Note: You are currently viewing documentation for Moodle 3.11. Up-to-date documentation for the latest stable version of Moodle may be available here: User policies.

User policies: Difference between revisions

From MoodleDocs
m (Tsala moved page Roles settings to User policies over redirect)
m (Document 255 character limit on user profile fields.)
 
(18 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Roles}}
{{Roles}}
==User policies==
==User policies==
The following settings may be changed by an administrator in ''Administration > Site administration > Users > Permissions > User policies''.
The following settings may be changed by an administrator in ''User policies'' in the Site administration.


===Role for visitors===
===Role for visitors===
Line 9: Line 9:
This option specifies the role that will automatically be assigned to the guest user. This role is also temporarily assigned to non enrolled users when they enter a course that allows guests without password.
This option specifies the role that will automatically be assigned to the guest user. This role is also temporarily assigned to non enrolled users when they enter a course that allows guests without password.


===Deny Guest Access to a site altogether===
(If you wish to deny guest access to a site altogether, the guest login button should be set to hide in ''Manage authentication'' in the Site administration.)
 
Go to Site administration ► Plugins ► Authentication ► Manage authentication and there is a switch there that allows you to turn the Guest Access button off altogether.


===Default role for all users===
===Default role for all users===
Line 17: Line 15:
It is recommended that the default role for all users is set to [[Authenticated user]]. To set it to a custom role, the custom role must be assignable in the system context and have role archetype set to none.
It is recommended that the default role for all users is set to [[Authenticated user]]. To set it to a custom role, the custom role must be assignable in the system context and have role archetype set to none.


Note: It is not recommended that the default role for all users is set to student, for reasons given in MDL-26805.
Note: It is not recommended that the default role for all users is set to student.
 
===Creators' role in new courses===
Moodle will automatically enroll the user creating a new course in the course with the role specified in this setting.  Moodle checks that the role used for creating the course e.g. "Course creator" has the right to assign the specified role in the new course. This means that the following capabilities needs to be set on the course creator role before the user is enrolled automatically : 
* moodle/course:create | Allow 
* moodle/course:manageactivities | Allow
* moodle/course:viewparticipants | Allow
* moodle/role:assign | Allow
 
If the course creator role is not setup correctly the user will be enrolled in the course without any roles.  


===Auto-login guest===
===Auto-login guest===
Line 23: Line 30:
If not set, then visitors must click the "Login as a guest" button before entering a course which allows [[Guest|guest access]].
If not set, then visitors must click the "Login as a guest" button before entering a course which allows [[Guest|guest access]].


Note: If auto-login guest is set, the guest login button also needs to be set to show (in ''Administration > Site administration > Plugins > Authentication > Manage authentication''), even though visitors won't necessarily use it.
Note: If auto-login guest is set, the guest login button also needs to be set to show in ''Manage authentication'' in the Site administration, even though visitors won't necessarily use it.


===Hide user fields===
===Hide user fields===
Line 37: Line 44:
Any of the following fields may be shown to users with the capability [[Capabilities/moodle/site:viewuseridentity|moodle/site:viewuseridentity]] when searching for users and displaying lists of users.
Any of the following fields may be shown to users with the capability [[Capabilities/moodle/site:viewuseridentity|moodle/site:viewuseridentity]] when searching for users and displaying lists of users.


This setting is useful for sites with large number of users, where the likelihood of users with the same name is high.
*Username
*ID number
*ID number
*Email address
*Email address
Line 43: Line 53:
*Department
*Department
*Institution
*Institution
*City/town
*Country


This setting is useful for sites with large number of users, where the likelihood of users with the same name is high.
{{New features}}New in 3.11: Custom profile fields (shown with an asterisk against their name) may now be selected to appear in certain locations. Note that only "Text input" fields are currently supported, and that their character limit must not exceed 255.


Locations where user identity fields are shown are as follows:
Locations where user identity fields are shown are as follows:
Line 50: Line 63:
*User selectors ([[Assign roles]] in some places, [[Groups|groups]], forum subscribers)
*User selectors ([[Assign roles]] in some places, [[Groups|groups]], forum subscribers)
*[[Browse list of users]]
*[[Browse list of users]]
*Course participants
*[[Participants]]
*[[Gradebook|Grader report]]
*[[Gradebook|Grader report]]
*[[Quiz reports]]
*[[Quiz reports]]
Line 57: Line 70:
*[[Using Course completion|Course completion report]]
*[[Using Course completion|Course completion report]]
*[[Using Activity completion|Activity completion report]]
*[[Using Activity completion|Activity completion report]]
*[[Enrolled users|Enroling users]]


