Moodle
  1. Moodle
  2. MDL-21655

Permissions and roles changes in 2.0 META

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: Roles / Access
    • Labels:
      None
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      32846

      Description

      List of tasks and general overview of planned
      1/ permissions evaluation changes - http://docs.moodle.org/en/Development:New_permissions_evaluation_in_2.0
      2/ role archetype improvements
      3/ new enrolments framework

      1. archetypes_21.patch
        555 kB
        Petr Škoda
      2. archetypes_23.patch
        556 kB
        Petr Škoda
      3. archetypes_25.patch
        555 kB
        Petr Škoda
      4. archetypes_28.patch
        606 kB
        Petr Škoda

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          Just a reminder, it's crucial we have a plan for global groups very soon.

          Show
          Martin Dougiamas added a comment - Just a reminder, it's crucial we have a plan for global groups very soon.
          Hide
          Dan Poltawski added a comment -

          A question which isn't clear in my mind: In the brave new world what is the purpose of category context?

          Show
          Dan Poltawski added a comment - A question which isn't clear in my mind: In the brave new world what is the purpose of category context?
          Hide
          Petr Škoda added a comment -

          why course category context ?

          • course creators
          • cohorts visible in some courses only
          • course managers in category (aka small admins)
          • in theory you could enrol students in courses and assign roles in contexts above
          • gradebook defaults use contxtid too
          • quiz questions access control
          • different themes for categories
          • etc.
          Show
          Petr Škoda added a comment - why course category context ? course creators cohorts visible in some courses only course managers in category (aka small admins) in theory you could enrol students in courses and assign roles in contexts above gradebook defaults use contxtid too quiz questions access control different themes for categories etc.
          Hide
          Petr Škoda added a comment - - edited

          Change log (updated to match latest code):

          • capability "moodle/course:view" redefined - means user may enter course without being enrolled, also is not visible, this capability is removed from the guest role finally
          • new capability "moodle/course:participate" - user enrolled and visible in course
          • "administrator" role removed - instead admins are list in $CFG->siteadmins
          • simplified use of $doanything parameters - now available only in has_capability(), not necessary anywhere else
          • hidden role assignments replaced by inspect capability and concept of enrolment and profile roles list
          • new "manager" role created, all original admins at lower levels assigned this role
          • new role archetypes replace old capability capabilities
          • negative guest capability removed - obsoleted by inspect capability and enforced restrictions in has_capability()
          • hardcoded restrictions in has_capability() for guest user account - no write access or risky capabilities (no need to use isguestuser() in so many places for security reasons)
          • new $CFG->profiteroles list - those are the roles visible in the profile and participants page
          • improved handling of $CFG->coursemanager roles - it is now used instead of isteacherinaanycourse()
          • new API - is_enrolled(), is_inspecting(), get_enrolled_sql() - major performance boost
          • undeprecated API - isguest($context) - course visitors + real guest account
          • fixed group assignment code - now allows assignment for roles only for enrolled users
          • fixed survey and choice - only for enrolled users
          • only enrolled users are visible in online users list - it is possible to add new capability to see all users including inspectors and visitors

          Definition os some terms:
          Enrolled user - participant in the course, those are usually students+teachers.
          Manager - somebody with full access that does not actually teach in course and does not interact with students
          Visitor - somebody with a temporary guest access into course, the access is granted in require_login() depending on the course settings
          Administrator - somebody administering server, has_capability() always returns true, get_user_by_capability() and get_enroleld_users() does not return them (with the exception of frontpage)

          Short list of benefits:
          1/ the api is compatible with future changes in enrolments (the new tables instead of course:participate capability) - it should not be necessary to modify SQL or PHP code in capabilities
          2/ simplified UI - no hidden role assignments that were working only in some areas
          3/ no problems with unintended modifications of admin role
          4/ much better performance - finally we may query who is enrolled in course

          Note: more info and explanation coming into wiki soon....

          Show
          Petr Škoda added a comment - - edited Change log (updated to match latest code): capability "moodle/course:view" redefined - means user may enter course without being enrolled, also is not visible, this capability is removed from the guest role finally new capability "moodle/course:participate" - user enrolled and visible in course "administrator" role removed - instead admins are list in $CFG->siteadmins simplified use of $doanything parameters - now available only in has_capability(), not necessary anywhere else hidden role assignments replaced by inspect capability and concept of enrolment and profile roles list new "manager" role created, all original admins at lower levels assigned this role new role archetypes replace old capability capabilities negative guest capability removed - obsoleted by inspect capability and enforced restrictions in has_capability() hardcoded restrictions in has_capability() for guest user account - no write access or risky capabilities (no need to use isguestuser() in so many places for security reasons) new $CFG->profiteroles list - those are the roles visible in the profile and participants page improved handling of $CFG->coursemanager roles - it is now used instead of isteacherinaanycourse() new API - is_enrolled(), is_inspecting(), get_enrolled_sql() - major performance boost undeprecated API - isguest($context) - course visitors + real guest account fixed group assignment code - now allows assignment for roles only for enrolled users fixed survey and choice - only for enrolled users only enrolled users are visible in online users list - it is possible to add new capability to see all users including inspectors and visitors Definition os some terms: Enrolled user - participant in the course, those are usually students+teachers. Manager - somebody with full access that does not actually teach in course and does not interact with students Visitor - somebody with a temporary guest access into course, the access is granted in require_login() depending on the course settings Administrator - somebody administering server, has_capability() always returns true, get_user_by_capability() and get_enroleld_users() does not return them (with the exception of frontpage) Short list of benefits: 1/ the api is compatible with future changes in enrolments (the new tables instead of course:participate capability) - it should not be necessary to modify SQL or PHP code in capabilities 2/ simplified UI - no hidden role assignments that were working only in some areas 3/ no problems with unintended modifications of admin role 4/ much better performance - finally we may query who is enrolled in course Note: more info and explanation coming into wiki soon....
          Hide
          Petr Škoda added a comment -
          Show
          Petr Škoda added a comment - Link to docs with more info: http://docs.moodle.org/en/Development:Enrolment_usage_overview
          Hide
          Martin Dougiamas added a comment -

          Most of this sounds fine and if we can still get SQL joins on enrolment without using a new table then all the better.

          My questions:

          1) Are you sure the SQL joins still work fast when someone has the capability at the category and site level? I thought that was one of the main selling points of the course_participants table, in that course enrolments were explicitly specified and thus very fast.

          2) The two capability names in English effectively mean the same thing (view == inspect) so I think they are confusing. If we are going down this path I would use course:view to mean the role can see the course (ie what the patch currently calls "inspect") and I would use course:participate to explicitly specify participants in the course (ie what the patch currently calls "view").

          Show
          Martin Dougiamas added a comment - Most of this sounds fine and if we can still get SQL joins on enrolment without using a new table then all the better. My questions: 1) Are you sure the SQL joins still work fast when someone has the capability at the category and site level? I thought that was one of the main selling points of the course_participants table, in that course enrolments were explicitly specified and thus very fast. 2) The two capability names in English effectively mean the same thing (view == inspect) so I think they are confusing. If we are going down this path I would use course:view to mean the role can see the course (ie what the patch currently calls "inspect") and I would use course:participate to explicitly specify participants in the course (ie what the patch currently calls "view").
          Hide
          Petr Škoda added a comment -

          sending latest version - commit candidate, going to do a few more installs and upgrades tomorrow and then I think it is ready for commit :-D

          Show
          Petr Škoda added a comment - sending latest version - commit candidate, going to do a few more installs and upgrades tomorrow and then I think it is ready for commit :-D
          Hide
          Anthony Borrow added a comment -

          I noticed Martins recent commit about count_enrolled_users and wondered if this takes into account or might be helpful if it could take into account hidden enrollments. Peace - Anthony

          Show
          Anthony Borrow added a comment - I noticed Martins recent commit about count_enrolled_users and wondered if this takes into account or might be helpful if it could take into account hidden enrollments. Peace - Anthony
          Hide
          Martin Dougiamas added a comment -

          Well, we don't really have that concept any more. You are only "enrolled" when you are a participant (have the participant capability). The old "hidden" roles are now those people who have view capability but not the participant capability. Not sure when that might be useful to know...

          Show
          Martin Dougiamas added a comment - Well, we don't really have that concept any more. You are only "enrolled" when you are a participant (have the participant capability). The old "hidden" roles are now those people who have view capability but not the participant capability. Not sure when that might be useful to know...
          Hide
          Petr Škoda added a comment -

          Closing this issue, I have move the enrol related stuff into new meta issue - I hope it will be all committed soon.
          Please do not file enrolment related regression issues before it lands, thanks everybody!

          Show
          Petr Škoda added a comment - Closing this issue, I have move the enrol related stuff into new meta issue - I hope it will be all committed soon. Please do not file enrolment related regression issues before it lands, thanks everybody!

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: