Roles as Group-Scoped Permission Sets

The hardest type of software to design is one that attempts to model diverse non-digital workflows with long histories. I'm going to start simple.

A collaborative web application needs to know who can do what things. Sometimes it needs to make sure that people don't take some action or see something they shouldn't. We call that a permission. Since different applications typically perform different functions, they often have different permissions. On the other hand, when multiple applications need to cooperate (e.g., an online Tests & Quizzes application needs to change scores in an online Gradebook application), they should ultimately check the same permission. But whatever the interesting permissions are, they have to stay fixed and known, or the application code will break.

For single short-term collaborative applications modeling simple real-world tasks, that may be enough to get by. We say "Joe Cool can read this message", "Joe Cool can't edit this message", "Josie Looc can read this message", "Josie Looc can't edit this message", "Janet Tenure can read this message", and "Janet Tenure can edit this message". But then Jim Loco shows up. Now we have to say two new things for him. And then Joe Cool leaves. Now we have to say two new things about him, too.

Moreover, as you have more collaborative applications in a unified environment, each may share some permissions or bring in its own permissions. So now you might have to say twelve things every time a person's status changes. And if a new application gets added after all of these people are already known to the environment, you might have to say, oh, 600,000 things at once.

So, for this and a variety of other reasons, we'd like to be able to clump people together and refer to them as a group. In this case, we might group by permission. We'd say "Make a ReaderGroup which can read but not edit messages", "Make an EditorGroup which can read and edit messages", "Joe and Josie are in the ReaderGroup", and "Janet is in the EditorGroup". Then we "Add Jim Loco to the ReaderGroup" and "Remove Joe Cool from the ReaderGroup". Then when we add "Send to the Printer" functionality, we might just have to add two new permissions: a "can't send" for the ReaderGroup and a "can send" for the EditorGroup. (Bear in mind, though, that a group may be defined for reasons other than just permission handling.)

At this point, the concept of "role" and "group" aren't obviously separable. But if the collaborative applications have to support more than one community context (multiple courses or research groups containing multiple sections or project groups), or survive more than a single turnaround of community (multiple semesters), we won't want to have to define all those ad hoc groups and all their stored permissions over and over again.

If we look at how human beings deal with this cognitive load in the real world, this is where the concept of role comes in. We don't say "put Josie Looc in the group of people who can sit in the lecture hall, participate in discussions, take tests, and be graded". We say "make Josie Looc a student in the course". We don't say "this particular group of individuals will be statistically tracked on their participation in online discussion". We say that "students will be."

We could call it a "job" or even a "stereotype", but the advantage of calling it a "role" is to reinforce the relativity of the attribute: a single actor can play many roles, even on the same stage. In higher education, a person may be a "Teaching Assistant" (with all the implied permissions) for "Lab 1" and "Discussion Group B" in the context of one course, and a "Student" (with another set of implied permissions) in another course. An "Instructor" (with permission to submit final grades) in the context of one course may be a "Guest Lecturer" (with permission to provide content and participate in discussions) in another. The next year, the courses (and their modeled versions in the software system) may stay pretty much the same, but different people will be playing all the roles.

Abstracted in relational terms, the "role" could be viewed as an attribute of the person's relationship to the group. Or you could model it as an attribute of an unnamed group with a tight relationship to a named group. No matter how you model it, though, it has a real-world meaning and use outside that particular instance. (For example, if the role of "TA" is meaningful in a course, an instructor will want to be able to quickly see a list of all TAs for all sections and see a list of the sections each TA is assigned to.)

In the abstract, all this is all pretty easy to handle. What makes our current job daunting is that the implied meanings of academic cross-institutional "roles" and "groups" are not as easy to define or as stable as the "permissions" of interest to applications.

Just about everyone can agree on two basic roles scoped by "course" membership: Instructor (who can do anything) and Student (with a far smaller set of implied permissions). (Or, in the more generically collaborative world, two basic roles scoped by "site" membership: Administrator and Member.) Otherwise, there seems to be massive ambiguity around "course"-scoped (or "site"-scoped) groups and roles. In most places, "TA"s are assumed to be able to grade students in their sections and have "commenting" rights on content whose access is scoped by section, and can't override or submit final grades. But some institutions will want non-instructors to be able to manage section-membership or change site content. In some places, "sections" are defined externally to the LMS/CLE itself; in others, the section management application will be chiefly responsible; in still others (such as UC Berkeley), there's a need to mix externally and internally defined sections and work groups.

For this reason, in the long term, I believe that solid LMS/CLE section-and-role support includes the requirements of solid collaborative framework support for generic roles and ad hoc groups. A "role" will be defined as a collection of implied permissions, with the definitions managed deployment-wide, and a user's "role" is an attribute of their membership in a group. The specifically LMS/CLE aspects are extras: special support for defining and managing groups from institutional data, agreement on a set of shared set of education-specific permissions (e.g., "grading"), aggreement on a set of shared attributes for education-specific groups (e.g., "defined by the registrar"), and increasing agreement on out-of-the-box roles.

(As I understand it, this sounds like U. Michigan's current "template" approach, which defines "user.template.ROLE" for permissions scoped by framework membership and "site.template.course/ROLE" for permissions scoped by site membership. Extending that scheme to handle typical section roles might give us "site.template.course.section"-scoped permission settings called things like "Section Admin", "TA", and "Visiting Lecturer".)