https://docs.moodle.org/dev/api.php?action=feedcontributions&feedformat=atom&user=UrsHunkler 2026-08-12T02:29:43Z User contributions MediaWiki 1.43.5 https://docs.moodle.org/dev/index.php?title=Developer_meeting_April_2015&diff=47587 2015-04-13T15:32:44Z

<p>UrsHunkler: /* First experiences with mustache, the new template framework */</p> <hr /> <div>[[Developer meetings]] &gt; April 2015 meeting notes<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> | Time<br /> | [http://www.timeanddate.com/worldclock/fixedtime.html?year=2015&amp;month=4&amp;day=21&amp;hour=07&amp;min=0&amp;sec=0 07:00 UTC on Tuesday, 21 April 2015] [http://www.google.com/calendar/event?action=TEMPLATE&amp;text=Moodle+General+developer+meeting&amp;dates=20150421T070000Z/20150421T090000Z&amp;details=&amp;location= &lt;span class=&quot;btn btn-info&quot;&gt;Add to my calendar&lt;/span&gt;]<br /> |-<br /> | Meeting room<br /> | TODO: link to the Live stream at YouTube<br /> |-<br /> | Forum discussion<br /> | TODO: link to a discussion in GDF at moodle.org<br /> |-<br /> | Chat<br /> | [https://moodle.org/local/chatlogs/info.php Regular dev chat]<br /> |-<br /> | Twitter<br /> | [https://twitter.com/search?q=%23moodledev #moodledev]<br /> |-<br /> | Event page<br /> | TODO: link to the event Google+ page]<br /> |}<br /> <br /> == Agenda ==<br /> <br /> The meeting focuses on changes in the upcoming Moodle 2.9 release with special attention paid to impact of these changes on community contributors and plugin authors.<br /> <br /> Work in progress - individual items to be confirmed, the exact order is subject of change.<br /> <br /> === Navigation improvements ===<br /> <br /> === First experiences with mustache, the new template framework ===<br /> <br /> * by [https://moodle.org/user/profile.php?id=25214 Urs Hunkler] (confirmed)<br /> * See [https://moodle.org/mod/forum/discuss.php?d=311119 the discussion] for more details.<br /> <br /> To see how to work with the Moodle Mustache implementation I refactored the »clean« theme to a Mustache theme. The process went quite well. I'll try to show the main thoughts and steps in the refactoring process in about 10 minutes. We may have some time to talk about Moodle Mustache afterwards.<br /> <br /> You may have a look at the theme »cleanm« in my [https://github.com/uhunkler/moodle/tree/MOODLE_29_mustaches Git repo].<br /> <br /> [[User:Urs Hunkler|Urs Hunkler]] ([[User talk:Urs Hunkler|talk]]) 23:32, 13 April 2015 (AWST)<br /> <br /> === Unified AJAX script handler ===<br /> <br /> * MDL-49163<br /> <br /> === Timezones handling ===<br /> <br /> * by [https://moodle.org/user/profile.php?id=12863 Petr Škoda] (confirmed)<br /> * MDL-49684<br /> <br /> === Per-request temp directories ===<br /> <br /> * by Andrew Nicols<br /> * MDL-44874<br /> <br /> === Behat tests runs in parallel ===<br /> <br /> * by Rajesh Taneja<br /> * MDL-39752<br /> <br /> == More ==<br /> <br /> * If you have something you'd like to add to this page, please contact [https://moodle.org/user/profile.php?id=1601 David Mudrák].</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Themes_2.0_overflow_problems&diff=18454 2010-10-27T08:36:22Z

<p>UrsHunkler: Added some clarifications. Removed Tim&#039;s changes.</p> <hr /> <div>This document examines the overflow:hidden - fixed width problem currently plaguing several areas of Moodle 2.0 (as of October 26, 2010)<br /> <br /> ==The problem==<br /> <br /> Content that is too wide for the main content area is not displayed correctly is obscured behind the side blocks or off-screen, and the browser doesn't scroll horizontally.<br /> <br /> To see it, shrink your browser window and look at:<br /> <br /> * http://moodle.org/mod/forum/discuss.php?d=32796<br /> <br /> It is caused by '''oversized, unwrappable content''':<br /> <br /> # Large images or other media of one form or another.<br /> # Tables, any table that has numerous columns and/or large content in columns.<br /> ## Tabulated data<br /> ## Tables for internal layout (like the forum)<br /> # Unwrappable content<br /> ## This is normally always user-entered text or images.<br /> ## Different browsers handle things differently.<br /> <br /> ==The technical description==<br /> <br /> The cause is a combination of the fixed width that gets set on the core layout XHTML, and the overflow:hidden setting that is required by the layout.<br /> <br /> The layout used in the base theme within Moodle is based on Matthew James Taylor's [http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm Holy grail layout] which is an excellent layout, however (and it does state this in the description of the layout) wide content is a known problem.<br /> <br /> This problem starts on the very first div that contains content within the body *&amp;lt;div id=&quot;page-content&quot;&amp;gt;....&amp;lt;/div&amp;gt;* which has the following style:<br /> <br /> &lt;code css&gt;<br /> #page-content {<br /> clear:both;<br /> float:left;<br /> overflow:hidden;<br /> position:relative;<br /> width:100%;<br /> min-width:900px;<br /> }<br /> &lt;/code&gt;<br /> <br /> Setting the width to 100% instantly boxes the displayable area to just the browsers internal display width, and then overflow:hidden ensures that any overflow is not visible.<br /> <br /> This is required because the premise of this layout is to move everything out of the viewport and then move things back into the correct position and in doing this it goes as far as expanding content divs out to 200% width.<br /> <br /> Because of this if we remove the width 100% and/or overflow hidden everything breaks because the page will ALWAYS expand beyond the browsers displayable area even if the content is easily displayed.<br /> <br /> As far as I can see there is no way to avoid this problem while using this layout.<br /> <br /> On the other hand there are very good reasons for using this layout:<br /> * it is cross browser, <br /> * columns are orderd 2,1,3 which is good for accessibility and search engine optimisation, and<br /> * in EVERY other respect it works well<br /> <br /> ==Proposed solution 1 - Additional wrapper DIV ==<br /> <br /> A couple of days ago I sat down with Martin and explained this to him and we looked into it and came up with the following three part solution:<br /> <br /> # Wrap format_text output within a div with a class that allows us to manage overflow. The themes can then turn on overflow:auto for these areas to make sure that user content wraps correctly (eg forum post content).<br /> # Convert places that use tables for layout to divs (eg forum posts) so that they wrap cleanly. Without this the large user content causes the table cells to grow too large, causing wrapping issues.<br /> # Locate places where tables are likely to require horizontal scrolling and wrap them in divs with a class like `flexible-wrap` that sets an overflow:auto so that the table is scrollable if required.<br /> <br /> <br /> ===Advantages===<br /> <br /> # A standard way for developers and themers to deal with these issues (can go in coding guidelines)<br /> # Will remove the possibility for users to intentionally/accidentally destroy the interface by posting large content<br /> <br /> ===Possible problems===<br /> <br /> # Because all format_text calls will be wrapped by this special div there might be regressions throughout Moodle - we will have to review the calls and possibly disable the new wrapping divs for some of them. (For example, quiz multiple choice options are processed by format_text, then output inside a Label. The wrapping div would break that horribly.)<br /> # Some parts of Moodle can never be made to fit in a sensible width. For example the gradebook, and other reports.<br /> # IE6/7 (and possibly IE 8/9?) render their scrollbars INSIDE an element rather than outside like most other browsers meaning that there is a *VERY* high chance there will be redundant scrollbars within some elements that don't actually require wrapping (on these browsers)<br /> # Elements that require scrolling will have their own scrollbars and particularly in the case of tables this is likely to require scrolling the page vertically to locate the horizontal scrollbar, scrolling horizontally and then locating the desired row vertically again.<br /> # Elements with a set width (e.g.style=&quot;width:2000px&quot;) greater than the content area will need to be wrapped in a div with the wrapping class as well.<br /> <br /> <br /> ==Proposed solution 2 - Source code order ==<br /> <br /> Compromise, and use a 1, 3, 2 or 1, 2, 3 layout (with skip links for accessibility).<br /> <br /> ===Advantages===<br /> <br /> # It can be made to work for all pages.<br /> # We use a 1, 3, 2 at the OU, and it is reliable.<br /> <br /> ===Possible problems===<br /> <br /> # Slightly less accessible (unless you are comparing with the current situation that actually chops off text for most users even before you start resizing fonts, and is therefore infinitely less accessible, of course). <br /> # Hurts our pride to give up on a 2, 1, 3 layout.<br /> <br /> ==Proposed solution 3 - JavaScript ==<br /> <br /> Add some JavaScript to the page, so that once everything has been laid out, it computes how wide the page needs to be to avoid truncation, and then changes the min-width: 900px to whatever width is needed to make the content fit.<br /> <br /> ===Advantages===<br /> <br /> # Might be the easiest solution to implement.<br /> <br /> ===Possible problems===<br /> <br /> # Ewwwwwww! This is clearly a horrible hack.<br /> # JavaScript for layout is deeply evil.<br /> <br /> <br /> ==Proposed solution 4 - Admin theme ==<br /> <br /> Use different page layouts for different needs. Admin/settings pages show very different content than the normal learning pages. All pages for admins and teachers where they change settings or edit content are shown with the admin theme. Two different page layouts would solve a lot of issues. In for example WordPress and Drupal the concept of the admin theme for admin/settings pages and the &quot;nice&quot; theme for content is standard.<br /> <br /> # Use an &quot;admin theme&quot; with flexible width and a 1-2 layout for the admin and settings pages. The huge tables are mainly on the admin pages. Most table issues would be solved this way.<br /> # Use the existing 2-1-3 fixed width layout for all learning pages.<br /> # Change all tables in the forum layout and other modules if existent to div layouts.<br /> # Create a filter to display a miniature of oversized media and open the original size in a bigger overlay on click. The maximum width can be a setting in the filter to fit different theme needs.<br /> <br /> ===Advantages===<br /> <br /> # The pages with different needs get different layouts better fitting these needs.<br /> # One optimized admin theme can be used with many different themes. Theme designers can focus on the content pages when they work on themes.<br /> # The flexible width admin theme helps a lot when the content shall be displayed in any fixed width page layout. <br /> # The different look of the admin theme signals: be careful - you are changing things which may seriously affect the system or the learning content.<br /> # I use an flexible width admin theme I developed for some time now with all fixed width themes and solve the table width issues on admin/settings pages. It's always the same admin theme with very different content themes.<br /> <br /> ===Possible problems===<br /> <br /> # The deeply nested forum threads issues are not solved with the admin theme.<br /> <br /> ==Opinions==<br /> <br /> ; Tim<br /> : I vote for 2, or failing that 3. I think 1. will not work.<br /> <br /> ; Sam<br /> : agree with Tim except I don't think 3 is likely to be reliable either.<br /> : http://moodle.org/mod/cvsadmin/view.php?conversationid=5929<br /> <br /> ; Frank<br /> : IMHO the only real problem is '''2.2.Tables for internal layout (like the forum)''' and possibly 3.2. (Which, by the way, only proves that tables for layout are a bad thing, [[User:Frank Ralf/Semantic HTML3]]). Any other ''oversized, unwrappable content'' will break the layout one way or another and should be the responsibility of the author. That said, I favor solution 2; any solution which requires JavaScript (3) only makes the situation even more complex. --[[User:Frank Ralf|Frank Ralf]] 14:41, 26 October 2010 (UTC)<br /> <br /> ; Urs<br /> : I vote for 4. <br /> : 3 is no option - from my experience using JavaScript to correct page issues breaks every once in a while.<br /> : 2 does not solve the table width issue in fixed width themes.<br /> : 1 seams to offer more problems than advantages.<br /> : Please don't throw out the existing 2-1-3 page layout. In my opinion to skip it means much more than it &quot;Hurts our pride to give up on a 2, 1, 3 layout.&quot;. By introducing an admin specific theme many issues can be solved. Additionally theme designers have less pages to work on.<br /> : I thought all table based page layouts should have gone in Moodle 2.0.</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Themes_2.0_overflow_problems&diff=18451 2010-10-26T20:17:11Z

<p>UrsHunkler: Add Proposed solution 4 and my opinion</p> <hr /> <div>This document examines the overflow:hidden - fixed width problem currently plaguing several areas of Moodle 2.0 (as of October 26, 2010)<br /> <br /> ==The problem==<br /> <br /> Content that is too wide for the main content area is not displayed correctly is obscured behind the side blocks or off-screen, and the browser doesn't scroll horizontally.<br /> <br /> To see it, shrink your browser window and look at:<br /> <br /> * http://moodle.org/mod/forum/discuss.php?d=32796<br /> <br /> It is caused by '''oversized, unwrappable content''':<br /> <br /> # Large images or other media of one form or another.<br /> # Tables, any table that has numerous columns and/or large content in columns.<br /> ## Tabulated data<br /> ## Tables for internal layout (like the forum)<br /> # Unwrappable content<br /> ## This is normally always user-entered text or images.<br /> ## Different browsers handle things differently.<br /> <br /> ==The technical description==<br /> <br /> The cause is a combination of the fixed width that gets set on the core layout XHTML, and the overflow:hidden setting that is required by the layout.<br /> <br /> The layout used in the base theme within Moodle is based on Matthew James Taylor's [http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm Holy grail layout] which is an excellent layout, however (and it does state this in the description of the layout) wide content is a known problem.<br /> <br /> This problem starts on the very first div that contains content within the body *&amp;lt;div id=&quot;page-content&quot;&amp;gt;....&amp;lt;/div&amp;gt;* which has the following style:<br /> <br /> &lt;code css&gt;<br /> #page-content {<br /> clear:both;<br /> float:left;<br /> overflow:hidden;<br /> position:relative;<br /> width:100%;<br /> min-width:900px;<br /> }<br /> &lt;/code&gt;<br /> <br /> Setting the width to 100% instantly boxes the displayable area to just the browsers internal display width, and then overflow:hidden ensures that any overflow is not visible.<br /> <br /> This is required because the premise of this layout is to move everything out of the viewport and then move things back into the correct position and in doing this it goes as far as expanding content divs out to 200% width.<br /> <br /> Because of this if we remove the width 100% and/or overflow hidden everything breaks because the page will ALWAYS expand beyond the browsers displayable area even if the content is easily displayed.<br /> <br /> As far as I can see there is no way to avoid this problem while using this layout.<br /> <br /> On the other hand there are very good reasons for using this layout:<br /> * it is cross browser, <br /> * columns are orderd 2,1,3 which is good for accessibility and search engine optimisation, and<br /> * in EVERY other respect it works well<br /> <br /> ==Proposed solution 1==<br /> <br /> A couple of days ago I sat down with Martin and explained this to him and we looked into it and came up with the following three part solution:<br /> <br /> # Wrap format_text output within a div with a class that allows us to manage overflow. The themes can then turn on overflow:auto for these areas to make sure that user content wraps correctly (eg forum post content).<br /> # Convert places that use tables for layout to divs (eg forum posts) so that they wrap cleanly. Without this the large user content causes the table cells to grow too large, causing wrapping issues.<br /> # Locate places where tables are likely to require horizontal scrolling and wrap them in divs with a class like `flexible-wrap` that sets an overflow:auto so that the table is scrollable if required.<br /> <br /> <br /> ===Advantages===<br /> <br /> # A standard way for developers and themers to deal with these issues (can go in coding guidelines)<br /> # Will remove the possibility for users to intentionally/accidentally destroy the interface by posting large content<br /> <br /> ===Possible problems===<br /> <br /> # Because all format_text calls will be wrapped by this special div there might be regressions throughout Moodle - we will have to review the calls and possibly disable the new wrapping divs for some of them. (For example, quiz multiple choice options are processed by format_text, then output inside a Label. The wrapping div would break that horribly.)<br /> # Some parts of Moodle can never be made to fit in a sensible width. For example the gradebook, and other reports.<br /> # IE6/7 (and possibly IE 8/9?) render their scrollbars INSIDE an element rather than outside like most other browsers meaning that there is a *VERY* high chance there will be redundant scrollbars within some elements that don't actually require wrapping (on these browsers)<br /> # Elements that require scrolling will have their own scrollbars and particularly in the case of tables this is likely to require scrolling the page vertically to locate the horizontal scrollbar, scrolling horizontally and then locating the desired row vertically again.<br /> # Elements with a set width (e.g.style=&quot;width:2000px&quot;) greater than the content area will need to be wrapped in a div with the wrapping class as well.<br /> <br /> <br /> ==Proposed solution 2==<br /> <br /> Compromise, and use a 1, 3, 2 or 1, 2, 3 layout (with skip links for accessibility).<br /> <br /> ===Advantages===<br /> <br /> # It can be made to work for all pages.<br /> # We use a 1, 3, 2 at the OU, and it is reliable.<br /> <br /> ===Possible problems===<br /> <br /> # Slightly less accessible (unless you are comparing with the current situation that actually chops off text for most users even before you start resizing fonts, and is therefore infinitely less accessible, of course). <br /> # Hurts our pride to give up on a 2, 1, 3 layout.<br /> <br /> ==Proposed solution 3==<br /> <br /> Add some JavaScript to the page, so that once everything has been laid out, it computes how wide the page needs to be to avoid truncation, and then changes the min-width: 900px to whatever width is needed to make the content fit.<br /> <br /> ===Advantages===<br /> <br /> # Might be the easiest solution to implement.<br /> <br /> ===Possible problems===<br /> <br /> # Ewwwwwww! This is clearly a horrible hack.<br /> # JavaScript for layout is deeply evil.<br /> <br /> <br /> ==Proposed solution 4==<br /> <br /> Use different page layouts for different needs. Admin/settings pages show very different content than the normal learning pages. Two different page layouts would solve a lot of issues. In for example WordPress and Drupal the concept of the admin theme for admin/settings pages and the &quot;nice&quot; theme for content is standard.<br /> <br /> # Use an &quot;admin theme&quot; with flexible width and a 1-2 layout for the admin and settings pages. The huge tables are mainly on the admin pages. Most table issues would be solved this way.<br /> # Use the existing 2-1-3 fixed width layout for all learning pages.<br /> # Change all tables in the forum layout and other modules if existent to div layouts.<br /> # Create a filter to display a miniature of oversized media and open the original size in a bigger overlay on click. The maximum width can be a setting in the filter to fit different theme needs.<br /> <br /> ===Advantages===<br /> <br /> # The pages with different needs get different layouts better fitting these needs.<br /> # One optimized admin theme can be used with many different themes. Theme designers can focus on the content pages when they work on themes.<br /> # The flexible width admin theme helps a lot when the content shall be displayed in any fixed width page layout. <br /> # I use an flexible width admin theme I developed for some time now with all fixed width themes and solve the table width issues on admin/settings pages. It's always the same admin theme with very different content themes.<br /> <br /> ===Possible problems===<br /> <br /> # I see only advantages.<br /> <br /> ==Opinions==<br /> <br /> ; Tim<br /> : I vote for 2, or failing that 3. I think 1. will not work.<br /> <br /> ; Sam<br /> : agree with Tim except I don't think 3 is likely to be reliable either.<br /> : http://moodle.org/mod/cvsadmin/view.php?conversationid=5929<br /> <br /> ; Frank<br /> : IMHO the only real problem is '''2.2.Tables for internal layout (like the forum)''' and possibly 3.2. (Which, by the way, only proves that tables for layout are a bad thing, [[User:Frank Ralf/Semantic HTML3]]). Any other ''oversized, unwrappable content'' will break the layout one way or another and should be the responsibility of the author. That said, I favor solution 2; any solution which requires JavaScript (3) only makes the situation even more complex. --[[User:Frank Ralf|Frank Ralf]] 14:41, 26 October 2010 (UTC)<br /> <br /> ; Urs<br /> : I vote for 4. <br /> : 3 is no option - from my experience using JavaScript to correct page issues breaks every once in a while.<br /> : 2 does not solve the table width issue in fixed width themes.<br /> : 1 seams to offer more problems than advantages.<br /> : Please don't throw out the existing 2-1-3 page layout. In my opinion to skip it means much more than it &quot;Hurts our pride to give up on a 2, 1, 3 layout.&quot;. By introducing an admin specific theme many issues can be solved. Additionally theme designers have less pages to work on.<br /> : I thought all table based page layouts should have gone in Moodle 2.0.</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19453 2008-08-19T08:02:45Z

<p>UrsHunkler: typo</p> <hr /> <div>[[Image:urs.png|left]]<br /> <br /> I am a web designer with my company [http://unodo.de unodo] specializing in concept, design and development of Internet-based working and learning. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. <br /> <br /> Integration of the Moodle code and the theme [[Custom Corners]] brings some Web 2.0 design opportunities to Moodle. The interactive Moodle theme [[Chameleon]] is one project. The Accordion Course format another. The outcome of these projects you can see and try on the [http://chameleon-theme.unodo.de/ Chameleon] site.<br /> <br /> I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 10:00, 18 August 2008 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19452 2008-08-19T08:01:59Z

<p>UrsHunkler: Actualize my description</p> <hr /> <div>[[Image:urs.png|left]]<br /> <br /> I am a web designer with my company [http://unodo.de unodo] specializing in concept, design and development of Internet-based working and learning. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. <br /> <br /> Integration of the Moodle code and the theme [[Custom Corners]] brings some Web 2.0 design opportunities to Moodle. [[The interactive Moodle theme [[Chameleon]] is one project. The Accordion Course format another. The outcome of these projects you can see and try on the [http://chameleon-theme.unodo.de/ Chameleon] site.<br /> <br /> I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 10:00, 18 August 2008 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Web_services&diff=7239 2007-12-23T10:07:34Z

<p>UrsHunkler: add :: with the option to plug in AMFPHP for Flash/Flex interfaces</p> <hr /> <div>This page is to decide on a STANDARD list of CORE web service functions that we should support in Moodle (by XMLRPC, REST and SOAP with the option to plug in AMFPHP for Flash/Flex interfaces) as an API for those writing code to work against Moodle.<br /> <br /> Please add new functions if there's functionality you want that isn't covered (we can refactor/whittle at the end).<br /> <br /> ==add user==<br /> I think we should require all data needed for a successful &quot;first login&quot; to Moodle without popping him out the profile page to fill in all missing required data. This may require extra inputs such as city, description ... (unsure of the full list depending of Moodle version ?).<br /> Also password should be &quot;required&quot; if authentication method is &quot;internal&quot; . <br /> <br /> INPUT:<br /> firstname<br /> lastname<br /> email <br /> idnumber<br /> login <br /> authentication method (optional , default= manual ?)<br /> <br /> <br /> <br /> OPERATION:<br /> Adds a new user to the user database <br /> <br /> OUTPUT:<br /> id or false<br /> <br /> ==delete user==<br /> INPUT:<br /> idnumber or <br /> email or <br /> id or<br /> login<br /> <br /> OPERATION:<br /> User is marked as deleted<br /> All it's role assignments are destroyed <br /> OUTPUT:<br /> true/false<br /> <br /> ==add course==<br /> INPUT:<br /> name<br /> shortname<br /> format (default topics)<br /> idnumber <br /> <br /> OPERATION:<br /> Adds a new course to the course table<br /> <br /> OUTPUT:<br /> id or false<br /> <br /> <br /> ==delete course==<br /> INPUT:<br /> name OR<br /> shortname OR<br /> idnumber OR<br /> id<br /> <br /> OPERATION:<br /> Deletes a course from the course table<br /> What about associated ressources, roles ... <br /> <br /> OUTPUT:<br /> true or false<br /> <br /> ==enrol student to course==<br /> INPUT:<br /> course unique Id (Moodle's ID or idnumber or shortname)<br /> student unique id (Moodle's ID or idnumber or login or email)<br /> <br /> OPERATION:<br /> Assign student role to course <br /> <br /> OUTPUT:<br /> true or false<br /> <br /> <br /> <br /> ==unenrol student from course==<br /> INPUT:<br /> course unique Id (Moodle's ID or idnumber or shortname)<br /> student unique id (Moodle's ID or idnumber or login or email)<br /> <br /> OPERATION:<br /> remove student role from course <br /> <br /> OUTPUT:<br /> true or false<br /> <br /> <br /> ==assign role to course==<br /> INPUT:<br /> course unique Id (Moodle's ID or idnumber or shortname)<br /> user unique id (Moodle's ID or idnumber or login or email)<br /> role id (teacher, non editing teacher, student (?) ...)<br /> <br /> OPERATION:<br /> assign given user a &quot;standard&quot; role to given course <br /> <br /> OUTPUT:<br /> true or false<br /> <br /> <br /> ==remove role from course==<br /> INPUT:<br /> course unique Id (Moodle's ID or idnumber or shortname)<br /> user unique id (Moodle's ID or idnumber or login or email)<br /> role id (teacher, non editing teacher, student (?) ...)<br /> <br /> OPERATION:<br /> remove given user's &quot;standard&quot; role from given course <br /> <br /> OUTPUT:<br /> true or false<br /> <br /> <br /> ==get my courses==<br /> <br /> INPUT:<br /> user unique id (Moodle's ID or idnumber or login or email)<br /> <br /> OPERATION:<br /> return a &quot;list&quot; of course's id in which given user move given user has some role assigned <br /> <br /> OUTPUT:<br /> &quot;array&quot; of (course id, course shortname, course fullname, role id, role name, course url)<br /> or false in case of error (bad user id)<br /> <br /> ==get last changes in my courses==<br /> <br /> INPUT:<br /> user unique id (Moodle's ID or idnumber or login or email)<br /> course unique Id (Moodle's ID ,idnumber or shortname) - optional (default = all my courses)<br /> timestamp - optional (default = time of last connexion in every course)<br /> <br /> OPERATION:<br /> return a &quot;list&quot; of changes (resource added/modified, new activities, etc.) for courses in which given user has some role assigned - since timestamp or last connexion in given course <br /> <br /> OUTPUT:<br /> &quot;array&quot; of (course id, course shortname, course fullname, role id, role name, url of the resource/activity, time of change)<br /> or false in case of error (bad user/course id)<br /> <br /> <br /> ==get grades==<br /> <br /> INPUT:<br /> user unique id (Moodle's ID or idnumber or login or email)<br /> course unique Id (Moodle's ID ,idnumber or shortname) - optional (default = all my courses)<br /> <br /> OPERATION:<br /> return a &quot;list&quot; of grades and statistics for the given student in the given course<br /> <br /> OUTPUT:<br /> &quot;array&quot; of grades records (name,maxgrade,grade,percent,weight,weighted,sortOrder) <br /> and &quot;array&quot; of stats (gradeItems,allgrades, points,totalpoints, percent, weight, weighted;) <br /> or false in case of error (bad user/course id or user not in course)<br /> <br /> <br /> ==get groups==<br /> <br /> OPERATION:<br /> return a &quot;list&quot; of group records in a given course (or site ?) <br /> <br /> ==get group members==<br /> <br /> OPERATION:<br /> return a &quot;list&quot; of ids for members of a group (within a course or global) <br /> <br /> <br /> ==enrol to group==<br /> <br /> OPERATION:<br /> add a new member to a group<br /> <br /> <br /> ==unenrol from group==<br /> <br /> OPERATION:<br /> remove membership from a group<br /> <br /> <br /> ==get events ==<br /> <br /> OPERATION:<br /> return a &quot;list&quot; of event's identifiers suitable from the &quot;get event&quot; operation<br /> <br /> ==get event==<br /> <br /> OPERATION:<br /> return in an &quot;exportable&quot; format (iCal, vCal ...)an event recorded in Moodle database (site, course, private ...)<br /> <br /> ==set event==<br /> <br /> OPERATION:<br /> add/modify an event in Moodle database (site, course, private ...)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19451 2006-11-28T19:48:01Z

<p>UrsHunkler: changed picture link</p> <hr /> <div>[[Image:urs.png|left]]<br /> <br /> I am a web designer specializing in Internet-based working and learning. And I am a Moodle Partner with my company [http://unodo.de unodo]. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. <br /> <br /> The interactive Moodle theme [[Chameleon]] is one project. The Accordion Course format another. The outcome of these projects you can see and try on the [http://chameleon-theme.unodo.de/ Chameleon] site.<br /> <br /> I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 15:16, 10 February 2006 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roles&diff=3132 2006-09-20T05:58:15Z

<p>UrsHunkler: /* Proposal for interface enhancement */ several typos</p> <hr /> <div>'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.<br /> <br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context, for example, teacher, student and forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<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 perform 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 /> <br /> {{Moodle 1.7}}The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> #CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically 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, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<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:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<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?) : 1)course/scales.php<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 : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:useremail - Can use the enable/disable email stuff<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<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 part before the colon is the full path to the module in the Moodle code. 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:submit - turn assignment in<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:viewentry - reads other people's entry<br /> ##mod/data:viewentriesfromallgroups<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:viewrating<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:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<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:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:view<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<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 /> ##mod/wiki:view - basic capability needed to view wiki content<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:view - basic capability needed to enter workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<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&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> (more soon)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<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 &quot;as a student&quot;, 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 inspectors, 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 /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<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 &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; 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 /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<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 /> ===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 some schools such as 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 &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; 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 /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<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 /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #[[Backup_roles_1.7|Backups]] [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. The sketches below are not worked out proposals. Their task is to visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from &quot;allow&quot; to &quot;prohibit&quot; (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tool-tip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<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 /> [[Category:Roles]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roles&diff=3131 2006-09-20T05:56:56Z

<p>UrsHunkler: /* Proposal for interface enhancement */ typo</p> <hr /> <div>'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.<br /> <br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context, for example, teacher, student and forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<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 perform 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 /> <br /> {{Moodle 1.7}}The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> #CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically 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, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<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:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<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?) : 1)course/scales.php<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 : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:useremail - Can use the enable/disable email stuff<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<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 part before the colon is the full path to the module in the Moodle code. 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:submit - turn assignment in<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:viewentry - reads other people's entry<br /> ##mod/data:viewentriesfromallgroups<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:viewrating<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:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<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:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:view<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<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 /> ##mod/wiki:view - basic capability needed to view wiki content<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:view - basic capability needed to enter workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<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&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> (more soon)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<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 &quot;as a student&quot;, 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 inspectors, 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 /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<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 &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; 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 /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<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 /> ===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 some schools such as 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 &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; 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 /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<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 /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #[[Backup_roles_1.7|Backups]] [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. The scetches below are not worked out proposals. Theier task is to visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from &quot;allow&quot; to &quot;prohibit&quot; (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful differnt coloured coulmns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tooltip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<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 /> [[Category:Roles]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roles&diff=3128 2006-09-19T21:22:22Z

<p>UrsHunkler: /* Proposal for interface enhancement */ typo</p> <hr /> <div>'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.<br /> <br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context, for example, teacher, student and forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<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 perform 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 /> <br /> {{Moodle 1.7}}The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> #CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically 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, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<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:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<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?) : 1)course/scales.php<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 : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<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 part before the colon is the full path to the module in the Moodle code. 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:submit - turn assignment in<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:viewentry - reads other people's entry<br /> ##mod/data:viewentriesfromallgroups<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:viewrating<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:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<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:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:view<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<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 /> ##mod/wiki:view - basic capability needed to view wiki content<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:view - basic capability needed to enter workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<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&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> (more soon)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<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 &quot;as a student&quot;, 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 inspectors, 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 /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<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 &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; 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 /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<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 /> ===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 some schools such as 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 &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; 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 /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<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 /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #Backups [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. The scetches blow are not worked out proposals. Theier task is to visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from &quot;allow&quot; to &quot;prohibit&quot; (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful differnt coloured coulmns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tooltip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<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 /> [[Category:Roles]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roles&diff=3127 2006-09-19T21:17:33Z

<p>UrsHunkler: /* Proposal for interface enhancement */ enhancements</p> <hr /> <div>'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.<br /> <br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context, for example, teacher, student and forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<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 perform 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 /> <br /> {{Moodle 1.7}}The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> #CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically 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, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<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:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<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?) : 1)course/scales.php<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 : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<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 part before the colon is the full path to the module in the Moodle code. 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:submit - turn assignment in<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:viewentry - reads other people's entry<br /> ##mod/data:viewentriesfromallgroups<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:viewrating<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:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<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:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:view<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<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 /> ##mod/wiki:view - basic capability needed to view wiki content<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:view - basic capability needed to enter workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<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&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> (more soon)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<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 &quot;as a student&quot;, 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 inspectors, 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 /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<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 &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; 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 /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<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 /> ===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 some schools such as 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 &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; 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 /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<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 /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #Backups [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. The scetches blow are not worked out proposals. They only visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from &quot;allow&quot; to &quot;prohibit&quot; (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful differnt coloured coulmns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tooltip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<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 /> [[Category:Roles]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roles&diff=3126 2006-09-19T21:08:34Z

<p>UrsHunkler: /* Proposal for interface enhancement */ typos</p> <hr /> <div>'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.<br /> <br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context, for example, teacher, student and forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<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 perform 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 /> <br /> {{Moodle 1.7}}The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> #CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically 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, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<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:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<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?) : 1)course/scales.php<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 : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<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 part before the colon is the full path to the module in the Moodle code. 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:submit - turn assignment in<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:viewentry - reads other people's entry<br /> ##mod/data:viewentriesfromallgroups<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:viewrating<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:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<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:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:view<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<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 /> ##mod/wiki:view - basic capability needed to view wiki content<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:view - basic capability needed to enter workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<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&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> (more soon)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<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 &quot;as a student&quot;, 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 inspectors, 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 /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<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 &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; 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 /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<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 /> ===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 some schools such as 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 &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; 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 /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<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 /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #Backups [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into visible differnt coulmns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tooltip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<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 /> [[Category:Roles]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roles&diff=3125 2006-09-19T21:05:57Z

<p>UrsHunkler: Add section &quot;interface proposals&quot;</p> <hr /> <div>'''Roles and permissions''' will be in Moodle 1.7 and are available in the developer version of Moodle.<br /> <br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context, for example, teacher, student and forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<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 perform 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 /> <br /> {{Moodle 1.7}}The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> #CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically 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, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<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:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<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?) : 1)course/scales.php<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 : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<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 part before the colon is the full path to the module in the Moodle code. 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:submit - turn assignment in<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:viewentry - reads other people's entry<br /> ##mod/data:viewentriesfromallgroups<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:viewrating<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:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<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:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:view<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<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 /> ##mod/wiki:view - basic capability needed to view wiki content<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:view - basic capability needed to enter workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<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&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> (more soon)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<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 &quot;as a student&quot;, 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 inspectors, 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 /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<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 &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; 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 /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<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 /> ===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 some schools such as 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 &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; 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 /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<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 /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #Backups [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. The picture shows that the user can keep a much better overview when the list is divided into visible differnt coulmns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tooltip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<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 /> [[Category:Roles]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19450 2006-05-09T11:00:37Z

<p>UrsHunkler: picture and enhancements</p> <hr /> <div>https://docs.moodle.org/en/images/b/b0/urs.png<br /> <br /> I am a web designer specializing in Internet-based working and learning. And I am a Moodle Partner with my company [http://unodo.de unodo]. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. <br /> <br /> The interactive Moodle theme [[Chameleon]] is one project. The Accordion Course format another. The outcome of these projects you can see and try on the [http://chameleon-theme.unodo.de/ Chameleon] site.<br /> <br /> I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 15:16, 10 February 2006 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:UrsHunkler/MoodleDocs.css&diff=19593 2006-02-25T19:53:11Z

<p>UrsHunkler: </p> <hr /> <div>body {background: #afa}</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19448 2006-02-15T07:29:56Z

<p>UrsHunkler: typo</p> <hr /> <div>I am a web designer specializing in Internet-based working and learning. And I am a Moodle Partner, my company is [http://unodo.de unodo]. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. The interactive Moodle theme [[Chameleon]] is one project.<br /> <br /> I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 15:16, 10 February 2006 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Credits&diff=28924 2006-02-15T07:27:51Z

<p>UrsHunkler: /* Key Moodle Roles */ added link to my profile page</p> <hr /> <div>{{About Moodle}}<br /> ==Overall guidance==<br /> <br /> [http://dougiamas.com/ Martin Dougiamas] is the founder and manager for the whole Moodle project. Since 2005 there is a [http://moodle.com/hq/ team of people] employed over at [http://moodle.com/ Moodle HQ] in Perth, Australia helping him keep on top of things (or at least within sight of the top!).<br /> <br /> The Moodle software package is [[License|Copyright © 1999 onwards, Martin Dougiamas under the GNU GPL]].<br /> <br /> ==Key Moodle Roles==<br /> <br /> * Lead Developer - Martin Dougiamas<br /> * Knight in Shining Armor - [[User:Stronk7|Eloy Lafuente]]<br /> * Translation Coordinator - Koen Roggemans<br /> * Security Officer - Petr Škoda (skodak)<br /> * Documentation Steward - [[User:Helen|Helen Foster]]<br /> * Themes Manager - [[User:UrsHunkler|Urs Hunkler]]<br /> * Stable Release Manager - Martin Langhoff<br /> <br /> ==Main developers==<br /> <br /> Endless thanks from all of us goes to those who have contributed substantial and ongoing amounts of time to writing Moodle code and helping it grow. These are people who &quot;get&quot; what developing Moodle is all about and without whom Moodle would be a far lesser thing:<br /> <br /> '''Eloy Lafuente (stronk7), Ray Kingdon, Williams Castillo, Petri Asikainen, Henrik Kaipe, Zbigniew Fiedorowicz, Gustav Delius, Thomas Robb, Janne Mikkonen, Jon Papaioannou (pj), Scott Elliott, Shane Elliott, Roberto Pinna (Bobo), Mike Churchward, Petr Škoda (skodak), Penny Leach, Martin Langhoff, Urs Hunkler'''<br /> <br /> ==Other contributors==<br /> <br /> Many other people have contributed (and are still contributing) with constructive discussions, support, testing and various chunks of code and documentation. This list is long and always changing, but some names include (in the order they were added):<br /> <br /> '''Peter C. Taylor, Art Lader, Matt Hope, Tom Murdock, Sébastien Namèche, James Miller, Dustin Rue, Holger Schadeck, Giovanni Tummarello, John Windmueller, Sean Keogh, Mitsuhiro Yoshida, Greg Barnett, Mark Kimes, Mary Hunter, Russell Jungwirth, Przemyslaw Stencel, John &quot;Captain&quot; Eyre, Paula Edmiston, Howard Miller, Claudio Tavares, P. Timothy Ervin, Bob Calder, Ursula Raab, David Delgado, Mad Alex, Gaëtan Frenoy, Bernard Boucher, Bryan Williams, Rob Butner, Koen Roggemans, David Scotson, Torsten Anderson, Eamon Costello, Hannes Gassert, Andrew Walker.'''<br /> <br /> Sorry if we've forgotten to include your name here - the Moodle community is large and active so this list is difficult to maintain! Please make your suggestions on the discussion tab for this page.<br /> <br /> Thanks also to everyone of you who have<br /> * donated via the [http://moodle.org/donations Donations page],<br /> * contributed to the [http://moodle.org/bugs bug tracker], and<br /> * participated in the [http://moodle.org/community Moodle Community]<br /> * used our [http://moodle.com commercial Moodle Partner services]<br /> <br /> ==Translators==<br /> <br /> One of Moodle's strengths is the number of translations it has. Each translation takes many hours of work, as there are over 1000 phrases to translate (plus hundreds of help files!). Many of the languages have more than one contributor, sometimes working together and sometimes working serially.<br /> <br /> Maintaining a list of all these wonderful people is too difficult, so please look at the [http://download.moodle.org/lang/ Language download page] for names and details.<br /> <br /> The Translation Coordinator is Koen Roggemans (translation@moodle.org).<br /> <br /> ==Themes==<br /> <br /> Themes give Moodle sites some colour and life. Here are all the themes carried as part of the Moodle 1.5 distribution, along with their authors:<br /> <br /> * '''standard''' by Martin Dougiamas<br /> * '''orangewhite''' and '''orangewhitepda''' by Urs Hunkler [http://www.unodo.de/ unodo]<br /> * '''oceanblue''' by Mitsuhiro Yoshida http://mitstek.com<br /> * '''cornflower''' by Thomas Murdock http://sand-paper.org<br /> * '''formal_white''' by Andrea Bicciolo<br /> * '''metal''' by A. Chavan (updated for Moodle 1.5 by Martin Dougiamas)<br /> * '''wood''' by Eloy Lafuente<br /> <br /> Urs Hunkler is our Themes Manager, providing support and development.<br /> <br /> == Documentation writers ==<br /> <br /> Documentation writing is coordinated by [[User:Helen|Helen Foster]]. We would like to thank the many people who have contributed their work to create various parts of Moodle documentation, among others: '''Przemyslaw Stencel, Matt Riordan, Bryan Williams, Ray Lawrence, Jason Cole, Darren Smith, Sylvia Maciaszczyk and Rafal Morusiewicz'''.<br /> <br /> <br /> ==Moodle libraries==<br /> <br /> Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. My thanks go out to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> <br /> '''ADOdb''' - lib/adodb<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 4.71<br /> <br /> Copyright © 2000-2006 John Lim (''jlim AT natsoft DOT com DOT my'')<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> URL: http://adodb.sourceforge.net<br /> <br /> <br /> '''Graph Class''' - lib/graphlib.php<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> <br /> '''html2text''' - lib/html2text.php<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Mark Wilton-Jones<br /> <br /> License: HowToCreate script license with written permission<br /> <br /> URL: http://www.howtocreate.co.uk/php/<br /> <br /> <br /> '''htmlArea''' - lib/editor<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> <br /> '''IP-Atlas''' - lib/ipatlas<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> URL: http://www.xpenguin.com/ip-atlas.php<br /> <br /> <br /> '''kses''' - lib/kses.php<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> URL: http://sourceforge.net/projects/kses<br /> <br /> <br /> '''mimeTeX''' - filter/tex<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> URL: http://www.forkosh.com/mimetex.html<br /> <br /> URL: http://moodle.org/download/mimetex<br /> <br /> <br /> '''mp3player''' - lib/mp3player<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> <br /> '''overlibmws''' - lib/overlib.js<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> URL: http://www.macridesweb.com/oltest/<br /> <br /> <br /> '''PclZip''' - lib/pclzip<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> URL: http://www.phpconcept.net<br /> <br /> <br /> '''PHP mailer''' - lib/class.phpmailer.php<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 1.71<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> URL: http://phpmailer.sourceforge.net<br /> <br /> <br /> '''PHP Markdown''' - lib/markdown.php<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.0b9 (with modifications)<br /> <br /> Copyright © 2003-2004 , John Gruber<br /> <br /> Copyright © 2004 , Michel Fortin<br /> <br /> License: LGPL<br /> <br /> URL: http://www.michelf.com/projects/php-markdown/<br /> <br /> <br /> '''Snoopy''' - lib/snoopy<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> URL: http://snoopy.sourceforge.com<br /> <br /> <br /> '''Spreadsheet::WriteExcel''' - lib/excel<br /> <br /> A library for generating Excel Spreadsheets.<br /> <br /> Version: 2002-11-28<br /> <br /> Copyright © 2002 Xavier Noguer (''xnoguer AT rezebra DOT com'')<br /> <br /> License: GNU LGPL<br /> <br /> URL: http://jeffn.users.phpclasses.org/browse.html/package/767.html<br /> <br /> <br /> '''SMTP class''' - lib/class.smtp.php<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> <br /> '''Typo3 Character Set Class''' - lib/typo3<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> CVS version: 1.54<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licencia: GNU GPL<br /> <br /> URL: http://typo3.org/<br /> <br /> [[Category:Core]]<br /> [[Category:Administrator]]<br /> [[Category:Developer]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19447 2006-02-10T07:20:46Z

<p>UrsHunkler: typo</p> <hr /> <div>I am a web designer specializing in Internet-based working and learning. And I am a MoodlePartner, my company is called [http://unodo.de unodo]. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. The interactive Moodle theme [[Chameleon]] is one project.<br /> <br /> I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 15:16, 10 February 2006 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19446 2006-02-10T07:20:25Z

<p>UrsHunkler: text updated</p> <hr /> <div>I am a web designer specializing in Internet-based working and learning. And I am a MoodlePartner, my company is called [http://unodo.de unodo]. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. The interactive Moodle theme [[Chameleon Chameleon]] is one project.<br /> <br /> I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 15:16, 10 February 2006 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19445 2006-02-10T07:16:25Z

<p>UrsHunkler: text updated</p> <hr /> <div>I am a web designer specializing in Internet-based working and learning. I am a MoodlePartner with my company [http://unodo.de unodo]. <br /> <br /> The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. I developed the MoodleDocs skin to integrate it's look with moodle.org and will enhance it for better functionality.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 15:16, 10 February 2006 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Interface_guidelines&diff=1777 2006-02-09T11:46:19Z

<p>UrsHunkler: /* Page layout */ info to use CSS hooks added</p> <hr /> <div>This document is not authoritative, it is a collection of ideas and under construction.<br /> <br /> ==Keeping it simple==<br /> <br /> Use the minimum interface required to get the job done<br /> <br /> ==Standard pages==<br /> <br /> ===Activity modules===<br /> <br /> *''index.php'' - lists all instances for that module in a course<br /> *''view.php'' - displays a particular instance<br /> *''config.html'' - configure an instance of the module<br /> <br /> ===Blocks===<br /> <br /> *''config.html'' - configure an instance of the block<br /> <br /> ==One script per major function/page==<br /> <br /> ...<br /> <br /> ==Page layout==<br /> <br /> # Print headings with print_heading, use the CSS hooks for IDs and Classes<br /> # Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes<br /> <br /> ==Form layout==<br /> <br /> # Show the more important settings at the top<br /> # Each entry should have a label, and if necessary, a help file<br /> # If there are more than 10 options, split them into required and optional/extra/advanced parameters<br /> <br /> ==Dealing with tables==<br /> <br /> Use the print_table function whenever possible.<br /> <br /> ==Standard navigation tools==<br /> <br /> # All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE &gt;&gt; INDEX &gt;&gt; INSTANCE &gt;&gt; SUBPAGES...<br /> # Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br /> <br /> ==URLs==<br /> <br /> # URLs should be as short as possible.<br /> # No underscores in parameter names or files names<br /> # Never use two words when one would do.<br /> <br /> ==Buttons vs links==<br /> <br /> This is a hard one to define ...<br /> <br /> The Google Web Accelerator issue definitely provides some pointers here:<br /> <br /> # Actions which can modify the state of Moodle (data files, database, session information) should be performed through buttons<br /> # At the very least, such actions which are implemented as links should forward to a confirmation page which *does* use buttons<br /> <br /> ==CSS naming==<br /> <br /> * See [[Standards|theme standards]]<br /> <br /> ==Linking to help==<br /> <br /> * Help buttons should be on the right of the thing (as an exception it can be left, if the thing is right-aligned)<br /> <br /> ==Related topics==<br /> <br /> Robin Good's Latest News. &quot;Interaction Design Meets Online Real Estate&quot; 1 Mar. 2005 http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm<br /> <br /> The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools.</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Developer_notes&diff=750 2006-02-08T18:07:20Z

<p>UrsHunkler: </p> <hr /> <div>&lt;p class=&quot;note&quot;&gt;'''Note for contributors:''' This area is for developers to work on various bits of code and documentation as necessary. Initial text has been taken from [http://moodle.org/course/view.php?id=5 Using Moodle] Developer Wiki. If you find any text missing, please email docs AT moodle DOT org.&lt;/p&gt;<br /> <br /> ==1.6 plans==<br /> <br /> *[[Forum development|Forum functional upgrade]]<br /> *[[UTF-8 migration|Migration to UTF-8]]<br /> *[[Other lang issues|Other language issues (non UTF related)]] <br /> *[[Developer conference|Developer conference]]<br /> *[[MoodleDocs development]]<br /> <br /> ==Other==<br /> <br /> *[[Usability]]<br /> *[[Interface guidelines]]<br /> *[[Stats package]]<br /> *[[Blogs and forums|Blogs, forums and the nature of discussion]]<br /> *[[Authentication API]]<br /> *[[Document Management API]]<br /> *[[Filters schema]]<br /> *[[Filterall support]]<br /> *[[Application/session variables]]<br /> *[[Unmerged files|1.4 and 1.5 un-merged files]]<br /> *[[Email processing]]<br /> *[[Wiki development|Wiki module development]]<br /> *[[Cookieless Sessions]]<br /> <br /> ==See also==<br /> <br /> *[[Developer documentation]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19444 2006-02-08T15:42:54Z

<p>UrsHunkler: </p> <hr /> <div>I am a web designer specializing in Internet-based working and learning. My company is [http://unodo.de unodo]. The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. I am developing the MoodleDocs skin to integrate it's look with moodle.org.<br /> <br /> * [[Themes]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 23:42, 8 February 2006 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19443 2006-02-08T15:42:31Z

<p>UrsHunkler: link to templates removed</p> <hr /> <div>I am a web designer specializing in Internet-based working and learning. My company is [http://unodo.de unodo]. The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. I am developing the MoodleDocs skin to integrate it's look with moodle.org.<br /> <br /> * [[Themes]]<br /> <br /> --UrsHunkler 16 July 2005 13:21 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19442 2006-02-08T11:07:21Z

<p>UrsHunkler: small changes</p> <hr /> <div>I am a web designer specializing in Internet-based working and learning. My company is [http://unodo.de unodo]. The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. I am developing the MoodleDocs skin to integrate it's look with moodle.org.<br /> <br /> * [[Themes]]<br /> * [[Templates]]<br /> <br /> --UrsHunkler 16 July 2005 13:21 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roadmap&diff=26093 2006-02-05T17:54:11Z

<p>UrsHunkler: </p> <hr /> <div>This roadmap collects the best information about upcoming features in Moodle. It is not 100% certain - features may change according to available funding and developers.<br /> <br /> == Version 1.6 - Beta expected late February 2006 ==<br /> <br /> * [[Unicode]] - Moodle.com, Eloy Lafuente and Koen Roggemans<br /> ::Moodle is now 100% Unicode, which means any language can be mixed together and an end to a number of problems that different character sets caused us.<br /> * [[Documentation]] - Moodle.com and Helen Foster<br /> ::A new one-stop Wiki site for ALL Moodle documentation, including links from Moodle itself<br /> * [[Database]] - Moodle.com <br /> ::A new activity module that allows collaborative collection of structured data, useful for many things!<br /> * [[LAMS]] - LAMS Foundation<br /> ::Integrated via a course format and an activity module<br /> * [[Blogs]] - Daryl Hawes and Moodle.com<br /> ::Allows reflection on an ongoing basis. Entries are marked and can be viewed by user, course, group, site etc. Contains new keyword support. <br /> * [[Site Stats]] - Catalyst<br /> ::Provides statistics at a higher level than before (by course etc)<br /> * [[My Moodle]] - Catalyst<br /> ::A dashboard interface that allows an overview for each user of all their courses etc<br /> * [[Hive integration]] - Moodle.com and Harvest Road<br /> ::This initial integration with Hive allows teachers to upload, browse, search and select [[mod/resource/index|Resources]] within the external repository.<br /> * [[Multiple Groups]] - Moodle.com and Arab Open University<br /> ::Users can be part of multiple groups within a course.<br /> * [[IMS Resource]] - Eloy Lafuente and Alton College<br /> ::Supports the loading of any content package as a Resource, plus special support for NLN repositories.<br /> * [[Learning Design Export]] - Moodle.com and Open University of The Netherlands<br /> ::We plan to have a very simple export for any Moodle course into IMS LD format, as a proof of concept and to help the community start learning about IMS LD.<br /> * [[Granularised Backup]] - Catalyst and Eloy Lafuente<br /> ::<br /> * [[Chameleon Theme]] - Andy Walker &amp; Urs Hunkler. <br /> :: It's in 1.6 CVS and you can test it live on http://chameleon-theme.unodo.de<br /> ::<br /> * [[Multi Authentication]] - Iñaki Arenaza?<br /> ::<br /> * [[Multi Enrolment]] - Catalyst<br /> ::<br /> <br /> <br /> == Version 2.0 - Expected end of 2006 ==<br /> <br /> * [[IMS Learning Design]] - moodle.com<br /> :: Support for importing/exporting LD, converting Moodle activities and sequences of activities into a standard format for sharing, and importing standard sequences into Moodle courses<br /> * [[Conditional activities]] - moodle.com<br /> ::allowing dependencies and forced paths through the content. It also provides support for <br /> * [[Roles]] - moodle.com<br /> ::this new system will allow the creation of custom roles at site, course and activity level<br /> * [[Metadata]] - moodle.com<br /> ::build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outomes and curricula<br /> * [[Accessibility]] - moodle.com <br /> ::Full compliance with all major accessibility standards<br /> * [[Web Services API]]<br /> ::Providing remote control and access of Moodle services by other systems, as well as sharing of information between Moodle sites with trust relationships.<br /> * [[Repository API]] - moodle.com<br /> ::Abstract all file operations to an API that allows plugins for different external repositories.<br /> * [[Student Information API]]<br /> ::API for integrating external systems for managing student career<br /> * [[Community Hub]] - moodle.com <br /> ::Leverage above improvements into a system to network Moodles together.<br /> <br /> == Version 2.1 ==<br /> <br /> * [[Groups]] <br /> ::groups can also be defined at the site level, and activities can be assigned to course groups<br /> * [[Portfolio API]]<br /> ::Interface Moodle activities and repositories to help produce portfolios for internal assessment AND external publication<br /> <br /> <br /> <br /> [[Category:Core]]<br /> [[Category:Administrator]]<br /> [[Category:Developer]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roadmap&diff=26090 2006-02-03T14:10:42Z

<p>UrsHunkler: </p> <hr /> <div>This roadmap collects the best information about upcoming features in Moodle. It is not 100% certain - features may change according to available funding and developers.<br /> <br /> == Version 1.6 - Beta expected late February 2006 ==<br /> <br /> * [[Unicode]] - Moodle.com, Eloy Lafuente and Koen Roggemans<br /> ::Moodle is now 100% Unicode, which means any language can be mixed together and an end to a number of problems that different character sets caused us.<br /> * [[Documentation]] - Moodle.com and Helen Foster<br /> ::A new one-stop Wiki site for ALL Moodle documentation, including links from Moodle itself<br /> * [[Database]] - Moodle.com <br /> ::A new activity module that allows collaborative collection of structured data, useful for many things!<br /> * [[LAMS]] - LAMS Foundation<br /> ::Integrated via a course format and an activity module<br /> * [[Blogs]] - Daryl Hawes and Moodle.com<br /> ::Allows reflection on an ongoing basis. Entries are marked and can be viewed by user, course, group, site etc. Contains new keyword support. <br /> * [[Site Stats]] - Catalyst<br /> ::Provides statistics at a higher level than before (by course etc)<br /> * [[My Moodle]] - Catalyst<br /> ::A dashboard interface that allows an overview for each user of all their courses etc<br /> * [[Hive integration]] - Moodle.com and Harvest Road<br /> ::This initial integration with Hive allows teachers to upload, browse, search and select [[mod/resource/index|Resources]] within the external repository.<br /> * [[Multiple Groups]] - Moodle.com and Arab Open University<br /> ::Users can be part of multiple groups within a course.<br /> * [[IMS Resource]] - Eloy Lafuente and Alton College<br /> ::Supports the loading of any content package as a Resource, plus special support for NLN repositories.<br /> * [[Learning Design Export]] - Moodle.com and Open University of The Netherlands<br /> ::We plan to have a very simple export for any Moodle course into IMS LD format, as a proof of concept and to help the community start learning about IMS LD.<br /> * [[Granularised Backup]] - Catalyst and Eloy Lafuente<br /> ::<br /> * [[Chameleon]] - Andy Walker &amp; Urs Hunkler. <br /> :: It's in 1.6 CVS and you can test it live on http://chameleon-theme.unodo.de<br /> ::<br /> * [[Multi Authentication]] - Iñaki Arenaza?<br /> ::<br /> * [[Multi Enrolment]] - Catalyst<br /> ::<br /> <br /> <br /> == Version 2.0 - Expected end of 2006 ==<br /> <br /> * [[IMS Learning Design]] - moodle.com<br /> :: Support for importing/exporting LD, converting Moodle activities and sequences of activities into a standard format for sharing, and importing standard sequences into Moodle courses<br /> * [[Conditional activities]] - moodle.com<br /> ::allowing dependencies and forced paths through the content. It also provides support for <br /> * [[Roles]] - moodle.com<br /> ::this new system will allow the creation of custom roles at site, course and activity level<br /> * [[Metadata]] - moodle.com<br /> ::build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outomes and curricula<br /> * [[Accessibility]] - moodle.com <br /> ::Full compliance with all major accessibility standards<br /> * [[Web Services API]]<br /> ::Providing remote control and access of Moodle services by other systems, as well as sharing of information between Moodle sites with trust relationships.<br /> * [[Repository API]] - moodle.com<br /> ::Abstract all file operations to an API that allows plugins for different external repositories.<br /> * [[Student Information API]]<br /> ::API for integrating external systems for managing student career<br /> * [[Community Hub]] - moodle.com <br /> ::Leverage above improvements into a system to network Moodles together.<br /> <br /> == Version 2.1 ==<br /> <br /> * [[Groups]] <br /> ::groups can also be defined at the site level, and activities can be assigned to course groups<br /> * [[Portfolio API]]<br /> ::Interface Moodle activities and repositories to help produce portfolios for internal assessment AND external publication<br /> <br /> <br /> <br /> [[Category:Core]]<br /> [[Category:Administrator]]<br /> [[Category:Developer]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roadmap&diff=26089 2006-02-03T14:07:59Z

<p>UrsHunkler: </p> <hr /> <div>This roadmap collects the best information about upcoming features in Moodle. It is not 100% certain - features may change according to available funding and developers.<br /> <br /> == Version 1.6 - Beta expected late February 2006 ==<br /> <br /> * [[Unicode]] - Moodle.com, Eloy Lafuente and Koen Roggemans<br /> ::Moodle is now 100% Unicode, which means any language can be mixed together and an end to a number of problems that different character sets caused us.<br /> * [[Documentation]] - Moodle.com and Helen Foster<br /> ::A new one-stop Wiki site for ALL Moodle documentation, including links from Moodle itself<br /> * [[Database]] - Moodle.com <br /> ::A new activity module that allows collaborative collection of structured data, useful for many things!<br /> * [[LAMS]] - LAMS Foundation<br /> ::Integrated via a course format and an activity module<br /> * [[Blogs]] - Daryl Hawes and Moodle.com<br /> ::Allows reflection on an ongoing basis. Entries are marked and can be viewed by user, course, group, site etc. Contains new keyword support. <br /> * [[Site Stats]] - Catalyst<br /> ::Provides statistics at a higher level than before (by course etc)<br /> * [[My Moodle]] - Catalyst<br /> ::A dashboard interface that allows an overview for each user of all their courses etc<br /> * [[Hive integration]] - Moodle.com and Harvest Road<br /> ::This initial integration with Hive allows teachers to upload, browse, search and select [[mod/resource/index|Resources]] within the external repository.<br /> * [[Multiple Groups]] - Moodle.com and Arab Open University<br /> ::Users can be part of multiple groups within a course.<br /> * [[IMS Resource]] - Eloy Lafuente and Alton College<br /> ::Supports the loading of any content package as a Resource, plus special support for NLN repositories.<br /> * [[Learning Design Export]] - Moodle.com and Open University of The Netherlands<br /> ::We plan to have a very simple export for any Moodle course into IMS LD format, as a proof of concept and to help the community start learning about IMS LD.<br /> * [[Granularised Backup]] - Catalyst and Eloy Lafuente<br /> ::<br /> * [[Chameleon]] - Andy Walker &amp; Urs Hunkler. (It's in 1.6 CVS)<br /> ::<br /> * [[Multi Authentication]] - Iñaki Arenaza?<br /> ::<br /> * [[Multi Enrolment]] - Catalyst<br /> ::<br /> <br /> <br /> == Version 2.0 - Expected end of 2006 ==<br /> <br /> * [[IMS Learning Design]] - moodle.com<br /> :: Support for importing/exporting LD, converting Moodle activities and sequences of activities into a standard format for sharing, and importing standard sequences into Moodle courses<br /> * [[Conditional activities]] - moodle.com<br /> ::allowing dependencies and forced paths through the content. It also provides support for <br /> * [[Roles]] - moodle.com<br /> ::this new system will allow the creation of custom roles at site, course and activity level<br /> * [[Metadata]] - moodle.com<br /> ::build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outomes and curricula<br /> * [[Accessibility]] - moodle.com <br /> ::Full compliance with all major accessibility standards<br /> * [[Web Services API]]<br /> ::Providing remote control and access of Moodle services by other systems, as well as sharing of information between Moodle sites with trust relationships.<br /> * [[Repository API]] - moodle.com<br /> ::Abstract all file operations to an API that allows plugins for different external repositories.<br /> * [[Student Information API]]<br /> ::API for integrating external systems for managing student career<br /> * [[Community Hub]] - moodle.com <br /> ::Leverage above improvements into a system to network Moodles together.<br /> <br /> == Version 2.1 ==<br /> <br /> * [[Groups]] <br /> ::groups can also be defined at the site level, and activities can be assigned to course groups<br /> * [[Portfolio API]]<br /> ::Interface Moodle activities and repositories to help produce portfolios for internal assessment AND external publication<br /> <br /> <br /> <br /> [[Category:Core]]<br /> [[Category:Administrator]]<br /> [[Category:Developer]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Roadmap&diff=26088 2006-02-03T14:07:13Z

<p>UrsHunkler: </p> <hr /> <div>This roadmap collects the best information about upcoming features in Moodle. It is not 100% certain - features may change according to available funding and developers.<br /> <br /> == Version 1.6 - Beta expected late February 2006 ==<br /> <br /> * [[Unicode]] - Moodle.com, Eloy Lafuente and Koen Roggemans<br /> ::Moodle is now 100% Unicode, which means any language can be mixed together and an end to a number of problems that different character sets caused us.<br /> * [[Documentation]] - Moodle.com and Helen Foster<br /> ::A new one-stop Wiki site for ALL Moodle documentation, including links from Moodle itself<br /> * [[Database]] - Moodle.com <br /> ::A new activity module that allows collaborative collection of structured data, useful for many things!<br /> * [[LAMS]] - LAMS Foundation<br /> ::Integrated via a course format and an activity module<br /> * [[Blogs]] - Daryl Hawes and Moodle.com<br /> ::Allows reflection on an ongoing basis. Entries are marked and can be viewed by user, course, group, site etc. Contains new keyword support. <br /> * [[Site Stats]] - Catalyst<br /> ::Provides statistics at a higher level than before (by course etc)<br /> * [[My Moodle]] - Catalyst<br /> ::A dashboard interface that allows an overview for each user of all their courses etc<br /> * [[Hive integration]] - Moodle.com and Harvest Road<br /> ::This initial integration with Hive allows teachers to upload, browse, search and select [[mod/resource/index|Resources]] within the external repository.<br /> * [[Multiple Groups]] - Moodle.com and Arab Open University<br /> ::Users can be part of multiple groups within a course.<br /> * [[IMS Resource]] - Eloy Lafuente and Alton College<br /> ::Supports the loading of any content package as a Resource, plus special support for NLN repositories.<br /> * [[Learning Design Export]] - Moodle.com and Open University of The Netherlands<br /> ::We plan to have a very simple export for any Moodle course into IMS LD format, as a proof of concept and to help the community start learning about IMS LD.<br /> * [[Granularised Backup]] - Catalyst and Eloy Lafuente<br /> ::<br /> * [[Chameleon]] - Andy Walker &amp; Urs Hunkler<br /> ::<br /> * [[Multi Authentication]] - Iñaki Arenaza?<br /> ::<br /> * [[Multi Enrolment]] - Catalyst<br /> ::<br /> <br /> <br /> == Version 2.0 - Expected end of 2006 ==<br /> <br /> * [[IMS Learning Design]] - moodle.com<br /> :: Support for importing/exporting LD, converting Moodle activities and sequences of activities into a standard format for sharing, and importing standard sequences into Moodle courses<br /> * [[Conditional activities]] - moodle.com<br /> ::allowing dependencies and forced paths through the content. It also provides support for <br /> * [[Roles]] - moodle.com<br /> ::this new system will allow the creation of custom roles at site, course and activity level<br /> * [[Metadata]] - moodle.com<br /> ::build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outomes and curricula<br /> * [[Accessibility]] - moodle.com <br /> ::Full compliance with all major accessibility standards<br /> * [[Web Services API]]<br /> ::Providing remote control and access of Moodle services by other systems, as well as sharing of information between Moodle sites with trust relationships.<br /> * [[Repository API]] - moodle.com<br /> ::Abstract all file operations to an API that allows plugins for different external repositories.<br /> * [[Student Information API]]<br /> ::API for integrating external systems for managing student career<br /> * [[Community Hub]] - moodle.com <br /> ::Leverage above improvements into a system to network Moodles together.<br /> <br /> == Version 2.1 ==<br /> <br /> * [[Groups]] <br /> ::groups can also be defined at the site level, and activities can be assigned to course groups<br /> * [[Portfolio API]]<br /> ::Interface Moodle activities and repositories to help produce portfolios for internal assessment AND external publication<br /> <br /> <br /> <br /> [[Category:Core]]<br /> [[Category:Administrator]]<br /> [[Category:Developer]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Helen_Foster&diff=19472 2006-01-29T10:13:16Z

<p>UrsHunkler: </p> <hr /> <div>Helen Foster, Moodle Documentation Steward<br /> <br /> &lt;p&gt;Hi,&lt;/p&gt;<br /> <br /> &lt;p&gt;I work in web development with Andy Walker at Alton College, a [http://www.standards.dfes.gov.uk/beaconschools/ Beacon] sixth form college. The [http://moodle.org/mod/forum/discuss.php?d=28815 Object module] is our NLN materials in Moodle solution - you are welcome to try it. :-) In addition to our college [http://moodle.altoncollege.ac.uk/ Moodle], we're also encouraging and supporting secondary schools in using Moodle as part of the [http://ifp.altoncollege.ac.uk/ East Hampshire 14-19 Partnership].&lt;/p&gt;<br /> &lt;p&gt;My background is in maths and teaching. I've worked in Botswana as well as in the UK.&lt;/p&gt;<br /> <br /> Please read more on my [http://moodle.org/user/view.php?id=24152 Moodle profile page].</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Helen_Foster&diff=19471 2006-01-29T10:10:18Z

<p>UrsHunkler: </p> <hr /> <div>Helen Foster, Moodle Documentation Steward<br /> <br /> &lt;p&gt;Hi,&lt;/p&gt;&lt;p&gt;I work in web development with Andy Walker at Alton College, a [http://www.standards.dfes.gov.uk/beaconschools/ Beacon] sixth form college. The [http://moodle.org/mod/forum/discuss.php?d=28815 Object module] is our &lt;acronym title=&quot;National Learning Network&quot;&gt;NLN&lt;/acronym&gt; materials in Moodle solution - you are welcome to try it. :-) In addition to our college [http://moodle.altoncollege.ac.uk/ Moodle], we're also encouraging and supporting secondary schools in using Moodle as part of the [http://ifp.altoncollege.ac.uk/ East Hampshire 14-19 Partnership].&lt;/p&gt;<br /> &lt;p&gt;My background is in maths and teaching. I've worked in Botswana as well as in the UK.&lt;/p&gt;<br /> <br /> Please read more on my [http://moodle.org/user/view.php?id=24152 Moodle profile page].</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Helen_Foster&diff=19470 2006-01-29T10:08:25Z

<p>UrsHunkler: </p> <hr /> <div>Helen Foster, Moodle Documentation Steward<br /> <br /> &lt;p&gt;Hi,&lt;/p&gt;&lt;p&gt;I work in web development with Andy Walker at Alton College, a [http://www.standards.dfes.gov.uk/beaconschools/ | Beacon] sixth form college. The [http://moodle.org/mod/forum/discuss.php?d=28815 | Object module] is our &lt;acronym title=&quot;National Learning Network&quot;&gt;NLN&lt;/acronym&gt; materials in Moodle solution - you are welcome to try it. :-) In addition to our college [http://moodle.altoncollege.ac.uk/| Moodle], we're also encouraging and supporting secondary schools in using Moodle as part of the [http://ifp.altoncollege.ac.uk/ | East Hampshire 14-19 Partnership].&lt;/p&gt;<br /> &lt;p&gt;My background is in maths and teaching. I've worked in Botswana as well as in the UK.&lt;/p&gt;<br /> <br /> Please read more on my [http://moodle.org/user/view.php?id=24152 | Moodle profile page].</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Helen_Foster&diff=19469 2006-01-29T10:01:40Z

<p>UrsHunkler: </p> <hr /> <div>Helen Foster, Moodle Documentation Steward<br /> <br /> &lt;p&gt;Hi,&lt;/p&gt;&lt;p&gt;I work in web development with Andy Walker at Alton College, a &lt;a href=&quot;http://www.standards.dfes.gov.uk/beaconschools/&quot; title=&quot;External link - DfES The Standards Site: Beacon Schools&quot;&gt;Beacon&lt;/a&gt; sixth form college. The &lt;a href=&quot;http://moodle.org/mod/forum/discuss.php?d=28815&quot; title=&quot;Forum discussion with module for download&quot;&gt;Object module&lt;/a&gt; is our &lt;acronym title=&quot;National Learning Network&quot;&gt;NLN&lt;/acronym&gt; materials in Moodle solution - you are welcome to try it. :-) In addition to our college &lt;a href=&quot;http://moodle.altoncollege.ac.uk/&quot; title=&quot;External link - Alton College Moodle&quot;&gt;Moodle&lt;/a&gt;, we're also encouraging and supporting secondary schools in using Moodle as part of the &lt;a href=&quot;http://ifp.altoncollege.ac.uk/&quot; title=&quot;External link - the insite&quot;&gt;East Hampshire 14-19 Partnership&lt;/a&gt;.&lt;/p&gt;&lt;p&gt;My background is in maths and teaching. I've worked in Botswana as well as in the UK.&lt;/p&gt;<br /> <br /> Please read more on my [http://moodle.org/user/view.php?id=24152| Moodle profile page].</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19441 2006-01-26T16:45:22Z

<p>UrsHunkler: text reworked</p> <hr /> <div>Hi,<br /> <br /> I am a web designer specialising in Internet-based working and learning. The Moodle 1.5 CSS re-work was led by my proposals and guidance. I will accompany further Moodle development with theme management. In addition, I am developing a theme for MoodleDocs.<br /> <br /> * [[Themes]]<br /> * [[Templates]]<br /> <br /> --UrsHunkler 16 July 2005 13:21 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19440 2006-01-25T20:14:32Z

<p>UrsHunkler: </p> <hr /> <div>Hi,<br /> <br /> I am a web designer and have specialized on net based working and learning. I was instrumental in the creation of the themes framework for Moodle 1.5 and will accompany the further development doing Moodle theme management and a MoodleDocs theme.<br /> <br /> * [[Themes]]<br /> * [[Templates]]<br /> <br /> --UrsHunkler 16 July 2005 13:21 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=Developer_documentation&diff=404 2005-12-27T09:07:51Z

<p>UrsHunkler: reverted spam</p> <hr /> <div>[[Moodle architecture]]<br /> <br /> == How you can contribute ==<br /> <br /> Even if you are not a programmer there are things you can change or help with. :-)<br /> * [[LearningActivities|Learning activities]]<br /> * [[ThemeDevelopment|Themes]]<br /> * [[Languages|Languages]]<br /> * [[Database Schemas|Database schemas]]<br /> * [[Course formats]]<br /> * [[Bug tracker|Participating in the bug tracker]]<br /> <br /> == See also ==<br /> *[http://moodle.org/blocks/HOWTO.html A step-by-step guide to creating blocks]<br /> *[http://moodle.org/mod/resource/view.php?id=1267 Core API]<br /> *[http://moodle.sourceforge.net/dhawes-phpdoc/ Moodle PHP doc reference]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19439 2005-08-01T18:43:15Z

<p>UrsHunkler: </p> <hr /> <div>Hi,<br /> <br /> I am a web designer and have specialized on net based working and learning. I was instrumental in the creation of the themes framework for Moodle 1.5 and will accompany the further development doing some Moodle theme management.<br /> <br /> * [[Themes]]<br /> * [[Templates]]<br /> <br /> --UrsHunkler 16 July 2005 13:21 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19438 2005-07-20T07:29:41Z

<p>UrsHunkler: </p> <hr /> <div>Hi,<br /> <br /> I am a web designer and have specialized on net based working and learning. I was instrumental in the creation of the themes framework for Moodle 1.5 and will accompany the further development doing some Moodle theme management.<br /> <br /> * [[Themes]]<br /> <br /> --UrsHunkler 16 July 2005 13:21 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User_talk:Stencel&diff=22911 2005-07-18T19:41:29Z

<p>UrsHunkler: </p> <hr /> <div>Now you can send a message to me by clicking on the &quot;+&quot; (plus) tab on the top of this page. I will automatically be notified of your message by email.<br /> <br /> == Oooops ==<br /> <br /> Ooops. I added loads of topics on the teacher manual front page then saw the note saying contact you if you wish to add topics!!!<br /> <br /> Perhaps the 3rd party add on modules need to go on a seperate page as the first page will start to get really long.<br /> <br /> --<br /> <br /> Hi,<br /> <br /> I'll have a look at the topics you've created and just edit them, if necessary, ok?<br /> Re. the 3rd party add on modules - yes, I guess we'll have to move them to a separate page. (Edit - I have moved them now)<br /> <br /> Thanks Darren,<br /> <br /> Przemek<br /> <br /> == watchlist ==<br /> <br /> przemek<br /> you said once that the pages we modify automatically appear in our watchlist, right?<br /> rafal<br /> <br /> ---<br /> <br /> Yes, that's right. Is it not happening for you?<br /> <br /> Przemek<br /> <br /> == Theme Documentation ==<br /> <br /> Hi Przemek,<br /> <br /> some time ago I wrote in the forum to get in contact with you. Now it happens ;-)<br /> <br /> It is nice to see the new online home for the Moodle documentation. I am very curiuos how active this project will evolve.<br /> <br /> Martin sent me the link to this Moodle Docs site and proposed to write all theme related documentation here. He gave me [[Themes]] as the link. There I started to create a sub structure. Perhaps you have a look at it.<br /> <br /> An important question is, if the themes documention and a theme scrapbook is well suited within the &quot;Documentation for Developers&quot; section? The scrapbook should be in something like a &quot;Tipps &amp; Tricks&quot; section.<br /> <br /> --UrsHunkler 2005-07-13<br /> <br /> Hi Urs,<br /> <br /> First of all, thank you for your contribution :-)<br /> <br /> Regarding your question - as I understand it, the documentation you're writing will be for site admins who want to customize the look of their Moodle, right? If so, then I personally think that the theme documentation should be linked from the administrators', not developers' section. What do you think?<br /> <br /> --[[User:Stencel|Stencel]] 14 July 2005 20:31 (WST)<br /> <br /> Hi Przemek,<br /> <br /> I can give a clear yes-and-no-answer ;-) The documentation is <br /> * for web designers, who build themes<br /> * a base for developers to know how to build the hooks into their web pages<br /> * for admins too<br /> <br /> What about making it a topic from every section. So every body will be able to find the theme topic in his/her mainly used section.<br /> <br /> --UrsHunkler 2005-07-15 14:21:02 (WST)<br /> <br /> == Spam ==<br /> <br /> Hi Przemek,<br /> <br /> today I removed some porn spam on the start page. I think the spam attacks will increase when the docs are better known. I propose to give write access only to registered users. And that the important wiki pages are watched. <br /> <br /> To keep the registration process as easy as possible perhaps there is a way to use the moodle.org registration here? What do you think?<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 18 July 2005 19:41 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19437 2005-07-16T13:21:09Z

<p>UrsHunkler: </p> <hr /> <div>Hi,<br /> <br /> I am a web designer and have specialized on net based working and learning. I made the concept for the Moodle 1.5 CSS system and accompany the realization.<br /> <br /> * [[Themes]]<br /> <br /> --UrsHunkler 16 July 2005 13:21 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User_talk:Stencel&diff=22910 2005-07-15T14:21:02Z

<p>UrsHunkler: /* Theme Documentation */</p> <hr /> <div>Now you can send a message to me by clicking on the &quot;+&quot; (plus) tab on the top of this page. I will automatically be notified of your message by email.<br /> <br /> == Oooops ==<br /> <br /> Ooops. I added loads of topics on the teacher manual front page then saw the note saying contact you if you wish to add topics!!!<br /> <br /> Perhaps the 3rd party add on modules need to go on a seperate page as the first page will start to get really long.<br /> <br /> --<br /> <br /> Hi,<br /> <br /> I'll have a look at the topics you've created and just edit them, if necessary, ok?<br /> Re. the 3rd party add on modules - yes, I guess we'll have to move them to a separate page. (Edit - I have moved them now)<br /> <br /> Thanks Darren,<br /> <br /> Przemek<br /> <br /> == watchlist ==<br /> <br /> przemek<br /> you said once that the pages we modify automatically appear in our watchlist, right?<br /> rafal<br /> <br /> ---<br /> <br /> Yes, that's right. Is it not happening for you?<br /> <br /> Przemek<br /> <br /> == Theme Documentation ==<br /> <br /> Hi Przemek,<br /> <br /> some time ago I wrote in the forum to get in contact with you. Now it happens ;-)<br /> <br /> It is nice to see the new online home for the Moodle documentation. I am very curiuos how active this project will evolve.<br /> <br /> Martin sent me the link to this Moodle Docs site and proposed to write all theme related documentation here. He gave me [[Themes]] as the link. There I started to create a sub structure. Perhaps you have a look at it.<br /> <br /> An important question is, if the themes documention and a theme scrapbook is well suited within the &quot;Documentation for Developers&quot; section? The scrapbook should be in something like a &quot;Tipps &amp; Tricks&quot; section.<br /> <br /> --UrsHunkler 2005-07-13<br /> <br /> Hi Urs,<br /> <br /> First of all, thank you for your contribution :-)<br /> <br /> Regarding your question - as I understand it, the documentation you're writing will be for site admins who want to customize the look of their Moodle, right? If so, then I personally think that the theme documentation should be linked from the administrators', not developers' section. What do you think?<br /> <br /> --[[User:Stencel|Stencel]] 14 July 2005 20:31 (WST)<br /> <br /> Hi Przemek,<br /> <br /> I can give a clear yes-and-no-answer ;-) The documentation is <br /> * for web designers, who build themes<br /> * a base for developers to know how to build the hooks into their web pages<br /> * for admins too<br /> <br /> What about making it a topic from every section. So every body will be able to find the theme topic in his/her mainly used section.<br /> <br /> --UrsHunkler 2005-07-15 14:21:02 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19436 2005-07-13T11:27:36Z

<p>UrsHunkler: </p> <hr /> <div>* [[Themes]]<br /> <br /> --UrsHunkler 2005-07-13 11:27:36 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19435 2005-07-12T22:17:19Z

<p>UrsHunkler: </p> <hr /> <div>* [[Themes]]<br /> <br /> ----<br /> <br /> * [[user:urshunkler/monobook.css]]<br /> * [[user:urshunkler/myskin.css]]<br /> * [[MediaWiki:Monobook.css]]<br /> <br /> <br /> --UrsHunkler 2005-07-12 22:08:25 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19434 2005-07-12T22:08:25Z

<p>UrsHunkler: </p> <hr /> <div>* [[Themes]]<br /> <br /> ----<br /> <br /> * [[user:urshunkler/monobook.css]]<br /> * [[user:urshunkler/myskin.css]]<br /> * [[MediaWiki:Monobook.css]]<br /> <br /> --UrsHunkler 2005-07-12 22:08:25 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19433 2005-07-12T22:07:29Z

<p>UrsHunkler: </p> <hr /> <div>* [[Themes]]<br /> <br /> ----<br /> <br /> * [[user:urshunkler/monobook.css]]<br /> * [[user:urshunkler/myskin.css]]<br /> * [[MediaWiki:Monobook.css]]<br /> <br /> --[[User:UrsHunkler|UrsHunkler]] 2005-07-12 22:07:29 (WST)</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User_talk:Stencel&diff=22908 2005-07-12T22:06:14Z

<p>UrsHunkler: Theme Documentation</p> <hr /> <div>Now you can send a message to me by clicking on the &quot;+&quot; (plus) tab on the top of this page. I will automatically be notified of your message by email.<br /> <br /> == Oooops ==<br /> <br /> Ooops. I added loads of topics on the teacher manual front page then saw the note saying contact you if you wish to add topics!!!<br /> <br /> Perhaps the 3rd party add on modules need to go on a seperate page as the first page will start to get really long.<br /> <br /> --<br /> <br /> Hi,<br /> <br /> I'll have a look at the topics you've created and just edit them, if necessary, ok?<br /> Re. the 3rd party add on modules - yes, I guess we'll have to move them to a separate page. (Edit - I have moved them now)<br /> <br /> Thanks Darren,<br /> <br /> Przemek<br /> <br /> == watchlist ==<br /> <br /> przemek<br /> you said once that the pages we modify automatically appear in our watchlist, right?<br /> rafal<br /> <br /> ---<br /> <br /> Yes, that's right. Is it not happening for you?<br /> <br /> Przemek<br /> <br /> == Theme Documentation ==<br /> <br /> Hi Przemek,<br /> <br /> some time ago I wrote in the forum to get in contact with you. Now it happens ;-)<br /> <br /> It is nice to see the new online home for the Moodle documentation. I am very curiuos how active this project will evolve.<br /> <br /> Martin sent me the link to this Moodle Docs site and proposed to write all theme related documentation here. He gave me [[Themes]] as the link. There I started to create a sub structure. Perhaps you have a look at it.<br /> <br /> An important question is, if the themes documention and a theme scrapbook is well suited within the &quot;Documentation for Developers&quot; section? The scrapbook should be in something like a &quot;Tipps &amp; Tricks&quot; section.<br /> <br /> --UrsHunkler 2005-07-13</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19432 2005-07-12T21:11:05Z

<p>UrsHunkler: </p> <hr /> <div>* [[Themes]]<br /> <br /> ----<br /> <br /> * [[user:urshunkler/monobook.css]]<br /> * [[user:urshunkler/myskin.css]]<br /> * [[MediaWiki:Monobook.css]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19431 2005-07-12T21:10:49Z

<p>UrsHunkler: </p> <hr /> <div>* [[https://docs.moodle.org/index.php/Themes]]<br /> <br /> ----<br /> <br /> * [[user:urshunkler/monobook.css]]<br /> * [[user:urshunkler/myskin.css]]<br /> * [[MediaWiki:Monobook.css]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19430 2005-07-12T21:01:12Z

<p>UrsHunkler: </p> <hr /> <div>* [[user:urshunkler/monobook.css]]<br /> * [[user:urshunkler/myskin.css]]<br /> * [[MediaWiki:Monobook.css]]</div>

UrsHunkler https://docs.moodle.org/dev/index.php?title=User:Urs_Hunkler&diff=19429 2005-07-12T20:59:11Z

<p>UrsHunkler: </p> <hr /> <div>* [[user:urshunkler/monobook.css]]<br /> * [[MediaWiki:Monobook.css]]</div>

UrsHunkler