A common use-case in integration scenarios is to add roles to Series ACLs to permit members of a course to access recordings in a series.
This may be the case where users authenticate via LTI or a user directory provider, and the roles may be of the form courseid_Learner or courseid_Instructor. courseid is typically numeric.
Discussion thread here:
It is proposed to add this ability to the CustomRoleProvider so that a regexp pattern may be specified in /etc/custom.properties, e.g.
The ACL editor in the Admin UI will then call findRoles() to validate a role name that is manually entered (typed in rather than selected from drop-down list). If the CustomRoleProvider matches the regexp it will return the offered role name from findRoles and so the role will be permitted.
Given that the LTI code creates roles that are courseid_learner and courseid_instructor, I think it would make sense to have an option in the UI that let's you easily add these roles,
Oh, sorry: I was not aware that the LTI depends on such roles... Makes more sense then.
I created for this idea because it's slightly different to this issue.
I'm curious what strategy Lars is following for the ACL changes. Many years ago, I did a lot of access control, I only associated users to roles, and roles to groups. Only group (containers) could be assigned access rights to an object. This was because group associations were difficult to change on a distributed objects, but users were very easy to remove from a group. Individual users come and go all the time. The group container has a longer life. Associating a user directly to an ACL seems like it would make things more complicated (tightly coupled) rather than less.
Well... we will see