[[PageOutline]] = Multi-user projects = This document describes a set of BOINC server features that support projects with multiple job submitters, or '''users'''. A user may represent a single scientist, a research group, or some other organizational entity. (A "user" should not be confused with a "volunteer", which is a person who runs the BOINC client on their computer.) An example of a multi-user project is a science portal such as [http://nanoHUB.org nanoHUB.org]. Such projects are typically structured so that users interact with the project through a web-based interface, and only project admins have login access to the BOINC server. BOINC's design supports the following goals: * The set of users may be large (1000s) and dynamic. * The project's resources are shared fairly among users, based on quotas. * Privacy: users cannot in general see the computational results of other users. * Flexible access control. == User identity == Users are identified by BOINC project accounts (same as volunteers). Users may also be volunteers; i.e. they may supply computing resources to the project. (this may affect their quota; see below). == Access control == The following operations are subject to access control: * Submitting jobs * Creating and deprecating apps * Creating and deprecating app versions * Aborting jobs (possibly those submitted by other users) * Changing access privileges For each user, the BOINC access control system defines a set of '''global privileges''' and optionally a set of '''per-app privileges''' for each app. The global privileges include * '''submit_all_apps'''. If this flag is set, the user can submit jobs to any application, included those added in the future. * '''manage_all_apps'''. If this flag is set, the user * has '''manage''' privileges (see below) for all apps, including those added in the future. * can grant and revoke the privileges of any user, except '''manage''' privileges. * can create and deprecate apps * can set user quotas (see below) The per-app privileges include * the ability to submit jobs to the app * '''manage''': if this flag is set, the user can * create and deprecate versions of the app * grant and revoke per-app permissions for this app (except '''manage''' permissions). * abort any job of this app * view the output files of any job of this app Management privileges are controlled using a script ('''bin/manage_privileges''') on the server; they can be granted and revoked only by project admins. Other permissions are controlled via the manage_project.php page on the project web site. == User quotas == Each user has a '''quota''' which determines how much computing resource they get if there is contention. Roughly speaking, if a set of users are contending for resources, the amount that each one gets is proportional to their resource share. The way in which quotas are determined is up to the project. Some possibilities: * Each user attaches their own PCs to the BOINC project, and their quota is the recent average credit of these hosts. * Volunteers attached to the project can assign shares of their resource to scientists, and a scientist's quota is the sum of these, weighted by the volunteer average credit. * A user's share is increased if they contribute to the portal, e.g. by participating in the message boards. Quotas can be manually set by users with the '''admin_all_apps''' privilege, via a web interface. To enforce quotas, you must either: * submit job using [RemoteJobs remote job submission], and include the '''allocation_priority''' flag in your request objects. * otherwise, use [MultiUserPriority allocation-based prioritization] as part of your job-submission process. You must run the [BackendPrograms feeder] with the '''--priority_order''' option. Currently this can't be used in combination with the --all_apps option, or with homogeneous redundancy. == Resetting priorities == you can reset user priorities by running {{{ html/ops/submit_init_priority.php }}} This will also assign new priorities to queued jobs.