Obsolete:Unsolved problems in roles

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 approaches to solve these problems, but AFAIK nobody published any plan for complete migration to new roles and capabilities yet. Why am I doing this? Because I am one of the few people that full understand how Moodle < 1.7 works - more specifically enrollments, user management and authentication, login process, installation process, session stuff, 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.

Now we have capabilities and manual assignment roles more or less working on course level. 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 GUI for roles between different sites.

It might not be evident but over the time we managed to add incredible amount of hacks into Moodle core to solve various problems in user management, access control, authentication, enrollments and other places. Most of the problems can be easily solved with combination roles and capabilities. If we start layering new hacks on top of the old ones, we might have to spend even more time on 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 the 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.

--Petr Škoda (škoďák) 08:48, 27 August 2006 (CDT)

---

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.

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