Tip: Select only one or two fields that are mandatory at your institution. Do not select more than two fields otherwise tables become very wide.
Tip: Select only one or two fields that are mandatory at your institution. Do not select more than two fields otherwise tables become very wide.
Line 63: Line 75:
===Full name format===
===Full name format===


See [[Additional name fields]] for details, also about the alternative full name format (in 2.8 onwards).
See [[Additional name fields]] for details, also about the alternative full name format.


===Maximum users per page===
===Maximum users per page===
Line 71: Line 83:
===Enable Gravatar===
===Enable Gravatar===


[http://gravatar.com/ Gravatar] (an abbreviation for globally recognized avatar) is a service for providing globally unique avatars.
[http://gravatar.com/ Gravatar] (an abbreviation for globally recognized avatar) is a third party service for providing globally personal avatars.


An administrator can enable the use of gravatars in ''Administration > Site administration > Users > Permissions > User policies''. If a user has not uploaded a user picture, Moodle will check whether the user's email address has an associated gravatar and if so, will use the gravatar as the user's picture.
If Gravatar service is enabled by the administrator and a user has not uploaded any user picture, Moodle will check whether the user's email address has an associated gravatar account and if so, will use the gravatar as the user's picture.
 
* [http://www.youtube.com/watch?v=Z4b7tJedlMA Use your Gravatar in Moodle 2.2 screencast]


===Gravatar default image URL===
===Gravatar default image URL===


In Moodle 2.3.3 onwards, if gravatars are enabled, an alternative default user picture may be specified. The options are:
If gravatars are enabled, an alternative default user picture may be specified. The options are:


* A gravatar default image - by entering a code such as mm. See https://en.gravatar.com/site/implement/images/ for codes of other gravatar default images.
* A gravatar default image - by entering a code such as ''mm'' or ''identicon'' - See https://en.gravatar.com/site/implement/images/ for codes of other gravatar default images.
* A specified image - by entering the image URL
* A specified image - by entering the image URL


Line 90: Line 100:
Unsupported role assignments are role assignments in contexts that make no sense for that role, such as the course creator role in the course or activity context, or the teacher role in the user context.  
Unsupported role assignments are role assignments in contexts that make no sense for that role, such as the course creator role in the course or activity context, or the teacher role in the user context.  


Prior to Moodle 2.0, there was no 'Context types where this role may be assigned' setting in the edit role form, and so any role could be assigned in any context. Upon upgrading a site from 1.9, any role assignments in contexts that make no sense for that role are listed as unsupported role assignments in ''Settings > Site administration > Users > Permissions > Unsupported role assignments''.
Prior to Moodle 2.0, there was no 'Context types where this role may be assigned' setting in the edit role form, and so any role could be assigned in any context. Upon upgrading a site from 1.9, any role assignments in contexts that make no sense for that role are listed as unsupported role assignments.


In general, it is safe to delete all unsupported role assignments. In doing so, the worst that can happen is for a user to be unassigned a custom role; no other data loss will occur.
In general, it is safe to delete all unsupported role assignments. In doing so, the worst that can happen is for a user to be unassigned a custom role; no other data loss will occur.
===Is it possible to remove the open door with green arrow icon that represents Self enrolment? Disable Self enrolment altogether?===
Yes, as an Administrator, go into
  Site Administration > Plugins > Authentication > Manage Authentication
In Common Settings, turn Self Registration to Disable and then if you do not want the Guest login button to show, turn it to Hide. Consider also the Authentication methods you want to use, you can set them on by clicking on any closed eye. This removes the self enrolment option completely.
If you just want to remove/hide the icon and not remove the ability to self enrol then you can take one of a couple of different options.
The Self Enrolment icon itself is theme dependent which means it is not always an open door with a green arrow. One way would be to replace it in whichever theme you are using with a transparent png of the same size. If you use something like Firebug, click on the icon to see its properties, (right click in Windows, or Cmd+Click in Mac) you should be able to see the path to the icon and its name - then you replace it with a file of the same name which is transparent (ie, invisible, hopefully) or one pixel by one pixel.
You can isolate the image and disable it using CSS but first you need to know the css path for that image.
For the Front Page it is this...
  #page-site-index .enrolmenticons {visibility: hidden;}
Depending on your theme, you can either add the CSS to your theme's Custom Settings page, or add that CSS rule directly into yourtheme/style/core.css  or whatever name your CSS stylesheet is called.  If you add the CSS to the stylesheet you need to add it at the very bottom of that file.
Before you do any of this it is best enabling Theme Designer Mode from Site Administration > Appearance > themes > Theme settings as this will allow the changes to be seen. You will also need to refresh your browser window to using Ctrl + F5 which forces the page to reload. Or, you can click the Clear Theme Caches button in the Site Administration > Appearance > themes > Theme selector page.
Thanks to Mary Cooch and Mary Evans.


[[Category:Site administration]]
[[Category:Site administration]]
Line 125: Line 109:
[[fr:Réglages des rôles]]
[[fr:Réglages des rôles]]
[[ja:ユーザポリシー]]
[[ja:ユーザポリシー]]
[[es:Configuraciones de roles]]
[[es:Políticas para el usuario]]

Latest revision as of 10:54, 28 March 2022


User policies

The following settings may be changed by an administrator in User policies in the Site administration.

Role for visitors

Users who are not logged in to the site will be treated as if they have the role specified here, granted to them at the site context. The role of Guest is the default and the recommended setting for standard Moodle sites. The user will still be required to login to participate in an activity.

Role for guest

This option specifies the role that will automatically be assigned to the guest user. This role is also temporarily assigned to non enrolled users when they enter a course that allows guests without password.

(If you wish to deny guest access to a site altogether, the guest login button should be set to hide in Manage authentication in the Site administration.)

Default role for all users

It is recommended that the default role for all users is set to Authenticated user. To set it to a custom role, the custom role must be assignable in the system context and have role archetype set to none.

Note: It is not recommended that the default role for all users is set to student.

Creators' role in new courses

Moodle will automatically enroll the user creating a new course in the course with the role specified in this setting. Moodle checks that the role used for creating the course e.g. "Course creator" has the right to assign the specified role in the new course. This means that the following capabilities needs to be set on the course creator role before the user is enrolled automatically :

  • moodle/course:create | Allow
  • moodle/course:manageactivities | Allow
  • moodle/course:viewparticipants | Allow
  • moodle/role:assign | Allow

If the course creator role is not setup correctly the user will be enrolled in the course without any roles.

Auto-login guest

If not set, then visitors must click the "Login as a guest" button before entering a course which allows guest access.

Note: If auto-login guest is set, the guest login button also needs to be set to show in Manage authentication in the Site administration, even though visitors won't necessarily use it.

Hide user fields

The following user fields appear on users' profile pages. Certain user fields are also listed on the course participants page. You can increase student privacy by hiding selected user fields.

Description, city/town, country, web page, ICQ number, Skype ID, Yahoo ID, AIM ID, MSN ID, last access, My courses and first access and groups

Show user identity

Any of the following fields may be shown to users with the capability moodle/site:viewuseridentity when searching for users and displaying lists of users.

This setting is useful for sites with large number of users, where the likelihood of users with the same name is high.

  • Username
  • ID number
  • Email address
  • Phone number
  • Mobile phone
  • Department
  • Institution
  • City/town
  • Country


New feature
in Moodle 3.11!
New in 3.11: Custom profile fields (shown with an asterisk against their name) may now be selected to appear in certain locations. Note that only "Text input" fields are currently supported, and that their character limit must not exceed 255.

Locations where user identity fields are shown are as follows:

Tip: Select only one or two fields that are mandatory at your institution. Do not select more than two fields otherwise tables become very wide.

Full name format

See Additional name fields for details, also about the alternative full name format.

Maximum users per page

You can choose here the maximum number of users to be displayed when searching in courses, groups, cohorts etc. The default is 100 but if your Moodle site is very large you can increase the number here.

Enable Gravatar

Gravatar (an abbreviation for globally recognized avatar) is a third party service for providing globally personal avatars.

If Gravatar service is enabled by the administrator and a user has not uploaded any user picture, Moodle will check whether the user's email address has an associated gravatar account and if so, will use the gravatar as the user's picture.

Gravatar default image URL

If gravatars are enabled, an alternative default user picture may be specified. The options are:

If the field is left empty then the theme's default user picture is used.

Unsupported role assignments

Unsupported role assignments are role assignments in contexts that make no sense for that role, such as the course creator role in the course or activity context, or the teacher role in the user context.

Prior to Moodle 2.0, there was no 'Context types where this role may be assigned' setting in the edit role form, and so any role could be assigned in any context. Upon upgrading a site from 1.9, any role assignments in contexts that make no sense for that role are listed as unsupported role assignments.

In general, it is safe to delete all unsupported role assignments. In doing so, the worst that can happen is for a user to be unassigned a custom role; no other data loss will occur.