Version(s): OpenMRS 1.9.9
Issue or Question:
The module has several roles and (so far) one privilege. My goal is to add the roles and privileges correctly and assign them to each other.
- Currently the privilege is added to the database via config.xml, the roles are added within the activator class.
- I have also tried a solution where I add the roles and privileges in the liquibase file.
- Now I have seen the @AddonStartup Annotation. Is this the recommended way of adding roles and privileges within a module?
If I get this right, there are two different(?) approaches in the core:
a) Via Liquibase (liquibase-core-data.xml)
<column name="privilege" value="Delete Relationships"/>
<column name="description" value="Able to delete relationships"/>
b) Via PrivilegeConstants (PrivilegeConstants.java)
@AddOnStartup(description = "Able to delete relationships")
public static final String DELETE_RELATIONSHIPS = "Delete Relationships";
The OpenMRS Docs says:
If you want constant to be put into a database at app startup, just mark it:
@AddOnStartup(description = "Constant description")
public static final String MANAGE_SMTH = "Manage smth";
Why is there need to do both (a&b)?
So i get to my final question
What is the best approach to
a) add Roles
b) add Privileges
c) assign the privileges to the roles
If I get receive a good answer i would volunteer to update the wiki page for this topic.
Thank you in advance for your answers,
I think i have found a accurate way to add privileges and roles. The negative aspect for me was to upgrade my module to OpenMRS 1.9.4 compatibility, but this was actually a very positive side aspect
I am not going to widely describe the solution. I use the metadatadeploy-api to install the roles and privileges. If anyone wants to see an example take a look at “EbolaRolePrivilegeMetadata” class in the the ebola module:
If anyone ever needs help with this feel free to post here, I will try to help you!
we could need your input/opinions
what is the suggested or “best practice” approach for adding roles and privileges?
some modules use
- metadatadeploy api + a constants class including roles/privileges
- and some use liquibase + constants class including roles/privileges
I am personally in favor of the metadatadeploy method since we define the privileges/roles constants in a class and add them to the database via the install method provided by AbstractMetadataBundle using the same constants. the approach with liquibase still needs to have a class with the constants to refer to those privileges/roles in the code. and this is where there is a potential mismatch between roles/privileges in liquibase and the ones defined in the code. therefore I dont like it too much, but on the other hand using the metadatadeploy-api adds another dependency to the module.
we are currently discussing this with @bgevam and @sunbiz in the radiology module since we want to get the roles/privileges set up properly https://issues.openmrs.org/browse/RAD-60
but we have not yet reached a consensus.
@darius would you mind sharing your opinion? since I think you are doing development on the ebola example module which uses metadatadeploy
Modules can register privileges via the module configuration file as shown here. Or you can add both roles and privileges using the metadata deploy or metadata sharing modules
I definitely recommend using the metadatadeploy approach.
So, metadatadeploy instead of liquibase? Radiology module will have to add dependency to the metadatadeploy module, just for a couple of roles and privileges…
Normally I’ve done this in situations where I am also using metadatadeploy
to create other things too.
If you aren’t creating other metadata, and want to avoid the dependency, I
would create these via the config.xml-based mechanism that Wyclif mentioned.
Thanks @wyclif and @darius for your explanations! We will then stick with the config.xml for now and use the metadatadeploy once we want to add other things as well.
The config.xml approach only supports privileges and not roles though, if you really want to void adding dependencies on the other modules you could probably add the roles via liquibase as @sunbiz suggested