After multiple community discussions today (TAC and the O3 design call), we have settled on introducing a generic entity access table that will hold such records:
{
principal_id: 123,
principal_type: "org.openmrs.Role",
resource_id : 987,
resource_type: "org.openmrs.module.cohort.CohortM",
access: "E+S"
}
This principal-to-resource mapping table will allow to 1) cover every possible scenario and 2) prepare us to fully adopt Spring Security (@ibacher to expand on this after his spike). Do not get bogged down by the details, such as the access string format, all this can be adapted to be more readable.
While the principal’s type can be anything, we will likely only use it with org.openmrs.User and org.openmrs.Role for the time being.
@burke @ibacher I still think that in the general case (so when the principal is not just a User) it is not sufficient to provide a reference to the principal and a reference to the resource, it is also necessary to specify a strategy to go from the principal to a collection of users. It is obvious what that one would do but in the above example there should be a RoleMappingStrategy, something like that:
class RoleMappingStrategy implements MappingStrategy<Role> {
public List<User> getUsers(Role principal) {
// returns all the users with the role `principal`
}
}
Of course there is a lot to be scrapped for a first stab since we will likely limit ourselves to supporting User and Role principal types, and therefore we may just hardcode two mapping strategies without putting together a more complicated architecture.