Hello Open edX Community! @mgmdi and @bryantt-v have written up 5 ADRs to spell out the model, runtime architecture, refresh and consistency frameworks for grouping users on the platform and the migration path and replication-based migration of legacy grouping mechanisms (such as course/track groups, cohorts, and teams). For added context, there is a product proposal in review for adding user groups to the platform outlining the feature’s value proposition. Please see all 5 ADRs listed below:
Any input on these ADRs is welcome and encouraged - we’d like to hear what you think! We’re hoping to continue on with the first phase of user group delivery soon, so we ask for any and all feedback by July 25th.
Could this be used for staff groups too, as the basis of RBAC and other permissions systems? For example, we currently have author permissions groups in courses and different author permissions groups in libraries, and no instance-level groups for authors. Or did you decide that this was specifically for learners only?
I’m wondering why you’ve decided to implement this as a plugin. It seems to be like it should be a core function that other plugins can build on.
Excellent question, Braden! This feature is explicitly for all users (not just learners), because we have the assumption that creating groups of specific staff users would be useful in a number of applications.
I really like the idea of using user groups for easily assigning RBAC to a group of staff users for example (mainly because - if we have a robust and generic user grouping mechanism - why build it twice in two different places?). But I’m not technical enough to know how feasible/advisable this would be from a technical standpoint and I’m a bit removed from the RBAC work in general - I’d need to rely on our technical RBAC and User Group experts on this one (@dave , @TyHob, @mgmdi, FYI @jmakowski and @sarina )
I’m wondering why you’ve decided to implement this as a plugin. It seems like it should be a core function that other plugins can build on.
Thank you for raising this - I agree this is part of the core, what I’m concerned about implementing it in, for example, edx-platform, is that plugin developers will not be able to easily install the Django app to use it as a library so we went ahead with a lightweight library others could import from. In any case, I think this raises a meaningful conversation we should definitely have. Can we move this discussion to this PR? Thank you!
I do think it makes sense, since this is not only meant for learners but also as a way to group based on any condition, so that any type of group can be created. I think it’d be helpful to have more examples of what we want to support, just to see if any red flags come up but I don’t see any at the moment.
Re: RBAC - @Guillermo_Viedma had mentioned the following: Thanks for sharing the User Groups project, it looks really promising. From what I understand, this feature will allow teams to define subsets of learners and take actions on them, such as sending emails, resetting problems, or downloading data. That’s closely related to some of the capabilities we’ve been envisioning for RBAC.
The current RBAC proposal already introduces the idea of scoping permissions to subsets of resources, for example, a specific course, an organization, or, more relevant in this case, all users within one of those. While User Groups weren’t explicitly part of the MVP, the architecture may support this kind of extension. Once the system includes support for cohorts, it becomes a natural step to explore group-level actions as well.
Eventually, I can see us defining roles or permissions like “Send email to Group X” or “Reset problem attempts for a defined group of learners.” At first, we might not need separate permissions per group if the user already has the right to act on the broader scope. For instance, someone with permission to manage a course could use the Groups feature to act on learners inside that course, without needing additional access.
My thought in reading your post was was more along the lines of using user groups to assign perms to a group of users. For example, the users in X user group on this instance gets A, B, and C perms. Is that more what you were thinking @braden?
From what I’ve read, I imagine Groups could relate to RBAC in three ways:
Using a group as the scope where a permission applies (for example, “Can send an email to Group A” or “Can edit the score of Group B”). Based on the current RBAC definitions, a group is actually closer to what we call a Scope in the proposal, since it is used to define a set of assets over which an action applies.
Role bulk assignment (for example, assigning Role A to Group B so it applies to the users in that group at that particular moment). I understand the value of this function, but if it does not include permission inheritance when the group changes, it may be hard for users to fully understand how it works. That said, I do not recommend adding inheritance either, for the reason mentioned in point 3.
Permission inheritance is the most delicate point. Assigning permissions directly to a group means members would inherit them, which replicates the behavior of roles. In that case, groups and roles would serve the same purpose, making the feature redundant.
Happy to be corrected if I am misunderstanding something. I am just trying to map it out based on what I have seen so far.
I don’t think that’s true at all. Roles are sets of permissions, whereas groups are sets of users. You can see this clearly in GitHub’s permission management system for example: you can create groups (“Teams”) like “Core Contributors” and assign each group a “role” like “Admin[istrator]”, “Maintain[er]”, “Write[r]”, “Triage[r]”, etc. Importantly, these roles can be assigned to groups at the org level or the individual repo level.
In fact, as I’ve said elsewhere, I personally believe permissions systems should discourage assigning roles directly to users. Over the long term it gets difficult to manage and audit; things are much cleaner if you only assign users to groups and then in turn assign roles to those groups. (Especially if the roles can be scoped, so e.g. a group called “MIT Admins” can have “Admin” role for “all courses in the MIT org”)
I’m not saying it can’t be done. Your definition of groups and roles is correct. But I don’t think using them the way you propose is obviously better or beyond discussion. Since we already built an initial definition without groups in mind, it didn’t seem natural to me to recommend that behavior upfront.
I understand the value of what you’re proposing, but I also see how it would affect the approach we’ve been working with. It introduces a layer of complexity we hadn’t considered and would significantly change both the interface and the overall structure. Even if it’s a bit late in the process, this is still a good time to talk about it, since the interface hasn’t been designed yet and implementation hasn’t started. I don’t find it self-evident that using groups leads to greater clarity and organization when it comes to authorization, but I recognize it’s a valid point of view and I’d like to explore it further.
I’d also be interested in hearing from other technical leads on the project, like @dave and @sarina, who helped shape the current definition and could help evaluate if your proposal is something we could (and should) incorporate before implementation starts.
For brief moments I had the opportunity to talk to @mgmdi about this. We, at now, have a couple of special use cases that (hopefully) can help you understand what kind of out-of-the-box solutions we might want to achieve.
Case 1: using cohorts for proctored exams. We have some courses that force proctored exams and a way to certify students. We observed that, because the proctoring software isn’t exactly 100% accessible, we had to find a way to separate participants into two distinct groups. Participants had to contact the course team in order to ask to enroll in the group without the proctoring restriction. The team responsible asked me multiple times if this process could be achieved automatically (like Moodle, where you can choose the team were you belong).
Case 2: customized certificates for cohorts. We also have a case where one of our course teams asked us to present extra content on some of their courses for a specific institution. The users of that institution are manually enrolled and placed in a specific cohort. Some new course sections where created that displayed personalized information to the students inside the cohort. The certificate template was also extended to contain additional logos and information. This is what we call a “mini-CCX” experience and a way to avoid duplicating course runs.
@Chelsea_Rathbun In case you need additional information, I can give you some visual examples of this.
