Moodle

Provide triggers that cause automatic role assignment when a user enters a context

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.9
  • Fix Version/s: None
  • Component/s: Roles / Access
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE

Description

It would be nice if Moodle provided triggers that admins could set in any context, which would cause a specified role to be automatically assigned when a user with certain characteristics entered the context. For example, one of the characteristic could be authentication method. This role could be in addition to a default role (e.g., Auth user, on entry to System, Student on entry to course), or in addition to a default role.

See the following discussion for a use case
http://moodle.org/mod/forum/discuss.php?d=92537

Activity

Hide
Eloy Lafuente (stronk7) added a comment -

Assigning to Martin Dougimas... for his consideration.

Thanks for the report, John!

Show
Eloy Lafuente (stronk7) added a comment - Assigning to Martin Dougimas... for his consideration. Thanks for the report, John!
Hide
John Isner added a comment -

Ger Tielmans provides another compelling use case for this feature in http://moodle.org/mod/forum/discuss.php?d=70539. Ger wants to control Block visibility on the MyMoodle page so that parents see only the Mentees block. In his scheme (which automates parent account creation and Parent role assignment), parents are distinguished from other users by their usernames, which are of the form parent_<child> where <child> is the child's username. A trigger that matched the username with the R.E. parent_* could be used to assign a role in the System context that allowed parents to be distinguished from other users. Currently, all logged in users are Authenticated users in System, and there is no way to distinguish them.

Show
John Isner added a comment - Ger Tielmans provides another compelling use case for this feature in http://moodle.org/mod/forum/discuss.php?d=70539. Ger wants to control Block visibility on the MyMoodle page so that parents see only the Mentees block. In his scheme (which automates parent account creation and Parent role assignment), parents are distinguished from other users by their usernames, which are of the form parent_<child> where <child> is the child's username. A trigger that matched the username with the R.E. parent_* could be used to assign a role in the System context that allowed parents to be distinguished from other users. Currently, all logged in users are Authenticated users in System, and there is no way to distinguish them.
Hide
John Isner added a comment -

Another use case for this feature can be found in http://moodle.org/mod/forum/discuss.php?d=100873. An administrator wants to prevent students from creating blog entries, but allow teachers to do so. There is currently no way to do it automatically, and there are no good workarounds.

Show
John Isner added a comment - Another use case for this feature can be found in http://moodle.org/mod/forum/discuss.php?d=100873. An administrator wants to prevent students from creating blog entries, but allow teachers to do so. There is currently no way to do it automatically, and there are no good workarounds.
Hide
John Isner added a comment -

Maybe "trigger" is an unfortunate term. If I filed the issue today, I might call it "user defined user policies"

Imagine a third tab in the roles user interface in each context (Locally assigned roles,Override permissions, *User policies*). In this tab you could specify one or more (predicate, role) pairs. The interpretation of each pair is:

if <predicate> is true, assign <role> to the user

It must be possible to evaluate predicates when the user logs in so the information can be loaded into the USER->access structure. Here are some useful predicates:

  • RE matches user name
  • RE matches specified field in user profile
  • user has a particular role

Like standard user policies, the user may have to log out and log back in for a user-defined user policy to take effect (for example, if the user changes a field in his profile).

The third example above (user has a particular role) is particularly valuable, since it makes assignment a viable alternative to overriding. For example, I can define a user-defined user policy in a Forum context "If user has the Student role, assign the ForumModerator role." This is particularly valuable in System, where there is no override (we have many use cases for this).

Show
John Isner added a comment - Maybe "trigger" is an unfortunate term. If I filed the issue today, I might call it "user defined user policies" Imagine a third tab in the roles user interface in each context (Locally assigned roles,Override permissions, *User policies*). In this tab you could specify one or more (predicate, role) pairs. The interpretation of each pair is: if <predicate> is true, assign <role> to the user It must be possible to evaluate predicates when the user logs in so the information can be loaded into the USER->access structure. Here are some useful predicates:
  • RE matches user name
  • RE matches specified field in user profile
  • user has a particular role
Like standard user policies, the user may have to log out and log back in for a user-defined user policy to take effect (for example, if the user changes a field in his profile). The third example above (user has a particular role) is particularly valuable, since it makes assignment a viable alternative to overriding. For example, I can define a user-defined user policy in a Forum context "If user has the Student role, assign the ForumModerator role." This is particularly valuable in System, where there is no override (we have many use cases for this).

People

Vote (7)
Watch (7)

Dates

  • Created:
    Updated: