Obsolete:Unsolved problems in roles

Yesterday I wanted to start full conversion of modules to new roles, mainly remove isteacher(), isguest(), iseditingteacher() and isstudent(). I stopped sooner than expected. Here is the list of problems we should solve before going ahead with roles conversion.

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 require_login() or obsolete it by has_capability() with parameter to login if needed.
• add special handling of moodle/legacy:guest to has_capability() to keep its negative meaning for legacy code

Guest access

Originally we used require_login() and isguest() combination. require_login() to be discussed later. 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.

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.)

Enrollments

If I understand it correctly the enrollment plugins will have to be rewritten. 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 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 user and guest and make just plugins for it.

Proposed solution

Sorry for the OOP terminology ;-) Class is just a code, instance is something configured 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.

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.