https://docs.moodle.org/dev/api.php?action=feedcontributions&feedformat=atom&user=CmcqueenMoodleDocs - User contributions [en]2026-04-12T09:48:30ZUser contributionsMediaWiki 1.43.5https://docs.moodle.org/dev/index.php?title=Student_Information_API&diff=2611Student Information API2008-02-24T11:44:42Z<p>Cmcqueen: </p>
<hr />
<div>Some standards:<br />
* [http://www.pesc.org/ PESC - Postsecondary Electronic Standards Council]<br />
* [http://www.sifinfo.org/sif-specification.asp SIF Specification]<br />
*[[IMS Enterprise]]<br />
<br />
Some notes:<br />
* In the UK the Becta has made a strategic case for SIF being adopted as the standard for interoperability between MIS systems, Learning Platforms (VLEs etc.) and other database systems that carry data for UK education. The UK SIF version 1.0 data model has been published and the next version 1.1 is available for review. See [http://uk.sifinfo.org/]<br />
* In the UK the dominant Information Management system is SIMS.net from Capita. This has a restricted IMS web services profile to connect to. See [http://moodle.org/mod/forum/discuss.php?d=15012&parent=245946] Capita also have adopted the SIF data model and transport mechanism for their Partnership Exchange Server, a SIF Zone Integration Server which targets 14-19 diploma requirements. The diplomas will require MIS systems in secondary schools and sixth form colleges to have data interoperability for student information including attendance and assessment data.<br />
<br />
Things to pass out:<br />
<br />
* Grades<br />
* Outcomes<br />
* Calendar events<br />
<br />
[[Category:Student Information API]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Using_XMLDB&diff=7749Using XMLDB2008-02-23T18:34:09Z<p>Cmcqueen: /* What is XMLDB and how can it help you */</p>
<hr />
<div>{{Moodle 1.7}}Note: This page is a work in progress. It is intended to help developers of third-party modules, and other plugins, to help them switch to XMLDB.<br />
<br />
==What is XMLDB and how can it help you==<br />
<br />
XMLDB stores the database definition in an XML format that can be used to install Moodle on any database. Everywhere in Moodle now uses XMLDB.<br />
<br />
In every module (or other plugin) folder, there is a ''db/'' folder where the database structure is stored. In the past, this used to contain separate files ''mysql.php'', ''mysql.sql'', etc. for different databases. It meant that you had to create different files for each database system. If there were more databases you wanted your module to be compatible with, you had to create more files. Switching to XMLDB means that you only have to create one file, and there is an editor to help you, so it saves you time.<br />
<br />
==Getting started==<br />
<br />
The XMLDB database definition is stored in the file ''db/install.xml''. You can use a built-in XMLDB editor to create or edit any ''install.xml'' files. If you're using MySQL as your default database schemes. XMLDB editor's powerful tools allowing retrofit MySQL table to XMLDB format.<br />
<br />
The XMLDB editor is located in administration block, go to ''Miscellaneous > XMLDB editor''. Find your module name. Initially you won't be able to click on ''Create'' link and also can't edit your module (If the ''Create'' link is clickable you can skip this step). Since you must make your module folder has write permission first (And if you haven't created ''db/'' folder in your module folder yet, create it now). In Linux operating system, ''chmod'' your ''/db'' folder to 777 solves this. Now you're ready to create your module's XMLDB files.<br />
<br />
Note that XMLDB editor is not a tool for creating your module, though it can help you with the database. It is a tool to manage XMLDB database file (think about phpmyadmin manages SQL database). You can create tables/fields/keys/indexes or export your existing MySQL tables to XMLDB.<br />
<br />
Another XMLDB's advantage is you can create table comments as you want. To describe it to other developer.<br />
<br />
XMLDB editor is really easy to work with. We strongly recommend you to play with it for a while and read [[XMLDB editor]] and about XMLDB structure [[XMLDB defining an XML structure]].<br />
<br />
===Create ''install.xml''===<br />
<br />
If you never create ''install.xml'' before (your ''db/'' doesn't have ''install.xml''), click ''Create'' first. install.xml will store your database info for this module.<br />
<br />
===Start editing===<br />
<br />
To start editing ''install.xml'', click ''Load'' and then ''Edit''. You need to do this every time before editing any XMLDB file. If this is your first time, there is a default table named like your module stored.<br />
<br />
===Create new table===<br />
<br />
# Go to ''New Table''.<br />
# Enter table name and comment, click ''change''.<br />
<br />
===Add field in table===<br />
<br />
# Click ''Edit'' on your desired table.<br />
# Click ''New Field'', You can now edit field information like name, comment, type, length, etc. See [[XMLDB column types] for XMLDB column type comparing with other database system.<br />
# When you're done, click ''Change''.<br />
<br />
===Retrofit MySQL table to XMLDB===<br />
<br />
XMLDB editor can retrofit MySQL table to XMLDB. In other word, it can create XMLDB table from existing SQL. This is useful if your module database already using MySQL.<br />
First, your module has to be installed. Then follow these steps:<br />
<br />
# Click ''New Table from MySQL''<br />
# In ''Create Table'' box, choose your table from MySQL database. In ''After Table'' choose where would you like to add this table to (It doesn't matter, just for arrangement). Click ''Create''.<br />
# Do it again until every table added, you are done!<br />
<br />
Note: Table name must contains only lowercase character, number, underscore and length must not exceed 28 characters. More info here: [[XMLDB defining an XML structure]]<br />
<br />
===Other operation===<br />
<br />
It's intuitive once you use it. There are visible links for editing, moving up or down and deleting.<br />
<br />
==See also==<br />
<br />
*[[XMLDB editor]]<br />
*[[XMLDB introduction]]<br />
*[[XMLDB defining an XML structure]]<br />
*[[XMLDB column types]]<br />
<br />
[[Category:Using XMLDB]]<br />
[[Category:XMLDB]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Student_Information_API&diff=2610Student Information API2008-01-26T15:02:04Z<p>Cmcqueen: </p>
<hr />
<div>Some standards:<br />
* [http://www.pesc.org/ PESC - Postsecondary Electronic Standards Council]<br />
* [http://www.sifinfo.org/sif-specification.asp SIF Specification]<br />
*[[IMS Enterprise]]<br />
<br />
Some notes:<br />
* In the UK the dominant Information Management system is SIMS.net from Capita. This has a restricted IMS web services profile to connect to. See [http://moodle.org/mod/forum/discuss.php?d=15012&parent=245946]<br />
* In the UK the Becta has made a strategic case for SIF being adopted as the standard for interoperability between MIS systems and Learning Platforms (VLEs etc.). The UK SIF version 1.0 data model has been published. See [http://uk.sifinfo.org/]<br />
<br />
<br />
Things to pass out:<br />
<br />
* Grades<br />
* Outcomes<br />
* Calendar events<br />
<br />
[[Category:Student Information API]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Student_Information_API&diff=2609Student Information API2008-01-26T15:01:31Z<p>Cmcqueen: </p>
<hr />
<div>Some standards:<br />
* [http://www.pesc.org/ PESC - Postsecondary Electronic Standards Council]<br />
* [http://www.sifinfo.org/sif-specification.asp SIF Specification]<br />
*[[IMS Enterprise]]<br />
<br />
Some notes:<br />
* In the UK the dominant Information Management system is SIMS.net from Capita. This has a restricted IMS web services profile to connect to. See [http://moodle.org/mod/forum/discuss.php?d=15012&parent=245946]<br />
* In the UK the Becta has made a stregic case for SIF as the standard for interoperability across MIS systems and Learning Platforms (VLEs etc.). The UK SIF version 1.0 data model has been published. See [http://uk.sifinfo.org/]<br />
<br />
<br />
Things to pass out:<br />
<br />
* Grades<br />
* Outcomes<br />
* Calendar events<br />
<br />
[[Category:Student Information API]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Student_Information_API&diff=2606Student Information API2006-10-27T21:25:29Z<p>Cmcqueen: </p>
<hr />
<div>Some standards:<br />
* [http://www.pesc.org/ PESC - Postsecondary Electronic Standards Council]<br />
* [http://www.sifinfo.org/sif-specification.asp SIF Specification]<br />
*[[IMS Enterprise]]<br />
<br />
Some notes:<br />
* In the UK the dominant Information Management system is SIMS.net from Capita. This has a restricted IMS web services profile to connect to. See [http://moodle.org/mod/forum/discuss.php?d=15012&parent=245946]<br />
<br />
Things to pass out:<br />
<br />
* Grades<br />
* Outcomes<br />
* Calendar events<br />
<br />
<br />
[[Category:Future]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Grades&diff=4361Grades2006-08-05T08:50:51Z<p>Cmcqueen: /* Other ideas */</p>
<hr />
<div>This page is to create a specification for the next generation of Moodle gradebook. If you edit it, please try and keep modifications under the correct headings.<br />
<br />
==Centralising data==<br />
<br />
Currently (in all versions up to 1.6) Moodle uses a "pull" model for grade collection. That is, at the time a user requests a view of the gradebook, each activity module is polled for grades and either returns grades or it doesn't. These are then massaged into the gradebook view.<br />
<br />
Problems with this are bad performance and less flexibility.<br />
<br />
In the next version, the modules must "push" their grades to the central gradebook at the time grades are changed. For example, if a student completes a quiz, the quiz module should call a central function such as grade_store() with courseid, userid, moduleid, column name, grade type and grade. This data gets stored in a central table (like grades). <br />
<br />
Modules can store grades internally as well if they want to (for efficiency and reports etc). All storing of grades centrally should take place via the API function: modules must not manipulate the grades table directly.<br />
<br />
An option in the gradebook should allow grades to be retained even if the activity that generated it has been deleted. If this is turned off, then when displaying the columns, a clean-up function should check the course format, and remove columns belonging to obsolete activities.<br />
<br />
For backward compatibility, a Moodle cron trigger should cause the gradebook to periodically look in activity modules for an old-style xxxx_grades() function, then call that function to extract and cache grades locally.<br />
<br />
==Additional columns==<br />
<br />
With a centralised table, it should be easier to add support for manual or ad-hoc calculation columns that are not connected to any activity table.<br />
<br />
For example, a final course grade column could be created that is a mathematical calculation based on other columns. Syntax could be provided to make the column empty unless all the other columns contain a value of some kind (for that user).<br />
<br />
==Export API==<br />
<br />
A great need is to connect grades to external systems, such as Student Information Systems.<br />
<br />
A plugin system should be added that can export grades to external systems, either at the time grades are added or via cron. The plugins take care of which data is chosen and where it goes. <br />
<br />
==Other ideas==<br />
There are multiple contributed addons that allow for grading of activities that do not take place within moodle. This is necessary to allow teachers to only use moodle's gradebook for grade entry. A modular grade import system would naturally follow.<br />
<br />
Graphing plug-in?<br />
<br />
So that data from the gradebook can create graphs/charts but also so people could easily extend the type of graph/charts available by writing extensions for the plug-in.<br />
<br />
Grading scheme plug-in interface?<br />
<br />
So that the dominant USA High School/College format can be changed to grading for other countries and year groups. Schemes could be created by either programmers or maybe even a forms interface for teachers to create schemes and save them off for sharing between teachers and across courses. Probably incorporating the scales used within it.<br />
<br />
==See also==<br />
<br />
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=51107 New gradebook for Moodle] forum discussion<br />
<br />
<br />
[[Category:Grades]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2994Roles2006-07-22T18:31:13Z<p>Cmcqueen: /* Librarian */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capability($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might need refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. It is important that capability names are unique. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
Certainly need a canview or cansee capability for parents as linked to their child's data/contributions.<br />
<br />
Do we need to add canview and cansearch logs at site/course/user/group level?<br />
<br />
I could use a canview at a course level, if I understand what that means exactly.--[[User:N Hansen|N Hansen]] 19:43, 12 June 2006 (WST)<br />
<br />
<br />
<br />
===Core-level Capabilities===<br />
<br />
Moodle core capabilitie names start with 'moodle/'. The capabilities for the Moodle core are defined in lib/db/access.php<br />
Do we still keep student view? What is a student view?<br />
<br />
#moodle/site:config - applicable in admin/index.php and config.php (might break down later)<br />
#moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now)<br />
#moodle/site:backup - can create a course backup<br />
#moodle/site:restore - can restore into this context<br />
#moodle/site:import - can import other courses into this context<br />
#moodle/blog:view - read blogs<br />
#moodle/blog:create - write new blog posts<br />
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use<br />
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use<br />
#moodle/blog:manageentries - edit/delete all blog entries<br />
#moodle/course:create - create courses<br />
#moodle/course:delete - create courses<br />
#moodle/course:update - update course settings<br />
#moodle/course:view - can use this to find participants<br />
#moodle/course:viewparticipants - allows a user to view participant list<br />
#moodle/course:viewscales - view scales (i.e. in a help window?)<br />
#moodle/course:manageactivities - adding/removing/editing activities and resources (don't think it makes any sense to split these)<br />
#moodle/course:managescales - add, delete, edit scales, move scales up and down<br />
#moodle/course:managegroups - managing groups, add, edit, delete<br />
#moodle/course:visibility - hide/show courses<br />
#moodle/category:create - create category<br />
#moodle/category:delete - create category<br />
#moodle/category:update - update category settings<br />
#moodle/category:visibility - hide/show categories<br />
#moodle/user:create - create user<br />
#moodle/user:delete - create user<br />
#moodle/user:update - update user settings<br />
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo). This ties in with the "visitor" scenario described below.<br />
#moodle/calendar:manageownentries - create/edit/delete <br />
#moodle/calendar:manageentries - create/edit/delete<br />
<br />
===Module-level Capabilities===<br />
The capabilities are cached into a database table when a module is installed or updated. Whenever the capability definitions are updated, the module version number should be bumped up so that the database table can be updated.<br />
<br />
The naming convention for capabilities that are specific to modules and blocks is 'mod/mod_name:capability'. The module capabilities are defined in mod/mod_name/db/access.php.<br />
<br />
#Assignment<br />
##mod/assignment:view- reading the assignment description<br />
##mod/assignment:grade - grading, viewing of list of submitted assignments<br />
#Chat<br />
##mod/chat:chat - allows a user to participate in this chat<br />
##mod/chat:readlog - allows a user to read past chat session logs<br />
##mod/chat:deletelog - allows a user to delete past chat logs<br />
#Choice<br />
##mod/choice:choose - make a choice<br />
##mod/choice:readresponses - read all responses<br />
##mod/choice:deleteresponses - deletes all responses<br />
##mod/choice:downloadresponses - download responses<br />
#Database<br />
##mod/data:readentry - reads other people's entry<br />
##mod/data:writeentry - add / edit and delete (own) entries<br />
##mod/data:managetemplates - add, delete, edit fields and templates<br />
##mod/data:manageentries - edit/delete all entries<br />
##mod/data:comment - comment<br />
##mod/data:managecomments - edit/delete all comments<br />
##mod/data:rate - rate an entry<br />
##mod/data:approve - approves an entry<br />
##mod/data:uploadentries - batch upload of entries<br />
#Exercise<br />
##mod/exercise:assess<br />
#Forum<br />
##mod/forum:viewforum<br />
##mod/forum:viewdiscussion<br />
##mod/forum:viewdiscussionsfromallgroups<br />
##mod/forum:startdiscussion<br />
##mod/forum:replypost<br />
##mod/forum:viewrating<br />
##mod/forum:rate<br />
##mod/forum:attachments<br />
##mod/forum:deleteownpost<br />
##mod/forum:deleteanypost<br />
##mod/forum:splitdiscussions<br />
##mod/forum:movediscussions<br />
##mod/forum:editanypost<br />
#Glossary<br />
##mod/glossary:view - read entries<br />
##mod/glossary:write - add entries<br />
##mod/glossary:manageentries - add, edit, delete entries<br />
##mod/glossary:managecategories - create, delete, edit categories<br />
##mod/glossary:comment - comment on an entry<br />
##mod/glossary:managecomments - edit, delete comments<br />
##mod/glossary:import - import glossaries<br />
##mod/glossary:export - export glossaries<br />
##mod/glossary:approve - approve glossaries<br />
##mod/glossary:rate - rates glossary<br />
##mod/glossary:readrate - view rating?<br />
#Hotpot<br />
##mod/hotpot:view<br />
#Label<br />
##none<br />
#Lams<br />
##TBD<br />
#Lesson<br />
##TBD<br />
#Quiz<br />
##TBD<br />
#Resource<br />
##mod/resource:view<br />
#Scorm<br />
##mod/scorm:view<br />
##mod/scorm:viewgrades<br />
#Survey<br />
##mod/survey:download - downloads survery result<br />
##mod/survey:participate - participate/ do survey<br />
##mod/survey:readresponses - read all user's responese<br />
#Wiki<br />
##Waiting on new wiki<br />
#Workshop<br />
##Waiting on new Workshop<br />
<br />
<br />
<br />
==Questions==<br />
I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in [http://www.moodle.org/bugs/bug.php?op=show&bugid=6118&pos= bug 6118].<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Student===<br />
Has this one been missed?<br />
<br />
===Site Designers===<br />
Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br />
<br />
===Educational Authority Adviser===<br />
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br />
<br />
===Educational Inspector===<br />
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br />
<br />
===Second Marker / Moderator===<br />
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.<br />
<br />
===Peer observer of teaching===<br />
Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).<br />
<br />
===External Examiner===<br />
Has all the rights of inpectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br />
<br />
In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.<br />
<br />
In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?<br />
<br />
Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
Is this the same as '''ALUMNUS''' ? An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --[[User:Anil Sharma|Anil Sharma]] 20:54, 15 July 2006 (WST)<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity. <br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity.<br />
<br />
I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)<br />
<br />
===Community Education Tutors/Trainers===<br />
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.<br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
===Admin - Catgory based===<br />
<br />
Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.<br />
<br />
===PROCESS ROLES===<br />
<br />
organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:<br />
<li>1. Give a student the role of forum-moderator with edit and chunk-rights<br />
<li>2. Give students different roles & rights in a Webquest design (and change these roles next week<br />
<li>3. Give students different resources, depending of their roles in a rolegame/simulation<br />
<li>4. Give a student the rights to create the section content of next week (and only that week..)<br />
<li>5. ..<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]<br />
<br />
<br />
[[ru:Роли]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2993Roles2006-07-22T18:26:48Z<p>Cmcqueen: /* Parent */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capability($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might need refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. It is important that capability names are unique. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
Certainly need a canview or cansee capability for parents as linked to their child's data/contributions.<br />
<br />
Do we need to add canview and cansearch logs at site/course/user/group level?<br />
<br />
I could use a canview at a course level, if I understand what that means exactly.--[[User:N Hansen|N Hansen]] 19:43, 12 June 2006 (WST)<br />
<br />
<br />
<br />
===Core-level Capabilities===<br />
<br />
Moodle core capabilitie names start with 'moodle/'. The capabilities for the Moodle core are defined in lib/db/access.php<br />
Do we still keep student view? What is a student view?<br />
<br />
#moodle/site:config - applicable in admin/index.php and config.php (might break down later)<br />
#moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now)<br />
#moodle/site:backup - can create a course backup<br />
#moodle/site:restore - can restore into this context<br />
#moodle/site:import - can import other courses into this context<br />
#moodle/blog:view - read blogs<br />
#moodle/blog:create - write new blog posts<br />
#moodle/blog:manageofficialtags - create/delete official blog tags that others can use<br />
#moodle/blog:managepersonaltags - create/delete official blog tags that others can use<br />
#moodle/blog:manageentries - edit/delete all blog entries<br />
#moodle/course:create - create courses<br />
#moodle/course:delete - create courses<br />
#moodle/course:update - update course settings<br />
#moodle/course:view - can use this to find participants<br />
#moodle/course:viewparticipants - allows a user to view participant list<br />
#moodle/course:viewscales - view scales (i.e. in a help window?)<br />
#moodle/course:manageactivities - adding/removing/editing activities and resources (don't think it makes any sense to split these)<br />
#moodle/course:managescales - add, delete, edit scales, move scales up and down<br />
#moodle/course:managegroups - managing groups, add, edit, delete<br />
#moodle/course:visibility - hide/show courses<br />
#moodle/category:create - create category<br />
#moodle/category:delete - create category<br />
#moodle/category:update - update category settings<br />
#moodle/category:visibility - hide/show categories<br />
#moodle/user:create - create user<br />
#moodle/user:delete - create user<br />
#moodle/user:update - update user settings<br />
#moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo). This ties in with the "visitor" scenario described below.<br />
#moodle/calendar:manageownentries - create/edit/delete <br />
#moodle/calendar:manageentries - create/edit/delete<br />
<br />
===Module-level Capabilities===<br />
The capabilities are cached into a database table when a module is installed or updated. Whenever the capability definitions are updated, the module version number should be bumped up so that the database table can be updated.<br />
<br />
The naming convention for capabilities that are specific to modules and blocks is 'mod/mod_name:capability'. The module capabilities are defined in mod/mod_name/db/access.php.<br />
<br />
#Assignment<br />
##mod/assignment:view- reading the assignment description<br />
##mod/assignment:grade - grading, viewing of list of submitted assignments<br />
#Chat<br />
##mod/chat:chat - allows a user to participate in this chat<br />
##mod/chat:readlog - allows a user to read past chat session logs<br />
##mod/chat:deletelog - allows a user to delete past chat logs<br />
#Choice<br />
##mod/choice:choose - make a choice<br />
##mod/choice:readresponses - read all responses<br />
##mod/choice:deleteresponses - deletes all responses<br />
##mod/choice:downloadresponses - download responses<br />
#Database<br />
##mod/data:readentry - reads other people's entry<br />
##mod/data:writeentry - add / edit and delete (own) entries<br />
##mod/data:managetemplates - add, delete, edit fields and templates<br />
##mod/data:manageentries - edit/delete all entries<br />
##mod/data:comment - comment<br />
##mod/data:managecomments - edit/delete all comments<br />
##mod/data:rate - rate an entry<br />
##mod/data:approve - approves an entry<br />
##mod/data:uploadentries - batch upload of entries<br />
#Exercise<br />
##mod/exercise:assess<br />
#Forum<br />
##mod/forum:viewforum<br />
##mod/forum:viewdiscussion<br />
##mod/forum:viewdiscussionsfromallgroups<br />
##mod/forum:startdiscussion<br />
##mod/forum:replypost<br />
##mod/forum:viewrating<br />
##mod/forum:rate<br />
##mod/forum:attachments<br />
##mod/forum:deleteownpost<br />
##mod/forum:deleteanypost<br />
##mod/forum:splitdiscussions<br />
##mod/forum:movediscussions<br />
##mod/forum:editanypost<br />
#Glossary<br />
##mod/glossary:view - read entries<br />
##mod/glossary:write - add entries<br />
##mod/glossary:manageentries - add, edit, delete entries<br />
##mod/glossary:managecategories - create, delete, edit categories<br />
##mod/glossary:comment - comment on an entry<br />
##mod/glossary:managecomments - edit, delete comments<br />
##mod/glossary:import - import glossaries<br />
##mod/glossary:export - export glossaries<br />
##mod/glossary:approve - approve glossaries<br />
##mod/glossary:rate - rates glossary<br />
##mod/glossary:readrate - view rating?<br />
#Hotpot<br />
##mod/hotpot:view<br />
#Label<br />
##none<br />
#Lams<br />
##TBD<br />
#Lesson<br />
##TBD<br />
#Quiz<br />
##TBD<br />
#Resource<br />
##mod/resource:view<br />
#Scorm<br />
##mod/scorm:view<br />
##mod/scorm:viewgrades<br />
#Survey<br />
##mod/survey:download - downloads survery result<br />
##mod/survey:participate - participate/ do survey<br />
##mod/survey:readresponses - read all user's responese<br />
#Wiki<br />
##Waiting on new wiki<br />
#Workshop<br />
##Waiting on new Workshop<br />
<br />
<br />
<br />
==Questions==<br />
I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in [http://www.moodle.org/bugs/bug.php?op=show&bugid=6118&pos= bug 6118].<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Student===<br />
Has this one been missed?<br />
<br />
===Site Designers===<br />
Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br />
<br />
===Educational Authority Adviser===<br />
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br />
<br />
===Educational Inspector===<br />
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br />
<br />
===Second Marker / Moderator===<br />
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.<br />
<br />
===Peer observer of teaching===<br />
Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).<br />
<br />
===External Examiner===<br />
Has all the rights of inpectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br />
<br />
In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.<br />
<br />
In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?<br />
<br />
Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
Is this the same as '''ALUMNUS''' ? An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --[[User:Anil Sharma|Anil Sharma]] 20:54, 15 July 2006 (WST)<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity. <br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity.<br />
<br />
I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)<br />
<br />
===Community Education Tutors/Trainers===<br />
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.<br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
===Admin - Catgory based===<br />
<br />
Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.<br />
<br />
===PROCESS ROLES===<br />
<br />
organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:<br />
<li>1. Give a student the role of forum-moderator with edit and chunk-rights<br />
<li>2. Give students different roles & rights in a Webquest design (and change these roles next week<br />
<li>3. Give students different resources, depending of their roles in a rolegame/simulation<br />
<li>4. Give a student the rights to create the section content of next week (and only that week..)<br />
<li>5. ..<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]<br />
<br />
<br />
[[ru:Роли]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=User:Colin_McQueen&diff=19822User:Colin McQueen2006-05-25T15:40:47Z<p>Cmcqueen: </p>
<hr />
<div>UK based teacher and Local Authority Consultant on Learning Platforms looking to ensure Moodle is included in the Becta Learning Platform list of approved platforms.</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2897Roles2006-05-25T15:33:58Z<p>Cmcqueen: /* Scenarios */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.<br />
<br />
Do we need to add canview and cansearch logs at site/course/user/group level?<br />
<br />
===Site-level Capabilities===<br />
<br />
#canreadblogs<br />
#canpostblogs<br />
#candeleteallblogs<br />
#canbrowseuser<br />
#canviewhiddenactivity<br />
#cancreatecourse<br />
#caneditownprofile<br />
#caneditallprofiles<br />
<br />
===Course-level Capabilities===<br />
<br />
#canseecoursecontent<br />
#caneditcourse<br />
#cancreatebackups<br />
#canrestorebackups<br />
#cancreateblocks<br />
#caneditblocks<br />
#candeleteblocks<br />
<br />
===Module-level Capabilities===<br />
<br />
#Assignment<br />
##assignment_canadd<br />
##assignment_canedit<br />
##assignment_candelete<br />
##assignment_cansubmit<br />
##assignment_canmark<br />
##assignment_canviewsubmissions<br />
#Chat<br />
##chat_canadd<br />
##chat_canedit<br />
##chat_candelete<br />
##chat_canparticipate<br />
##chat_canviewpastsessions<br />
#Choice<br />
##choice_canadd<br />
##choice_canedit<br />
##choice_candelete<br />
##choice_canparticipate<br />
##choice_canviewresponses<br />
#Database<br />
##database_canadd<br />
##database_canedit<br />
##databaes_candelete<br />
##database_canaddentry<br />
##database_canaddtemplates<br />
##database_canedittemplates<br />
##database_candeleteownentry<br />
##database_candeleteallentry<br />
##database_cancomment<br />
##database_candeletecomment<br />
##database_canrate<br />
#Exercise<br />
##exercise_canadd<br />
##exercise_canedit<br />
##exercise_candelete<br />
##exercise_canassess<br />
#Forum<br />
##forum_canadd<br />
##forum_canedit<br />
##forum_candelete<br />
##forum_canreadpost<br />
##forum_canstartnewdiscussion<br />
##forum_canreply<br />
##forum_caneditallpost<br />
##forum_candeleteallpost<br />
##forum_canrate<br />
#Glossary<br />
##glossary_canadd<br />
##glossary_canedit<br />
##glossary_candelete<br />
##glossary_canaddcat<br />
##glossary_caneditcat<br />
##glossary_candeletecat<br />
##glossary_canadditem<br />
##glossary_candeleteitem<br />
##glossary_canedititem<br />
##glossary_cancomment<br />
##glossary_canimportentries<br />
##glossary_canexportentries<br />
##glossary_canapprove<br />
#Hotpot<br />
##hotpot_candd<br />
##hotpot_canedit<br />
##hotpot_candelete<br />
##hotpot_canparticipate<br />
#Label<br />
##label_canadd<br />
##label_canedit<br />
##label_candelete<br />
#Lams<br />
##lams_canadd<br />
##lams_canedit<br />
##lams_candelete<br />
#Lesson<br />
##lesson_canadd<br />
##lesson_canedit<br />
##lesson_candelete<br />
##lesson_canparticipate<br />
#Quiz<br />
##quiz_canadd<br />
##quiz_canedit<br />
##quiz_candelete<br />
##quiz_canaddquestion<br />
##quiz_caneditquestion<br />
##quiz_candeletequestion<br />
##quiz_canparticipate<br />
##quiz_cangrade<br />
#Resource<br />
##resource_canadd<br />
##resource_canedit<br />
##resource_candelete<br />
#Scorm<br />
##scorm_canadd<br />
##scorm_canedit<br />
##socrm_candelete<br />
#Survey<br />
##survey_canadd<br />
##survey_canedit<br />
##survey_candelete<br />
##survey_canviewresponses<br />
#Wiki<br />
##wiki_canadd<br />
##wiki_canedit<br />
##wiki_candelete<br />
##wiki_canstartnewwiki<br />
##wiki_canparticipate<br />
#Workshop<br />
##workshop_canadd<br />
##workshop_canedit<br />
##workshop_candelete<br />
##workshop_cangrade<br />
##workshop_canparticipate<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Student===<br />
Has this one been missed?<br />
<br />
===Site Designers===<br />
Is there a role for peole involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br />
<br />
===Educational Authority Adviser===<br />
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br />
<br />
===Educational Inspector===<br />
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br />
<br />
In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.<br />
<br />
In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.<br />
<br />
Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity. <br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity.<br />
<br />
===Community Education Tutors/Trainers===<br />
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.<br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2896Roles2006-05-25T15:31:36Z<p>Cmcqueen: /* Teacher */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.<br />
<br />
Do we need to add canview and cansearch logs at site/course/user/group level?<br />
<br />
===Site-level Capabilities===<br />
<br />
#canreadblogs<br />
#canpostblogs<br />
#candeleteallblogs<br />
#canbrowseuser<br />
#canviewhiddenactivity<br />
#cancreatecourse<br />
#caneditownprofile<br />
#caneditallprofiles<br />
<br />
===Course-level Capabilities===<br />
<br />
#canseecoursecontent<br />
#caneditcourse<br />
#cancreatebackups<br />
#canrestorebackups<br />
#cancreateblocks<br />
#caneditblocks<br />
#candeleteblocks<br />
<br />
===Module-level Capabilities===<br />
<br />
#Assignment<br />
##assignment_canadd<br />
##assignment_canedit<br />
##assignment_candelete<br />
##assignment_cansubmit<br />
##assignment_canmark<br />
##assignment_canviewsubmissions<br />
#Chat<br />
##chat_canadd<br />
##chat_canedit<br />
##chat_candelete<br />
##chat_canparticipate<br />
##chat_canviewpastsessions<br />
#Choice<br />
##choice_canadd<br />
##choice_canedit<br />
##choice_candelete<br />
##choice_canparticipate<br />
##choice_canviewresponses<br />
#Database<br />
##database_canadd<br />
##database_canedit<br />
##databaes_candelete<br />
##database_canaddentry<br />
##database_canaddtemplates<br />
##database_canedittemplates<br />
##database_candeleteownentry<br />
##database_candeleteallentry<br />
##database_cancomment<br />
##database_candeletecomment<br />
##database_canrate<br />
#Exercise<br />
##exercise_canadd<br />
##exercise_canedit<br />
##exercise_candelete<br />
##exercise_canassess<br />
#Forum<br />
##forum_canadd<br />
##forum_canedit<br />
##forum_candelete<br />
##forum_canreadpost<br />
##forum_canstartnewdiscussion<br />
##forum_canreply<br />
##forum_caneditallpost<br />
##forum_candeleteallpost<br />
##forum_canrate<br />
#Glossary<br />
##glossary_canadd<br />
##glossary_canedit<br />
##glossary_candelete<br />
##glossary_canaddcat<br />
##glossary_caneditcat<br />
##glossary_candeletecat<br />
##glossary_canadditem<br />
##glossary_candeleteitem<br />
##glossary_canedititem<br />
##glossary_cancomment<br />
##glossary_canimportentries<br />
##glossary_canexportentries<br />
##glossary_canapprove<br />
#Hotpot<br />
##hotpot_candd<br />
##hotpot_canedit<br />
##hotpot_candelete<br />
##hotpot_canparticipate<br />
#Label<br />
##label_canadd<br />
##label_canedit<br />
##label_candelete<br />
#Lams<br />
##lams_canadd<br />
##lams_canedit<br />
##lams_candelete<br />
#Lesson<br />
##lesson_canadd<br />
##lesson_canedit<br />
##lesson_candelete<br />
##lesson_canparticipate<br />
#Quiz<br />
##quiz_canadd<br />
##quiz_canedit<br />
##quiz_candelete<br />
##quiz_canaddquestion<br />
##quiz_caneditquestion<br />
##quiz_candeletequestion<br />
##quiz_canparticipate<br />
##quiz_cangrade<br />
#Resource<br />
##resource_canadd<br />
##resource_canedit<br />
##resource_candelete<br />
#Scorm<br />
##scorm_canadd<br />
##scorm_canedit<br />
##socrm_candelete<br />
#Survey<br />
##survey_canadd<br />
##survey_canedit<br />
##survey_candelete<br />
##survey_canviewresponses<br />
#Wiki<br />
##wiki_canadd<br />
##wiki_canedit<br />
##wiki_candelete<br />
##wiki_canstartnewwiki<br />
##wiki_canparticipate<br />
#Workshop<br />
##workshop_canadd<br />
##workshop_canedit<br />
##workshop_candelete<br />
##workshop_cangrade<br />
##workshop_canparticipate<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Site Designers===<br />
Is there a role for peole involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br />
<br />
===Educational Authority Adviser===<br />
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br />
<br />
===Educational Inspector===<br />
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br />
<br />
In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.<br />
<br />
In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.<br />
<br />
Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity. <br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity.<br />
<br />
===Community Education Tutors/Trainers===<br />
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.<br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2895Roles2006-05-25T15:26:24Z<p>Cmcqueen: /* Educational Authority Adviser */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.<br />
<br />
Do we need to add canview and cansearch logs at site/course/user/group level?<br />
<br />
===Site-level Capabilities===<br />
<br />
#canreadblogs<br />
#canpostblogs<br />
#candeleteallblogs<br />
#canbrowseuser<br />
#canviewhiddenactivity<br />
#cancreatecourse<br />
#caneditownprofile<br />
#caneditallprofiles<br />
<br />
===Course-level Capabilities===<br />
<br />
#canseecoursecontent<br />
#caneditcourse<br />
#cancreatebackups<br />
#canrestorebackups<br />
#cancreateblocks<br />
#caneditblocks<br />
#candeleteblocks<br />
<br />
===Module-level Capabilities===<br />
<br />
#Assignment<br />
##assignment_canadd<br />
##assignment_canedit<br />
##assignment_candelete<br />
##assignment_cansubmit<br />
##assignment_canmark<br />
##assignment_canviewsubmissions<br />
#Chat<br />
##chat_canadd<br />
##chat_canedit<br />
##chat_candelete<br />
##chat_canparticipate<br />
##chat_canviewpastsessions<br />
#Choice<br />
##choice_canadd<br />
##choice_canedit<br />
##choice_candelete<br />
##choice_canparticipate<br />
##choice_canviewresponses<br />
#Database<br />
##database_canadd<br />
##database_canedit<br />
##databaes_candelete<br />
##database_canaddentry<br />
##database_canaddtemplates<br />
##database_canedittemplates<br />
##database_candeleteownentry<br />
##database_candeleteallentry<br />
##database_cancomment<br />
##database_candeletecomment<br />
##database_canrate<br />
#Exercise<br />
##exercise_canadd<br />
##exercise_canedit<br />
##exercise_candelete<br />
##exercise_canassess<br />
#Forum<br />
##forum_canadd<br />
##forum_canedit<br />
##forum_candelete<br />
##forum_canreadpost<br />
##forum_canstartnewdiscussion<br />
##forum_canreply<br />
##forum_caneditallpost<br />
##forum_candeleteallpost<br />
##forum_canrate<br />
#Glossary<br />
##glossary_canadd<br />
##glossary_canedit<br />
##glossary_candelete<br />
##glossary_canaddcat<br />
##glossary_caneditcat<br />
##glossary_candeletecat<br />
##glossary_canadditem<br />
##glossary_candeleteitem<br />
##glossary_canedititem<br />
##glossary_cancomment<br />
##glossary_canimportentries<br />
##glossary_canexportentries<br />
##glossary_canapprove<br />
#Hotpot<br />
##hotpot_candd<br />
##hotpot_canedit<br />
##hotpot_candelete<br />
##hotpot_canparticipate<br />
#Label<br />
##label_canadd<br />
##label_canedit<br />
##label_candelete<br />
#Lams<br />
##lams_canadd<br />
##lams_canedit<br />
##lams_candelete<br />
#Lesson<br />
##lesson_canadd<br />
##lesson_canedit<br />
##lesson_candelete<br />
##lesson_canparticipate<br />
#Quiz<br />
##quiz_canadd<br />
##quiz_canedit<br />
##quiz_candelete<br />
##quiz_canaddquestion<br />
##quiz_caneditquestion<br />
##quiz_candeletequestion<br />
##quiz_canparticipate<br />
##quiz_cangrade<br />
#Resource<br />
##resource_canadd<br />
##resource_canedit<br />
##resource_candelete<br />
#Scorm<br />
##scorm_canadd<br />
##scorm_canedit<br />
##socrm_candelete<br />
#Survey<br />
##survey_canadd<br />
##survey_canedit<br />
##survey_candelete<br />
##survey_canviewresponses<br />
#Wiki<br />
##wiki_canadd<br />
##wiki_canedit<br />
##wiki_candelete<br />
##wiki_canstartnewwiki<br />
##wiki_canparticipate<br />
#Workshop<br />
##workshop_canadd<br />
##workshop_canedit<br />
##workshop_candelete<br />
##workshop_cangrade<br />
##workshop_canparticipate<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Site Designers===<br />
Is there a role for peole involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br />
<br />
===Educational Authority Adviser===<br />
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br />
<br />
===Educational Inspector===<br />
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br />
<br />
In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.<br />
<br />
In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.<br />
<br />
Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.<br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity. <br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2894Roles2006-05-25T15:25:59Z<p>Cmcqueen: /* Scenarios */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.<br />
<br />
Do we need to add canview and cansearch logs at site/course/user/group level?<br />
<br />
===Site-level Capabilities===<br />
<br />
#canreadblogs<br />
#canpostblogs<br />
#candeleteallblogs<br />
#canbrowseuser<br />
#canviewhiddenactivity<br />
#cancreatecourse<br />
#caneditownprofile<br />
#caneditallprofiles<br />
<br />
===Course-level Capabilities===<br />
<br />
#canseecoursecontent<br />
#caneditcourse<br />
#cancreatebackups<br />
#canrestorebackups<br />
#cancreateblocks<br />
#caneditblocks<br />
#candeleteblocks<br />
<br />
===Module-level Capabilities===<br />
<br />
#Assignment<br />
##assignment_canadd<br />
##assignment_canedit<br />
##assignment_candelete<br />
##assignment_cansubmit<br />
##assignment_canmark<br />
##assignment_canviewsubmissions<br />
#Chat<br />
##chat_canadd<br />
##chat_canedit<br />
##chat_candelete<br />
##chat_canparticipate<br />
##chat_canviewpastsessions<br />
#Choice<br />
##choice_canadd<br />
##choice_canedit<br />
##choice_candelete<br />
##choice_canparticipate<br />
##choice_canviewresponses<br />
#Database<br />
##database_canadd<br />
##database_canedit<br />
##databaes_candelete<br />
##database_canaddentry<br />
##database_canaddtemplates<br />
##database_canedittemplates<br />
##database_candeleteownentry<br />
##database_candeleteallentry<br />
##database_cancomment<br />
##database_candeletecomment<br />
##database_canrate<br />
#Exercise<br />
##exercise_canadd<br />
##exercise_canedit<br />
##exercise_candelete<br />
##exercise_canassess<br />
#Forum<br />
##forum_canadd<br />
##forum_canedit<br />
##forum_candelete<br />
##forum_canreadpost<br />
##forum_canstartnewdiscussion<br />
##forum_canreply<br />
##forum_caneditallpost<br />
##forum_candeleteallpost<br />
##forum_canrate<br />
#Glossary<br />
##glossary_canadd<br />
##glossary_canedit<br />
##glossary_candelete<br />
##glossary_canaddcat<br />
##glossary_caneditcat<br />
##glossary_candeletecat<br />
##glossary_canadditem<br />
##glossary_candeleteitem<br />
##glossary_canedititem<br />
##glossary_cancomment<br />
##glossary_canimportentries<br />
##glossary_canexportentries<br />
##glossary_canapprove<br />
#Hotpot<br />
##hotpot_candd<br />
##hotpot_canedit<br />
##hotpot_candelete<br />
##hotpot_canparticipate<br />
#Label<br />
##label_canadd<br />
##label_canedit<br />
##label_candelete<br />
#Lams<br />
##lams_canadd<br />
##lams_canedit<br />
##lams_candelete<br />
#Lesson<br />
##lesson_canadd<br />
##lesson_canedit<br />
##lesson_candelete<br />
##lesson_canparticipate<br />
#Quiz<br />
##quiz_canadd<br />
##quiz_canedit<br />
##quiz_candelete<br />
##quiz_canaddquestion<br />
##quiz_caneditquestion<br />
##quiz_candeletequestion<br />
##quiz_canparticipate<br />
##quiz_cangrade<br />
#Resource<br />
##resource_canadd<br />
##resource_canedit<br />
##resource_candelete<br />
#Scorm<br />
##scorm_canadd<br />
##scorm_canedit<br />
##socrm_candelete<br />
#Survey<br />
##survey_canadd<br />
##survey_canedit<br />
##survey_candelete<br />
##survey_canviewresponses<br />
#Wiki<br />
##wiki_canadd<br />
##wiki_canedit<br />
##wiki_candelete<br />
##wiki_canstartnewwiki<br />
##wiki_canparticipate<br />
#Workshop<br />
##workshop_canadd<br />
##workshop_canedit<br />
##workshop_candelete<br />
##workshop_cangrade<br />
##workshop_canparticipate<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Site Designers===<br />
Is there a role for peole involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br />
<br />
===Educational Authority Adviser===<br />
Someone who would want to browse the site and may be asked to comment or contibute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br />
<br />
===Educational Inspector===<br />
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br />
<br />
In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.<br />
<br />
In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.<br />
<br />
Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.<br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity. <br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2893Roles2006-05-25T15:12:49Z<p>Cmcqueen: /* Capabilities */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.<br />
<br />
Do we need to add canview and cansearch logs at site/course/user/group level?<br />
<br />
===Site-level Capabilities===<br />
<br />
#canreadblogs<br />
#canpostblogs<br />
#candeleteallblogs<br />
#canbrowseuser<br />
#canviewhiddenactivity<br />
#cancreatecourse<br />
#caneditownprofile<br />
#caneditallprofiles<br />
<br />
===Course-level Capabilities===<br />
<br />
#canseecoursecontent<br />
#caneditcourse<br />
#cancreatebackups<br />
#canrestorebackups<br />
#cancreateblocks<br />
#caneditblocks<br />
#candeleteblocks<br />
<br />
===Module-level Capabilities===<br />
<br />
#Assignment<br />
##assignment_canadd<br />
##assignment_canedit<br />
##assignment_candelete<br />
##assignment_cansubmit<br />
##assignment_canmark<br />
##assignment_canviewsubmissions<br />
#Chat<br />
##chat_canadd<br />
##chat_canedit<br />
##chat_candelete<br />
##chat_canparticipate<br />
##chat_canviewpastsessions<br />
#Choice<br />
##choice_canadd<br />
##choice_canedit<br />
##choice_candelete<br />
##choice_canparticipate<br />
##choice_canviewresponses<br />
#Database<br />
##database_canadd<br />
##database_canedit<br />
##databaes_candelete<br />
##database_canaddentry<br />
##database_canaddtemplates<br />
##database_canedittemplates<br />
##database_candeleteownentry<br />
##database_candeleteallentry<br />
##database_cancomment<br />
##database_candeletecomment<br />
##database_canrate<br />
#Exercise<br />
##exercise_canadd<br />
##exercise_canedit<br />
##exercise_candelete<br />
##exercise_canassess<br />
#Forum<br />
##forum_canadd<br />
##forum_canedit<br />
##forum_candelete<br />
##forum_canreadpost<br />
##forum_canstartnewdiscussion<br />
##forum_canreply<br />
##forum_caneditallpost<br />
##forum_candeleteallpost<br />
##forum_canrate<br />
#Glossary<br />
##glossary_canadd<br />
##glossary_canedit<br />
##glossary_candelete<br />
##glossary_canaddcat<br />
##glossary_caneditcat<br />
##glossary_candeletecat<br />
##glossary_canadditem<br />
##glossary_candeleteitem<br />
##glossary_canedititem<br />
##glossary_cancomment<br />
##glossary_canimportentries<br />
##glossary_canexportentries<br />
##glossary_canapprove<br />
#Hotpot<br />
##hotpot_candd<br />
##hotpot_canedit<br />
##hotpot_candelete<br />
##hotpot_canparticipate<br />
#Label<br />
##label_canadd<br />
##label_canedit<br />
##label_candelete<br />
#Lams<br />
##lams_canadd<br />
##lams_canedit<br />
##lams_candelete<br />
#Lesson<br />
##lesson_canadd<br />
##lesson_canedit<br />
##lesson_candelete<br />
##lesson_canparticipate<br />
#Quiz<br />
##quiz_canadd<br />
##quiz_canedit<br />
##quiz_candelete<br />
##quiz_canaddquestion<br />
##quiz_caneditquestion<br />
##quiz_candeletequestion<br />
##quiz_canparticipate<br />
##quiz_cangrade<br />
#Resource<br />
##resource_canadd<br />
##resource_canedit<br />
##resource_candelete<br />
#Scorm<br />
##scorm_canadd<br />
##scorm_canedit<br />
##socrm_candelete<br />
#Survey<br />
##survey_canadd<br />
##survey_canedit<br />
##survey_candelete<br />
##survey_canviewresponses<br />
#Wiki<br />
##wiki_canadd<br />
##wiki_canedit<br />
##wiki_candelete<br />
##wiki_canstartnewwiki<br />
##wiki_canparticipate<br />
#Workshop<br />
##workshop_canadd<br />
##workshop_canedit<br />
##workshop_candelete<br />
##workshop_cangrade<br />
##workshop_canparticipate<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children.<br />
<br />
In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.<br />
<br />
In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.<br />
<br />
Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.<br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity. <br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Roles&diff=2892Roles2006-05-25T15:09:16Z<p>Cmcqueen: /* Parent */</p>
<hr />
<div>'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.<br />
<br />
''Please note that none of the following is finalised.''<br />
<br />
==Definitions==<br />
<br />
By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.<br />
<br />
A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.<br />
<br />
==The existing system==<br />
<br />
Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br />
<br />
==The new roles and capability system==<br />
<br />
The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role. <br />
<br />
To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.<br />
<br />
''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''<br />
<br />
==The plan==<br />
<br />
There are a few major things that need to be done. Here's a list (in no particular order):<br />
<br />
#Identify permissions required for site/course/each module.<br />
#Define the database structure for storing roles and capabilities.<br />
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).<br />
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?<br />
#Consider interface issues, especially how to manage conflicting role/exception rules.<br />
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?<br />
#Consider the impact on backup/restore.<br />
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.<br />
<br />
==Capabilities==<br />
<br />
This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?<br />
<br />
What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)<br />
<br />
===Site-level Capabilities===<br />
<br />
#canreadblogs<br />
#canpostblogs<br />
#candeleteallblogs<br />
#canbrowseuser<br />
#canviewhiddenactivity<br />
#cancreatecourse<br />
#caneditownprofile<br />
#caneditallprofiles<br />
<br />
===Course-level Capabilities===<br />
<br />
#canseecoursecontent<br />
#caneditcourse<br />
#cancreatebackups<br />
#canrestorebackups<br />
#cancreateblocks<br />
#caneditblocks<br />
#candeleteblocks<br />
<br />
===Module-level Capabilities===<br />
<br />
#Assignment<br />
##assignment_canadd<br />
##assignment_canedit<br />
##assignment_candelete<br />
##assignment_cansubmit<br />
##assignment_canmark<br />
##assignment_canviewsubmissions<br />
#Chat<br />
##chat_canadd<br />
##chat_canedit<br />
##chat_candelete<br />
##chat_canparticipate<br />
##chat_canviewpastsessions<br />
#Choice<br />
##choice_canadd<br />
##choice_canedit<br />
##choice_candelete<br />
##choice_canparticipate<br />
##choice_canviewresponses<br />
#Database<br />
##database_canadd<br />
##database_canedit<br />
##databaes_candelete<br />
##database_canaddentry<br />
##database_canaddtemplates<br />
##database_canedittemplates<br />
##database_candeleteownentry<br />
##database_candeleteallentry<br />
##database_cancomment<br />
##database_candeletecomment<br />
##database_canrate<br />
#Exercise<br />
##exercise_canadd<br />
##exercise_canedit<br />
##exercise_candelete<br />
##exercise_canassess<br />
#Forum<br />
##forum_canadd<br />
##forum_canedit<br />
##forum_candelete<br />
##forum_canreadpost<br />
##forum_canstartnewdiscussion<br />
##forum_canreply<br />
##forum_caneditallpost<br />
##forum_candeleteallpost<br />
##forum_canrate<br />
#Glossary<br />
##glossary_canadd<br />
##glossary_canedit<br />
##glossary_candelete<br />
##glossary_canaddcat<br />
##glossary_caneditcat<br />
##glossary_candeletecat<br />
##glossary_canadditem<br />
##glossary_candeleteitem<br />
##glossary_canedititem<br />
##glossary_cancomment<br />
##glossary_canimportentries<br />
##glossary_canexportentries<br />
##glossary_canapprove<br />
#Hotpot<br />
##hotpot_candd<br />
##hotpot_canedit<br />
##hotpot_candelete<br />
##hotpot_canparticipate<br />
#Label<br />
##label_canadd<br />
##label_canedit<br />
##label_candelete<br />
#Lams<br />
##lams_canadd<br />
##lams_canedit<br />
##lams_candelete<br />
#Lesson<br />
##lesson_canadd<br />
##lesson_canedit<br />
##lesson_candelete<br />
##lesson_canparticipate<br />
#Quiz<br />
##quiz_canadd<br />
##quiz_canedit<br />
##quiz_candelete<br />
##quiz_canaddquestion<br />
##quiz_caneditquestion<br />
##quiz_candeletequestion<br />
##quiz_canparticipate<br />
##quiz_cangrade<br />
#Resource<br />
##resource_canadd<br />
##resource_canedit<br />
##resource_candelete<br />
#Scorm<br />
##scorm_canadd<br />
##scorm_canedit<br />
##socrm_candelete<br />
#Survey<br />
##survey_canadd<br />
##survey_canedit<br />
##survey_candelete<br />
##survey_canviewresponses<br />
#Wiki<br />
##wiki_canadd<br />
##wiki_canedit<br />
##wiki_candelete<br />
##wiki_canstartnewwiki<br />
##wiki_canparticipate<br />
#Workshop<br />
##workshop_canadd<br />
##workshop_canedit<br />
##workshop_candelete<br />
##workshop_cangrade<br />
##workshop_canparticipate<br />
<br />
==Scenarios==<br />
<br />
This section is for brainstorming some example roles that we would like to support:<br />
<br />
===Parent===<br />
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children.<br />
<br />
In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.<br />
<br />
In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br />
<br />
In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.<br />
<br />
Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br />
<br />
In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br />
<br />
The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br />
<br />
In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br />
<br />
===Manager===<br />
''Please add text here...''<br />
<br />
===Weekly Seminar Leader===<br />
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br />
<br />
===Mentor/Mentee===<br />
''Please add text here...''<br />
<br />
===Community-Designed Rating Criteria===<br />
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br />
<br />
===Visitor===<br />
<br />
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant. <br />
<br />
===Former Student===<br />
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br />
<br />
===Librarian===<br />
<br />
Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br />
<br />
===Teacher===<br />
<br />
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.<br />
<br />
I think that what is needed is a simple heirarchy of permissions and levels of granularity. <br />
<br />
===Secretary/Student Worker===<br />
<br />
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br />
<br />
===Teaching Assistant===<br />
<br />
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br />
<br />
==See also==<br />
<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion<br />
<br />
<br />
[[Category:Future]]</div>Cmcqueenhttps://docs.moodle.org/dev/index.php?title=Course/site_filter_config&diff=869Course/site filter config2006-02-20T17:43:19Z<p>Cmcqueen: </p>
<hr />
<div>This topic is to define how to add the possibility of "configure" filters both at site and course level.<br />
<br />
The mp3player may be configured at site level to only start downloading when the play button is pressed.<br />
<br />
The flashplugin filter could do with configuartion so you can vary the size of the displayed rectangle. Not sure how this would work other than on a per course level. Do flash files store an optimum size in the file? If they do could we use that in the filter up to the max size for the column it's being displayed in.</div>Cmcqueen