http://wiki.mipt.ru/index.php?action=history&feed=atom&title=Development%3AEnrolment_usage_overview 2026-05-07T06:59:18Z История изменений этой страницы в вики MediaWiki 1.42.1 http://wiki.mipt.ru/index.php?title=Development:Enrolment_usage_overview&diff=11070&oldid=prev 2024-10-21T08:51:12Z

<p>1 версия импортирована</p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <tr class="diff-title" lang="ru"> <td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">← Предыдущая версия</td> <td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">Версия от 08:51, 21 октября 2024</td> </tr><tr><td colspan="2" class="diff-notice" lang="ru"><div class="mw-diff-empty">(нет различий)</div> </td></tr></table>

Олег Давидович http://wiki.mipt.ru/index.php?title=Development:Enrolment_usage_overview&diff=11069&oldid=prev 2010-06-15T19:05:17Z

<p></p> <p><b>Новая страница</b></p><div>{{Infobox Project<br /> |name = Enrolment usage overview<br /> |state = In progress<br /> |tracker = MDL-21655<br /> |discussion = n/a<br /> |assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]<br /> }}<br /> {{Moodle 2.0}}<br /> <br /> =Goals=<br /> There is a lot of confusion related to guest access, enrolment of users, etc. This page is trying to sum up the usage of enrolments and guest access in various parts of Moodle.<br /> <br /> =Definitions=<br /> ; enrolment : All enrolled users enrolled in a course record in user_enrolments table. The original moodle/course:view is reset during 2.0 upgrade and all data is migrated to this new enrolment table.<br /> ; guest user : Local user account with username &#039;&#039;guest&#039;&#039;, for performance reasons guest id is cached in $CFG, guest is never returns by get_users_by_capability() or get_enrolled_users(), all write and dangerous capabilities are blocked in has_capability().<br /> ; viewing/inspection : Users with moodle/course:view at course or higher level, users are not visible inside course unless they post or do other visible action.<br /> ; course guest access : Those are users that are not enrolled or just viewing, but still &#039;&#039;somehow&#039;&#039; get through the require_login($course), the enrolment plugins are supposed to grant this temporary guest access, usually the user is granted some guest role on the fly.<br /> ; administrator access : Administrators do not have any role assigned any more, instead list of administrators is stored in CFG variable. Administrators are not returned from any accesslib queries, the only function explicitly dealing with administrators is the has_capability().<br /> <br /> =Core API=<br /> <br /> ; get_enrolled_users() : returns list of userids that are already enrolled (everybody on frontpage) optionally with some capability<br /> ; get_enrolled_sql() : return the sql select used in get_enrolled_users() <br /> ; isguest() : returns true for guest user account and users with temporary guest access<br /> ; isguestuser() : return true only for the real guest account (username==guest)<br /> ; is_siteadmin() : returns true for all site admins<br /> ; has_capability() : returns true if user has capability, if $doanything==true used returns true for all admins<br /> ; get_users_by_capability() : the same as in 1.9<br /> ; is_enrolled() : returns true if user enrolled, on frontpage true for everybody<br /> ; is_viewing() : returns true if user administrator or has inspect capability<br /> <br /> =Core usage=<br /> <br /> ==Group membership==<br /> Only enrolled users may be members of groups. In 1.9 and earlier we only guess by looking at roles that have moodle/course:view which is not hidden, this may actually return incorrect results if overrides used. All group membership is removed when unenrolling form course.<br /> <br /> Technically we need to look only at users that are returned by get_enrolled_users() when looking for new group membership candidates. Existing group membership should be filtered so that only enrolled users are displayed.<br /> <br /> ==Gradebook==<br /> <br /> We keep only grades of enrolled users. Gradebook shows only enrolled users that have the gradebook role. In future it could be controlled by a special capability instead, this was not possible in 1.9 for performance reasons.<br /> <br /> Anybody with capability may grade or manage gradebook.<br /> <br /> ==Logs and reports==<br /> In some cases we want to see only enrolled users, in others we want to see really all users. This should be decided by a new capability.<br /> <br /> ==User profiles==<br /> <br /> Only enrolled user have course visible profile.<br /> Users that have one of $CFG-&gt;coursemanager roles have profile on site level because we want them to be clickable on course description page. (This was originally controlled by isteacherinanycourse() which was both deprecated and incorrect.)<br /> <br /> Profile displays also user roles in course, the list of roles is the same as on the profile page.<br /> <br /> ==Participation page==<br /> <br /> Participants page displays only enrolled users (with moodle/course:participate capability).<br /> It shows only limited number of roles specified in the $CFG-&gt;profileroles setting.<br /> <br /> ==Messaging==<br /> <br /> There is an ongoing discussion about limiting of communication to Teacher-Student only, I do not think we should restrict this - they may use modules like Consultation or Dialog instead. In any case the current 2.0dev messaging needs a lot more work both on performance and usability.<br /> <br /> ==Comments==<br /> Comments can be controlled by capability.<br /> <br /> ==Ratings==<br /> Ratings can be controlled by capability.<br /> <br /> =Modules=<br /> <br /> ==Assignment==<br /> <br /> Only enrolled user with submit capability may submit.<br /> <br /> Users with capability may grade.<br /> <br /> ==Chat==<br /> <br /> Users with capability may chat.<br /> <br /> ==Choice==<br /> <br /> Enrolled users with capability may make a choice. In theory there could be a setting to require capability only.<br /> <br /> The enrolment is important especially when there is a limited number of slots or when we want to display list of users that did not make a choice yet.<br /> <br /> ==Feedback==<br /> <br /> Options:<br /> * Enrolled users with capability only<br /> * Users with capability<br /> * All users including guest (non standard feature disabled by default for security reasons)<br /> <br /> ==Forum==<br /> <br /> Anybody with capability may post. Enrolled users may get notifications via email or track new posts.<br /> <br /> ==Glossary==<br /> <br /> Anybody with capability may post.<br /> <br /> ==Lesson==<br /> <br /> Anybody with capability may try it, grades are recorded only for enrolled.<br /> <br /> ==Quiz==<br /> <br /> Anybody with capability could try it. Only enrolled with capability are displayed as those that did not pass grade yet. Only grades of enrolled are passed to gradebook.<br /> <br /> ==SCORM==<br /> Anybody with capability may try it.<br /> <br /> ==Survey==<br /> Only enrolled with capability may answer it.<br /> <br /> ==Wiki==<br /> <br /> Anybody with capability may edit.<br /> <br /> ==Workshop==<br /> <br /> Only enrolled with capabilities may participate.<br /> <br /> =Blocks=<br /> <br /> ==Online users==<br /> <br /> We need separate capability to see all or enrolled users.<br /> <br /> =See also=<br /> * [[Development:Role archetypes]]<br /> * [[Development:New permissions evaluation in 2.0]]<br /> * [[Development:New_enrolments in 2.0]]<br /> <br /> [[Category:Developer]]<br /> [[Category:Enrolment]]<br /> [[Category:Groups]]<br /> [[Category:Roles]]</div>

1>Skodak