Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Unsolved problems in roles

From MoodleDocs
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.


See Enrolment rewrite and role tweaks proposal for up-to-date information.

All the ideas described here are just my thoughts, it does not represent any statement or future plans for Moodle development, in fact it might be completely wrong ;-) or there might be some better or easier approach to solve all these problems, but AFAIK nobody published any plan for complete migration to new roles and capabilities yet. (EDIT: Martin is working on his own specification just now - nice!) Why am I doing this? Because I am one of the few people that fully understand how Moodle works internally - more specifically enrollments, user management and authentication, login process, installation, session magic, etc.

Yesterday I wanted to start full migration of Glossary to new roles, mainly remove isteacher(), isguest(), iseditingteacher() and isstudent() and patch require_login(). I stopped sooner than expected. Now I am trying to come up with a clean solution for all problems. IMO we should first draft a complete plan for migration to new roles and capabilities framework, then make as clean implementation as possible and only after that add hacks to emulate old functions for legacy code and make GUI tweaks to ease the transition for teachers.

Capabilities and manual assignment of roles sort of work on course level now already. The old enrollment plugins are not usable, because they must work with role_assignments instead of user_students and user_teachers tables. Backup/restore code can not work before we make it use the new enrollment framework and add some mapping UI for roles between different sites.

It might not be evident but over the time we managed to add incredible amount of hacks ($CFG->force_login, guest access with password, guest autologin and so on) into Moodle core to solve various problems in user management, access control, security, authentication, enrollments and others. Most of them can be easily solved by combination of roles and capabilities. If we start layering new hacks on top of the old ones we might spend even more time coding and testing it, the result would be less flexible and I am afraid also less secure.

Do we have to solve these problems before 1.7? I am afraid yes. Originally I thought that we will keep user_students and user_teachers in 1.7 and just assign roles to existing students and teachers at the course level to give them some extra permissions; and transition to course enrollments based on role_assignments table later in 2.0. That way we could use the old enrollment, backup and user related code. I am not saying that it was a bad decision, but it will IMHO require much greater changes in Moodle core, it will not be 100% compatible with old code and we might have to do bigger UI changes.

In case we would need fast forward to 1.7.0 release we might (each of the points is roughly one week of coding and testing):

  • sacrifice backwards compatibility in 3rd party code - it would eliminate much of the compatibility testing (modules will have to be converted anyway, but it should be any easy process)
  • upgrade only actual data and not all the settings, mostly enrollment settings would have to be fixed/reviewed - we could add better migration of setting later in 1.7.1 (large site never upgrade to .0 release, new sites would not be affected at all and old smaller sites could be fixed in notime)
  • implement only restore on original site - the full restore, which we should better call export and separate it from normal backup, can be implemented in 1.7.1


--Petr Škoda (škoďák) 27 August 2006




Enrollments

If I understand it correctly the enrollment plugins should only handle automatic role assignments. The manual assignment is done through GUI at admin/roles/assign.php, there is no need for manual enrollment plugin anymore. It is not possible to use old course settings unchanged because we want to be able to assign particitants to different groups based on several criteria.

Definition: Enrollment plugins do automatic assignment of users into preset roles in given course context.
Definition: Enrollment means assignment to role(s).

It might be best to eliminate all exceptions in handling of not logged in users and guests and let the plugins hide it from modules.

Proposed solution

Sorry for the OOP terminology ;-) Class is just PHP code, instance is something configured by user and stored in the database.

  1. Create new enrollment classes - guest enrollment, notlogged enrollment, paypal enrollment, password protected enrollment, etc.
  2. Make gui for creating and configuring of enrollment instances - enrollment instance could be shared in several courses; each enrollment plugin instance may have different target roles
  3. Make gui to assign ordered list of enrollments in the course settings page
  4. use new check_enrollment($courseid) function instead of old require_login() - If user has no role in given course or some capability bypass (moodle/site:enrolled_everywhere?) at site level, it uses associated plugin instances to enroll the user.

As described above I would not assign any users at site level except admin, course creators and other VIPs. Guest and notlogged should be assigned roles at course level only. SITEID course context should be properly separated from site level context - these two are not the same anymore!

