User app filtering

BOINC offers two mechanisms allowing users to control the set of apps for which they get jobs. The first, described here, lets you designate apps as "beta test", and lets users opt-in to getting jobs for these apps. The second, "app filtering", lets users select apps individually.

App filtering is disabled by default. To enable it, add to your html/project/project_specific_prefs.inc:

define ('APP_SELECT_PREFS', true);

The app filtering user interface is part of project-specific preferences (i.e., the "Preferences for this project" link on their account page). If the feature is enabled, users are shown:

A list of apps and check boxes.
A checkbox labeled "If no work for selected applications is available, accept work from other applications?".

Users can specify project preferences separately for each host "venue" (default, work, school, home), allowing them to control which apps run on each host.

If no apps are selected, there is no restriction: the user can be sent jobs for any app. When you first enable app filtering, no apps are selected. Hence all users can get all apps. Post a news item to notify users that app filtering is available.

Defining default app selection

Suppose you want to define a default other than enabling all apps. For new users you can do this by adding some lines to your html/project/project_specific_prefs.inc:

function project_specific_prefs_default() {
	... existing code
	$x .= "<app_id>ID1</app_id>\n";
	...
	$x .= "<app_id>IDn</app_id>\n";

where ID1 ... IDn are the database IDs of the apps to enable by default.

This specifies default prefs for new users, but it doesn't affect existing users. Setting prefs for existing users, en masse, will require some new code; ask David Anderson.

Adding a new app

When you add a new app, it won't be sent to any users who have selected apps. You can change this (i.e. add the new app to the prefs of users who have selected apps) by running

app_select_edit.php ID

in your html/ops directory (where ID is the database ID of the new app). We recommend that you test this script for a few individual users before running it on your whole database; see the bottom of the script for details on how to do this.

Disabling app filtering

Currently there's no way to disable app filtering; if you undefine APP_SELECT_PREFS, the GUI will go away but existing prefs will continue to be enforced. To fix this we'll need to add a scheduler flag to disable app filtering; if you need this, ask me (David Anderson).

Implementation

Each user's list of selected apps is stored in the user.project_specific_prefs database field. Each 'allowed' application is represented by an element <app_id>N</app_id>, where N is the database ID of the application.

Home