Roles and Privileges

Application Privileges vs. API Privileges

In the Reference Application, we make a distinction between Application Privileges (that control access to different features of the application feature) and API Privileges (that control calls to the underlying API). For example a pharmacy aide who records dispensed medications would need the API privilege "View Patients" (or "Get Patients" in newer versions of the platform), but an implementation might not allow them to search for patients through the standard UI, by not giving them the privilege "App: coreapps.findPatient".

Application Privilege Naming

The underlying OpenMRS platform does not yet support the distinction between Application and API privileges, so we are forced to use a somewhat hacky workaround. Application privileges need to start with either "App:" or "Task:", which allows the Reference Application to recognize them.

Note that the underlying OpenMRS platform does not recognize these prefixes as having any special meaning, so you need to use the full privilege name (including the prefix) in config.xml, in any @Authorized, etc.

"App:"

If your privilege controls top-level access to an entire suite of functionality, you should give it a name starting with "App:". For example the Capture Vitals app on the homepage is controlled by a privilege named "App: referenceapplication.vitals". All homepage links should be controlled by an "App:" privilege. (You may also use "App:" privileges in other cases though.)

"Task:"

If your privilege controls access to one feature within a larger set of functionality, you should give it a name starting with "Task:". For example the Visit Note action on the patient dashboard is controlled by the privilege "Task: referenceapplication.simpleVisitNote" and opening the vitals form from the patient dashboard is controlled by "Task: referenceapplication.vitals".

Application Roles

TBD