Each plugin would know into which role (or roles) is assigning the users. The enrollment request comming from course would have to contain userid and courseid. The plugin would simply assign the user to all its preset roles in the context of give course. The list of course assigned plugins would be traversed first to find out if we can enroll the user automatically, if not the list of forms from plugins requiring extra information (password, paypal, etc.) would be displayed. We should also store the enrollment plugin instance id in role_assignment table, field enrol.

check_enrollment() function

Replacement for require_login(). Original require_login() was used to prevent access to course material without login and to redirect to enrollment plugin if needed. It did handle various special cases for guest login, guest autologin, enrollments, global $COURSE handling and lots of other stuff.

check_enrollment() should do following in this specific order:

  • check that user has a role assigned in the context of given course - if yes ask for course password if any (only once per session)
  • try auto enrollment using any enrollment plugin assigned to the course
  • display enrollment options from plugins and link to login screen
    • password plugin would ask for enrollment password specified in course configuration
    • PayPal plugin for money
    • Guest plugin would display relogin link if guests allowed in

We could add some hacks or special plugins to allow intelligent redirection to login page later.

Guest enrollment plugin

Special purpose plugin replacing allow guest course option. If enabled it automatically assigns Guest role (or any other) to guest user in given course context. It would work only for guest user.

Notlogged enrollment plugin

Special purpose plugin replacing access without login. If enabled it could automatically assigns Notlogged role to notlogged user in given course context.See the section about assigning roles and capabilities to not logged in users. It would work only for notlogged user.

Password protected enrollment plugin

General purpose plugin, asks user for password if specified in course setting. It would not handle password protected guest access anymore, see bellow. It would not work guest and notlogged user.

LDAP plugin

the same as before. Enrolls users based on membership in LDAP groups. Can be used to sync the assignment too - from cron or upon request. It would not work guest and notlogged user.

PayPal plugin

The same as before. It would not work guest and notlogged user.

Separation of enrollment and guest password

  • Add course password.
  • Add password bypass capability (moodle/course:password_bypass) - allow it in all roles except Guest and Notlogged role
  • Use different password for enrollment and course access in course settings page
  • Ask for the course access password from check_enrollment() when one is set and user does not have moodle/course:password_bypass; ask it only once per session.

The enrollment plugins could be simplified - no special guest handling any more. We could password protect access for all users even after enrollment, not only for guests.

User perspective description

TO DO: ui and administration process description from amdmin, previous teacher and previous student

Access without login

How do we assign capabilities and roles to "not logged in" user?

Till now we used empty($USER->id) or isloggedin(). If we want to control everything using capabilities we need new notlogged user and Not logged role plus legacy capability site/legacy:loggedin. We should also eliminate $CFG->forcelogin that was used when we wanted to give access without login to resources at site level.

Solution

  • automatically create user notlogged - either in memory only or in database
  • load notlogged user in $USER if not logged
  • do some automatic assignment or capability overrides in upgrade
  • remove empty($USER->id) from core
  • rewrite and obsolete require_login(); use new check_entrollment($courseid) instead
  • add special handling of moodle/legacy:guest to has_capability() to keep its negative meaning for legacy code (or negate it moodle/legacy:notguest)

Guest access

Originally we used require_login() and isguest() combination. We are moving to capability checks only and stopping special checks in modules. We can not assign guest user to Guest role manually now - guest user is assigned to Guest role automatically at the site level.

Role assignment at site level gives the user role capabilities in all courses now. As described above it might be better to enroll guest into Guest role only in SITEID course context insead of site level context; and use guest enrollment plugin to do the trick of guest access into public courses. Because if we do not enroll user at site level, he would not have any capabilities at course level when not enrolled into it.

Solution

  1. If we keep course settings gui, make automatic overrides of Guest role based on access setting.
  2. During upgrade assign Guest role to guest only at SITEID course level instead of site level. Assign guest to guest role in courses with open access. Enroll guest as normal users in new courses. (Password for guests could be made separate from enrollment process password.)

Backup/Restore