3 | | You can allow users to select which applications they will receive work for |
4 | | (by default, they may receive work for any application). |
| 3 | BOINC offers two mechanisms allowing users to control the set of apps for which they get jobs. |
| 4 | The first, described [BetaTest here], lets you designate apps as "beta test", and lets users opt-in to getting jobs for these apps. |
| 5 | The second, "app filtering", lets users select apps individually. |
6 | | Each user's list of selected apps is stored in the [ProjectSpecificPrefs project-specific preferences]. |
7 | | This is stored in the user.project_specific_prefs database field. |
8 | | Each 'allowed' application is represented by an element {{{<app_id>N</app_id>}}}, |
9 | | where N is the database ID of the application. |
10 | | If no {{{<app_id>}}} elements are present, the user may be sent work for any application. |
11 | | |
12 | | This feature is disabled by default. |
13 | | To enable it, edit your html/project/project_specific_prefs.inc to contain |
| 7 | App filtering is disabled by default. |
| 8 | To enable it, add to your html/project/project_specific_prefs.inc: |
| 12 | |
| 13 | The app filtering user interface is part of [ProjectSpecificPrefs project-specific preferences] |
| 14 | (i.e., the "Preferences for this project" link on their account page). |
| 15 | If the feature is enabled, users are shown: |
| 16 | * A list of apps and check boxes. |
| 17 | * A checkbox labeled "If no work for selected applications is available, accept work from other applications?". |
| 18 | |
| 19 | If no apps are selected, there is no restriction: the user can be sent jobs for any app. |
| 20 | When you first enable app filtering, no apps are selected. |
| 21 | Hence all users can get all apps. |
| 22 | Post a news item to notify users that app filtering is available. |
| 23 | |
| 24 | == Defining default app selection == |
| 25 | |
| 26 | Suppose you want to define a default other than enabling all apps. |
| 27 | For new users you can do this by adding some lines to your |
| 28 | '''html/project/project_specific_prefs.inc''': |
| 29 | {{{ |
| 30 | function project_specific_prefs_default() { |
| 31 | ... existing code |
| 32 | $x .= "<app_id>ID1</app_id>\n"; |
| 33 | ... |
| 34 | $x .= "<app_id>IDn</app_id>\n"; |
| 35 | }}} |
| 36 | where ID1 ... IDn are the database IDs of the apps to enable by default. |
| 37 | |
| 38 | This specifies default prefs for new users, but it doesn't affect existing users. |
| 39 | Setting prefs for existing users, ''en masse'', will require some new code; ask David Anderson. |
33 | | Once you use application filtering, |
34 | | currently there is no easy way to cancel it: |
35 | | users who have non-empty app lists will continue to |
36 | | be filtered even if you remove app filtering from your PHP code. |
37 | | The only ways to fully undo app filtering are: |
| 56 | Currently there's no way to disable app filtering; |
| 57 | if you undefine APP_SELECT_PREFS, the GUI will go away |
| 58 | but existing prefs will continue to be enforced. |
| 59 | To fix this we'll need to add a scheduler flag to disable app filtering; |
| 60 | if you need this, ask me (David Anderson). |