Moodle
  1. Moodle
  2. MDL-26805

Default role for all users setting only shows a limited list of roles - this *needs* documenting

    Details

    • Rank:
      16749

      Description

      The roles settings on the user policies page restrict the available roles to select. The code (admin/settings/users.php) checks the role archetypes but it is uncommented and undocumented. This will be confusing for users. If the list is restricted can we know why please?

        Activity

        Hide
        Helen Foster added a comment -

        Howard, thanks for reporting this issue.

        I tried creating a new role and found it was not available in the defaultuserroleid dropdown if the role archetype was set to student, as you mentioned in the discussion http://moodle.org/mod/forum/discuss.php?d=170956

        Show
        Helen Foster added a comment - Howard, thanks for reporting this issue. I tried creating a new role and found it was not available in the defaultuserroleid dropdown if the role archetype was set to student, as you mentioned in the discussion http://moodle.org/mod/forum/discuss.php?d=170956
        Hide
        James Snell added a comment -

        I agree this is a high priority issue. I'd rather not edit any source for fear of issues when upgrading later. This issue seems to be at the heart of a headache I've got.

        Cheers friends

        Show
        James Snell added a comment - I agree this is a high priority issue. I'd rather not edit any source for fear of issues when upgrading later. This issue seems to be at the heart of a headache I've got. Cheers friends
        Hide
        Howard Miller added a comment -

        'git blame' indicates the offending bit of code was written by Petr so I'm adding him in. He'll certainly have a logical explanation

        Show
        Howard Miller added a comment - 'git blame' indicates the offending bit of code was written by Petr so I'm adding him in. He'll certainly have a logical explanation
        Hide
        Petr Škoda added a comment -

        Which setting exactly?

        Show
        Petr Škoda added a comment - Which setting exactly?
        Hide
        Howard Miller added a comment -

        Home / ► Site administration / ► Users / ► Permissions / ► User policies

        All of the drop-downs that allow for a role selection restrict the list of roles that can be selected in one way or another. It is not clear, (apparently) not documented and the actual code (which filters based on archetypes) that does this is not commented. I'm sure there's a perfectly good reason for the restrictions but it's not obvious.

        Show
        Howard Miller added a comment - Home / ► Site administration / ► Users / ► Permissions / ► User policies All of the drop-downs that allow for a role selection restrict the list of roles that can be selected in one way or another. It is not clear, (apparently) not documented and the actual code (which filters based on archetypes) that does this is not commented. I'm sure there's a perfectly good reason for the restrictions but it's not obvious.
        Hide
        Petr Škoda added a comment -

        Each one may be restricted for different reason, this was introduced in early 2.0dev, some of the original problems that this was supposed to work around might have been resolved later (such as guest account problems). I will revisit this in 2.1dev, thanks.

        Show
        Petr Škoda added a comment - Each one may be restricted for different reason, this was introduced in early 2.0dev, some of the original problems that this was supposed to work around might have been resolved later (such as guest account problems). I will revisit this in 2.1dev, thanks.
        Hide
        Petr Škoda added a comment -

        Hello,

        I have cleaned-up the code a bit, tweaked the outdated info and removed one unused setting.

        However there is not much to be explained here, the defaults list roles with intended archetype + all roles without archetype. The creator role is one exception because there only manager and teacher (+ roles without archetype) actually make sense (I have kept student and non-editing teacher for now for BC reasons only). The frontpage role allows guest archetype for backwards compatibility only because the frontpage archetype did not exist in earlier versions and the role may not actually exist.

        If somebody does not like this they can either remove the archetype from custom role or the settings can be also hardcoded in config.php

        I would personally recommend to use only roles with expected archetypes or you risk major functional or security issues in current or future releases.

        Please submit new issues if more string related improvements are necessary, thanks a lot for this report!

        Petr

        Show
        Petr Škoda added a comment - Hello, I have cleaned-up the code a bit, tweaked the outdated info and removed one unused setting. However there is not much to be explained here, the defaults list roles with intended archetype + all roles without archetype. The creator role is one exception because there only manager and teacher (+ roles without archetype) actually make sense (I have kept student and non-editing teacher for now for BC reasons only). The frontpage role allows guest archetype for backwards compatibility only because the frontpage archetype did not exist in earlier versions and the role may not actually exist. If somebody does not like this they can either remove the archetype from custom role or the settings can be also hardcoded in config.php I would personally recommend to use only roles with expected archetypes or you risk major functional or security issues in current or future releases. Please submit new issues if more string related improvements are necessary, thanks a lot for this report! Petr
        Hide
        Howard Miller added a comment -

        Petr,

        I have read this several times and still don't understand what you mean. What are "expected archetypes" (for example, as opposed to some other kind of archetypes)? Even a help message saying "you cannot pick some of the roles for security reasons" would be better than nothing and avoid loads of queries in the support forums.

        I think you are assuming we know something about archetypes that we don't

        Show
        Howard Miller added a comment - Petr, I have read this several times and still don't understand what you mean. What are "expected archetypes" (for example, as opposed to some other kind of archetypes)? Even a help message saying "you cannot pick some of the roles for security reasons" would be better than nothing and avoid loads of queries in the support forums. I think you are assuming we know something about archetypes that we don't
        Hide
        Petr Škoda added a comment - - edited

        ARCHETYPE:

        • it is a hardcoded template for role
        • it tells what role is intended to be used for
        • it is used during upgrades when adding defaults for new capabilities - no archetype == no new capability during upgrade
        • it is used during reset reset to determine the defaults - no archetype == reset removes all capabilities

        No archetype used:

        • custom roles used for overrides
        • admin wants to specify new capabilities after upgrade manually

        default registered user role - the only archetype that makes sense is the 'user' archetype, this is intended for site level tweaks. There should be only one 'user' archetype role in all systems. This archetype is used during upgrades, we add new caps to it in access.php during upgrades. Systems that want to control everything 100% without our upgrades can remove the archetype completely. Some upgraded sites may not have this role at all, some might be still using archetype. There is absolutely no way teacher, manager, student, editing teacher or course creator could be used in this settings because it would not simply work.

        guest role - you do not ever want all guests to be managers or teachers, right? If you really do create a custom role without archetype for this hack.

        creator role - no sense to add creator role here, or guest or user because this is intended to allow creators to modify newly created courses.

        frontpage role - again only the frontpage role archetype tells us what are the expected capabilities for this role

        Show
        Petr Škoda added a comment - - edited ARCHETYPE: it is a hardcoded template for role it tells what role is intended to be used for it is used during upgrades when adding defaults for new capabilities - no archetype == no new capability during upgrade it is used during reset reset to determine the defaults - no archetype == reset removes all capabilities No archetype used: custom roles used for overrides admin wants to specify new capabilities after upgrade manually default registered user role - the only archetype that makes sense is the 'user' archetype, this is intended for site level tweaks. There should be only one 'user' archetype role in all systems. This archetype is used during upgrades, we add new caps to it in access.php during upgrades. Systems that want to control everything 100% without our upgrades can remove the archetype completely. Some upgraded sites may not have this role at all, some might be still using archetype. There is absolutely no way teacher, manager, student, editing teacher or course creator could be used in this settings because it would not simply work. guest role - you do not ever want all guests to be managers or teachers, right? If you really do create a custom role without archetype for this hack. creator role - no sense to add creator role here, or guest or user because this is intended to allow creators to modify newly created courses. frontpage role - again only the frontpage role archetype tells us what are the expected capabilities for this role
        Hide
        Howard Miller added a comment -

        OK, thanks. As I thought - I didn't really understand what archetypes do. That's really helpful.

        Show
        Howard Miller added a comment - OK, thanks. As I thought - I didn't really understand what archetypes do. That's really helpful.
        Hide
        Brandon Horn added a comment -

        Under User policies -> Default role for all users, can Student now be set as the default role? I'd like to make a Moodle site entirely public.

        Show
        Brandon Horn added a comment - Under User policies -> Default role for all users, can Student now be set as the default role? I'd like to make a Moodle site entirely public.
        Hide
        Petr Škoda added a comment -

        Brandon: Moodle is not designed to make everybody enrolled in each course. Tweaking the default role is not a good approach. You might try to hack the guest role instead, but some actions would be only available if users self-enrol anyway. You might want to create a new enrol plugin that enrols users automatically upon the first course visit.

        Show
        Petr Škoda added a comment - Brandon: Moodle is not designed to make everybody enrolled in each course. Tweaking the default role is not a good approach. You might try to hack the guest role instead, but some actions would be only available if users self-enrol anyway. You might want to create a new enrol plugin that enrols users automatically upon the first course visit.
        Hide
        Brandon Horn added a comment -

        Ok. Thanks Petr.

        I got quotes to commission a plugin to do that as well as one for SEO. The quotes were much higher than the functionality was worth to me though. I ended up using WordPress for the public site. Making Moodle more suitable for use on publicly accessible sites would significantly expand the use cases. I'm not sure to what extent it would impact the core functionality as a LMS though.

        Brandon

        Show
        Brandon Horn added a comment - Ok. Thanks Petr. I got quotes to commission a plugin to do that as well as one for SEO. The quotes were much higher than the functionality was worth to me though. I ended up using WordPress for the public site. Making Moodle more suitable for use on publicly accessible sites would significantly expand the use cases. I'm not sure to what extent it would impact the core functionality as a LMS though. Brandon
        Hide
        Chris Brainerd added a comment -

        Hi Petr,

        What actions would only be available if users are actually enrolled in a course? I was considering doing exactly as Brandon said: set the default role to student, so that no one needs to enroll, for my Moodle is public in the sense that all courses are available for all accounts. Fundamentally, it seemed that enrolling in a course accomplished assigning the student role to the account in that course's context, and so I concluded the equivalent thing to do for the whole site is to assign the student role to all accounts in the system context through the defaultuserroleid. Thus, the defaultuserroleid is preferable because there is no data (no list of student role assignments), and there is no enrollment process needed, not even for the student to click 'Enrol Me'. So, what is missing in this theory? Cheers.

        Show
        Chris Brainerd added a comment - Hi Petr, What actions would only be available if users are actually enrolled in a course? I was considering doing exactly as Brandon said: set the default role to student, so that no one needs to enroll, for my Moodle is public in the sense that all courses are available for all accounts. Fundamentally, it seemed that enrolling in a course accomplished assigning the student role to the account in that course's context, and so I concluded the equivalent thing to do for the whole site is to assign the student role to all accounts in the system context through the defaultuserroleid. Thus, the defaultuserroleid is preferable because there is no data (no list of student role assignments), and there is no enrollment process needed, not even for the student to click 'Enrol Me'. So, what is missing in this theory? Cheers.
        Hide
        Petr Škoda added a comment -

        Enrolled users:

        • can be assigned to groups
        • have grades
        • can submit assignments
        • are visible in the list of participants
        • can subscribe to forums
        • can participate in choices
        • etc.

        Only enrolled users are true participants in course. Technically you can enrol everybody in each course, but expect some performance problems if you have more than a few thousand of users in one course.

        Show
        Petr Škoda added a comment - Enrolled users: can be assigned to groups have grades can submit assignments are visible in the list of participants can subscribe to forums can participate in choices etc. Only enrolled users are true participants in course. Technically you can enrol everybody in each course, but expect some performance problems if you have more than a few thousand of users in one course.
        Hide
        Chris Brainerd added a comment -

        This is a tangent, so if there is a better place to discuss, please let me know. In regards to your comment about performance problems: this will be an inevitable situation for us. All of our courses will always be available to all of our accounts, and we naturally desire to scale over the years to increasingly larger customer base sizes. Are you talking about anything beyond the obvious inverse relationship between database size and speed, that should be incorporated into a scaleable Moodle design with 'site-wide enrollment'? And if so, where will these performance problems lie, or is there anything specific we can do now or later to alleviate them, besides natural remedies (get better hardware, structure the load, etc.)? For example, could you say 'never scale like that, at some point you want to duplicate courses in the same installation, or get another entire moodle installation.'

        Show
        Chris Brainerd added a comment - This is a tangent, so if there is a better place to discuss, please let me know. In regards to your comment about performance problems: this will be an inevitable situation for us. All of our courses will always be available to all of our accounts, and we naturally desire to scale over the years to increasingly larger customer base sizes. Are you talking about anything beyond the obvious inverse relationship between database size and speed, that should be incorporated into a scaleable Moodle design with 'site-wide enrollment'? And if so, where will these performance problems lie, or is there anything specific we can do now or later to alleviate them, besides natural remedies (get better hardware, structure the load, etc.)? For example, could you say 'never scale like that, at some point you want to duplicate courses in the same installation, or get another entire moodle installation.'
        Hide
        Chris Brainerd added a comment -

        Here is a relevant question. OK, my goal is all courses for all users. We have two user types, student and non-editing teacher. Students will self-enroll as students, since you talked me out of using defaultuserroleid. Teachers will also self-enroll in courses, but will be assigned the non-editing teacher role in the system context. (I duplicated the non-editing teacher role, and turned on the option for system context.) So, one self enrollment method, always assigns student, to both student and teacher accounts, and teacher accounts are additionally assigned the teacher role in system context. On the course's enrolled users page, for the teacher account in the Roles column, it shows "Student [x] Teacher". Will this achieve functionality for the teacher equivalent to if they were enrolled in each individual course as non-editing teacher? Any problems with being both student and teacher? It looks like I can also do this by creating a self enrollment method for the teacher role with an enrollment key, but I don't want every teacher to have to put in a key on every course their first time. (So, I don't specifically desire them to have the student role, but I'd rather they have two roles, then have a self enrollment method with a key.)

        Show
        Chris Brainerd added a comment - Here is a relevant question. OK, my goal is all courses for all users. We have two user types, student and non-editing teacher. Students will self-enroll as students, since you talked me out of using defaultuserroleid. Teachers will also self-enroll in courses, but will be assigned the non-editing teacher role in the system context. (I duplicated the non-editing teacher role, and turned on the option for system context.) So, one self enrollment method, always assigns student, to both student and teacher accounts, and teacher accounts are additionally assigned the teacher role in system context. On the course's enrolled users page, for the teacher account in the Roles column, it shows "Student [x] Teacher". Will this achieve functionality for the teacher equivalent to if they were enrolled in each individual course as non-editing teacher? Any problems with being both student and teacher? It looks like I can also do this by creating a self enrollment method for the teacher role with an enrollment key, but I don't want every teacher to have to put in a key on every course their first time. (So, I don't specifically desire them to have the student role, but I'd rather they have two roles, then have a self enrollment method with a key.)
        Hide
        Howard Miller added a comment -

        You can set up a course so that any authenticated user can enrol onto that course. Isn't that more sensible? I tend to recommend only changing these site-wide settings as a last resort anyway. Also, you risk confusing users as they will "see" a list of courses many of which they may not be actively participating in.

        Show
        Howard Miller added a comment - You can set up a course so that any authenticated user can enrol onto that course. Isn't that more sensible? I tend to recommend only changing these site-wide settings as a last resort anyway. Also, you risk confusing users as they will "see" a list of courses many of which they may not be actively participating in.
        Hide
        Chris Brainerd added a comment -

        Hi Howard, that's how it is set up. Self enrollment as student for all users in all courses. My question is, is there a problem with a user having non-editing teacher role in system context, and also having student role in course context from self enrollment? It's not what I want, but the former accomplishes making the user a teacher in all courses, and the latter accomplishes enrollment for the teacher, I just want them to use the same method students enroll because I don't want to have a self-enrollment method for teacher role with an enrollment key. Sorry to hijack the bug, this wasn't completely about default roles.

        Show
        Chris Brainerd added a comment - Hi Howard, that's how it is set up. Self enrollment as student for all users in all courses. My question is, is there a problem with a user having non-editing teacher role in system context, and also having student role in course context from self enrollment? It's not what I want, but the former accomplishes making the user a teacher in all courses, and the latter accomplishes enrollment for the teacher, I just want them to use the same method students enroll because I don't want to have a self-enrollment method for teacher role with an enrollment key. Sorry to hijack the bug, this wasn't completely about default roles.
        Hide
        Helen Foster added a comment -

        Petr, thanks for your explanation of role archetypes, which is now available in the docs: http://docs.moodle.org/en/Creating_custom_roles

        Thanks also for explaining why the default role for all users should not be set to student. I have amended the docs and included a link to this issue: http://docs.moodle.org/23/en/Roles_settings#Default_role_for_all_users

        Chris, apologies for the very long delay in replying. In general it is fine to assign a user the role of student and teacher. It should work as you'd expect, with the user having additional rights according to the teacher role. If you have further questions, please post in one of the forums on moodle.org, as usually nobody comments further on tracker issues with status closed.

        Show
        Helen Foster added a comment - Petr, thanks for your explanation of role archetypes, which is now available in the docs: http://docs.moodle.org/en/Creating_custom_roles Thanks also for explaining why the default role for all users should not be set to student. I have amended the docs and included a link to this issue: http://docs.moodle.org/23/en/Roles_settings#Default_role_for_all_users Chris, apologies for the very long delay in replying. In general it is fine to assign a user the role of student and teacher. It should work as you'd expect, with the user having additional rights according to the teacher role. If you have further questions, please post in one of the forums on moodle.org, as usually nobody comments further on tracker issues with status closed.
        Hide
        Petr Škoda added a comment - - edited

        Chris: you need a new enrolment plugin that assigns your expected students and teachers in your courses. I do not think this is ever going to work painlessly with standard enrolment plugins or any role hacks. You might use cohort enrolment plugin for teacher enrolments, the only drawback might be that you need to add it manually to each course or create some automated script for it. The same way if you add all your students to another cohort you might add it to all your courses too.

        If Martin Dougiamas wants a new "enrol_everybody" plugin in standard installation I can create it in a few hours, but I am not willing to work on it and maintain it in my free time, sorry.

        Show
        Petr Škoda added a comment - - edited Chris: you need a new enrolment plugin that assigns your expected students and teachers in your courses. I do not think this is ever going to work painlessly with standard enrolment plugins or any role hacks. You might use cohort enrolment plugin for teacher enrolments, the only drawback might be that you need to add it manually to each course or create some automated script for it. The same way if you add all your students to another cohort you might add it to all your courses too. If Martin Dougiamas wants a new "enrol_everybody" plugin in standard installation I can create it in a few hours, but I am not willing to work on it and maintain it in my free time, sorry.

          People

          • Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: