It very much undermines our efforts and the expectation of trust when something as simple as an individual being assigned as a teacher on the site (system) level can monitor and edit grades of every course and that there is no a way for student or teacher to see this capability. Often this type of setting is made without understanding the consequences. And it is frequently not the specific assignment of an individual that is the problem (that individual may be trusted and respected by all concerned), but the control that it takes away by doing it invisibly that is the issue.

Roles should be as transparent as possible, most specifically to the teacher and most likely also the student.

+foreach($caps as $cap) { + if (has_capability($cap->name, $testedcontext, $user->id)) $hascaps[$cap->name] = $cap; +}

This would be an extremely expensive calculation, especially if the user were allowed to walk the context chain and display calculated permissions at each level.

It might be possible to write a more efficient algorithm capable of calculating the full set of permissions in a single pass through the data, but the algorithm would probably be very complicated.

In discussion http://moodle.org/mod/forum/discuss.php?d=90826, Tim Hunt suggested an interim solution. Rather than showing the complete set of calculated permissions, Tim suggested displaying them one at a time. Tim writes:

"a new tab next to assign and override that lets you select a user and a capability, and then automatically draws the table ...."

Here Tim is referring to the table format described in http://docs.moodle.org/en/How_permissions_are_calculated

The table (see screenshot) displays the permission data relevant to a single has_capability calle. It displays it in such a way that the viewer can easily perform/verify the calculation mentally by visually tracing the path of the algorithm through the table. In fact, the viewer can easily perform/verify the calculation at each level of the context chain. The viewer animates the display mentally, without need for Up and Down buttons.

As I said, this would be an interim solution. In practice, a user is almost never interested in the value of a single permission, but wants to see them all.

http://docs.moodle.org/en/How_permissions_are_calculated

The files are:

::::roletab.php – point your browser at this file and enter 3 parameters
::::::::capability – e.g., mod/quiz:attempt
::::::::context level – e.g., MODULE
::::::::instance id – e.g., the id of the quiz

::::get_permission_table – add these functions to lib/accesslib.php

The table is printed for the current user. The result of has_capability() is also displayed as a check. If you want to test a module or block context, you must first access the module or block context to ensure that the access data is loaded (since access data below course level is only loaded on demand). For example, try to attempt the quiz.

Feedback and discussion here: http://moodle.org/mod/forum/discuss.php?d=91993

if it is easy please try to explain it here and I will ask several ppl to read it and we will see if they understand it

anyway this may be a very useful feature for developers

http://docs.moodle.org/en/How_permissions_are_calculated

It is a feature for users. For most users today, roles are a black box that they do not understand and that they are afraid of. Transparency is for them, not for developers. Developers can always read the code.

The table is easy to explain, but the explainee must obviously have a working mental model of capabilities, permissions, assignments, overrides and how they work. This includes (1) every admin and every teacher who has permission to override roles. When we give a teacher permission to override, we give them incredible power to fiddle with Moodle's core functionality. So yes, they better understand this stuff! Giving a teacher override permission is like giving the keys to your car to someone. You check first that they know how to drive.

The docs wiki article was a multi-purpose article. It explains a lot more than a user would need to know in order to use the table. I will write a version of the article for teachers, but only when there is a feature available for them to use and I know what it looks like (Tim Hunt and I are working on this in http://moodle.org/mod/forum/discuss.php?d=91993. For a user, I would only document (1) how to set up the table (2) how to scan the table. The article will be very short. For exmple: list the role assignments in the top row and place the overrides underneath. Then scan the table as in the diagram you spot an imbalance.

Re: explaining to children. My mentor years ago taught me "you'll know you've got it right when you can explain it to a child." I certainly meant no offence to children, and hope none was taken

A ROLES EXPERT HELPING A ROLES NOVICE TROUBLESHOOT A ROLES-RELATED PROBLEM.

I'll explain the use case below. I hope to convince you that a feature designed to increase the transparency of roles should NOT be a feature "For Admins Only." like Tim Hunt's Users' Roles Report (third party, modules and plugins database, which is only available in the reports section of the Site admininstration menu).

The use case:

A roles_expert is anyone with a good understanding of permissions, including "how permissions are calculated." A roles_novice is a Moodle user with the ability to follow simple instructions from the expert. While the expert and novice may occasionally share the same physical location and have accounts on the same Moodle site, and sometimes even be the same person, the use case requires none of the above. Specifically, the expert must be able to help the novice (1) without logging in to the novice's site (2) communicating only e-mail, messaging, forum posts, etc.. For example, the novice may be a user posting to a moodle.org forum and the expert may be a moodler wanting to be helpful. Even when expert and novice share a physical location and have accounts on the same Moodle site, the expert may not be in a position to give direct help, e.g., by "logging in as" the novice or meeting with the novice. For example, the expert may be a Moodle administrator who is too busy to spare more than a few minutes helping.

Here's a typical scenario. The novice is a teacher who has created a forum, but is being prevented from posting to the forum for some unknown reason. The novice reports the problem to moodle.org. The expert (a helpful moodler) suspects a roles problem and replies by asking the novice to (1) log in to Moodle, reproduce the problem (2) use the new feature to get permission information (3) paste the output into a reply forum post. The expert reviews the output and (hopefully) diagnoses the problem.

Secondary use cases include

• a user troubleshooting his own problems
• a user troubleshooting another user's problem while logged in as that user

Both use cases are equivalent, since there is only one actor (the expert), not two. As in the main use case, the user should not require admin privileges.