Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Unsolved problems in roles.

Obsolete:Unsolved problems in roles: Difference between revisions

From MoodleDocs
Line 29: Line 29:
===Idea: Separation of enrollment and guest password===
===Idea: Separation of enrollment and guest password===
* Add course password.
* Add course password.
* Add password bypass capability at course level - assign it to all Roles except Guest role
* Add password bypass capability at course level - assign it to all Roles except guest role
* Use this course password for enrollment
* Use this course password for enrollment
* Ask for the password when accessing course, store a marker in session and skip the check next time
* Ask for the password when accessing course, store a marker in session and skip the check next time


==Backup/Restore==
==Backup/Restore==

Revision as of 09:54, 27 August 2006

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

Idea: Separation of enrollment and guest password

  • Add course password.
  • Add password bypass capability at course level - assign it to all Roles except guest role
  • Use this course password for enrollment
  • Ask for the password when accessing course, store a marker in session and skip the check next time

Backup/Restore