I poked my head into a conversation thread about Cohort permissions, and the topic came up that we should have a built-in way of representing ad-hoc groups of users. (This is different from Role, which are about assigning system privileges.)
I feel like this feature would be important to have, but it’s never urgent enough for anyone to pick up ahead of time.
I’d like to volunteer to design and implement this feature. I would do this very slowly, since I don’t have much spare time these days.
Would this be useful? If so, please let me know here, and I’ll start a design doc to better capture the use case.
Yes a new UserGroup entity is indeed needed. I would say that, among other things (such as those that you listed), this entity is what would be a proper implementation of organisational roles.
We discussed this very topic with @burke on a call recently and I commented that the OpenMRS
wiki states well the distinction between app roles and organizational roles but does not provide an appropriate mechanism to model the latter. User groups would be the way to do that.
It’s certainly a feature that would be useful to the way we’re discussing leveraging cohorts to provide patient lists; whether or not that would see actual use in practice I’m unclear on. I’m happy to review a design document, though.
Hey @darius! I hope you and your family are doing well and staying safe.
I like the potential of UserGroup to provide the creation of groups of users that can be used for more than permission assignment. Some random thoughts that come to mind (feel free to ignore these, just free-associating here):
What are the similarities/differences from cohort? Will we end up wanting all the same features as cohorts (e.g., static manually-managed lists of users and dynamic/calculated lists, start & stop dates for memberships)? If so, can we leverage the same code/approach to avoid doing the same thing twice or in different ways?
How does this relate to grouping providers? When I consider groups of users unrelated to permissions/access management, most of the examples are actually groups of providers.
How can we avoid promoting lists of everybody? Just like we added concept_class to classify concepts without having to create massive concept sets (like creating a concept set for all diagnoses), I wouldn’t want, for example, to end up with a user group for all providers.
Can we avoid making implementers & developers hate the UserGroup feature and find workarounds because it’s a pain to manage (like we managed to do with roles & privileges)?
I note that several of these are provider scheduling use cases that could be based on the same data structure as User Groups, but I would have assumed they’d be part of a dedicated system.
I would focus on users for now (instead of users + providers), since groups of providers remains an imagined need and, in most cases, providers will also be (or could be) users of the system.
Instead of hardcoding a single owner, what about allowing ADMIN, EDIT, and VIEW relationship to user and to user group? That would allow multiple owners (e.g., who could delete the group).
How would we handle publicly accessible (viewable) groups without having to grant view access to all users?
We may not need to add groups of groups now, but I could easily see it becoming a requirement if user groups are used widely, so – even if we don’t build it now – I’d like to at least consider how it would affect the API. More specifically, could it be introduced in a backwards-compatible way that doesn’t require all consumers to be refactored. For example, an API call like “Who are the users in this group?” could returns all users whether direct members or members of subgroups. And if “What groups is this user in?” only returned direct memberships, the responses wouldn’t change. But “Remove user from a group” might behave differently (e.g., after groups of groups was introduced, it might fail if the user belongs to a subgroup and isn’t a direct member of the group). That’s probably fine.
Groups of groups gets a little more complicated when you consider permissions (e.g. what happens if a user has VIEW access to a group but doesn’t have access to one of its subgroups? Maybe that’s more reasons to defer groups of groups for now.
That sounds reasonable. I’m pretty sure an early requirement will be the ability to share non-public lists with others (users or user groups) and collaborative management. Starting with just is_public could work and a couple of many-to-many relationships to hold permissions (admin, edit, view) for users & user groups could be v1.1.
As long as requesting a user’s groups only returns direct memberships (e.g., not parents of groups once hierarchies are introduced). When hierarchies are introduced, there could be separate method(s) to get all inherited groups and/or find out which direct group membership(s) connect a user to a specific group (i.e., to make it easier to figure out why a user is in a group through the hierarchy).
Maybe that’s more reasons to defer groups of groups for now.