mirror_php/moodle
1
0
Fork 0
mirror of https://github.com/moodle/moodle.git synced 2025-01-18 05:58:34 +01:00
Code Issues Projects Releases Wiki Activity

MDL-21695 Permissions and overrides help strings

Browse Source 
AMOS BEGIN
 HLP overrides.html,[overridepermissions_help,core_role]
 HLP permissions.html,[permission_help,core_role]
AMOS END
This commit is contained in:
David Mudrak 2010-05-17 12:43:02 +00:00
parent cd8236983d
commit 52236f053b
5 changed files with 3 additions and 129 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
admin/roles/check.php
View File

@ -118,7 +118,7 @@ if ($tabfile) {
} }
// Print heading. // Print heading.
echo $OUTPUT->heading_with_help($title, 'checkpermissions', 'role'); echo $OUTPUT->heading($title);
// If a user has been chosen, show all the permissions for this user. // If a user has been chosen, show all the permissions for this user.
$reportuser = $userselector->get_selected_user(); $reportuser = $userselector->get_selected_user();

2
admin/roles/lib.php
View File

@ -484,7 +484,7 @@ abstract class capability_table_with_risks extends capability_table_base {
protected function add_header_cells() { protected function add_header_cells() {
global $OUTPUT; global $OUTPUT;
echo '<th colspan="' . count($this->displaypermissions) . '" scope="col">' . echo '<th colspan="' . count($this->displaypermissions) . '" scope="col">' .
get_string('permission', 'role') . ' ' . $OUTPUT->help_icon('permissions', 'role') . '</th>'; get_string('permission', 'role') . ' ' . $OUTPUT->help_icon('permission', 'role') . '</th>';
echo '<th class="risk" colspan="' . count($this->allrisks) . '" scope="col">' . get_string('risks','role') . '</th>'; echo '<th class="risk" colspan="' . count($this->allrisks) . '" scope="col">' . get_string('risks','role') . '</th>';
} }

2
admin/roles/override.php
View File

@ -138,7 +138,7 @@ echo $OUTPUT->header();
if ($tabfile) { if ($tabfile) {
include($tabfile); include($tabfile);
} }
echo $OUTPUT->heading_with_help($title, 'overrides', 'role'); echo $OUTPUT->heading_with_help($title, 'overridepermissions', 'role');
// Show UI for overriding roles. // Show UI for overriding roles.
if (!empty($capabilities)) { if (!empty($capabilities)) {

40
lang/en/help/overrides.html
View File

@ -1,40 +0,0 @@
<h1>Overrides</h1>
<p>
Overrides are specific permissions designed to override a
role in a specific context, allowing you to "tweak" your
permissions as required.
</p>
<p>
For example, if users with the role Student in your course
can usually start new discussions in forums, but there is
one particular forum for which you want to restrict that
capability, then you can set an override that PREVENTS
the capability for Students to "Start new discussions".
</p>
<p>
Overrides can also be used to "open up" areas of your
site and courses to give users extra permissions where
it makes sense. For example, you may want to experiment
giving Students the ability to grade some assignments.
</p>
<p>
The interface is similar to the one for defining roles,
except sometimes only relevant capabilities are shown,
and you will also see some capabilities highlighted to
show you what the permission for that role would be
WITHOUT any override active (ie when your override is
set to INHERIT).
</p>
<p>
See also
<a href="help.php?file=roles.html">Roles</a>,
<a href="help.php?file=contexts.html">Contexts</a>,
<a href="help.php?file=assignroles.html">Assign Roles</a> and
<a href="help.php?file=permissions.html">Permissions</a>.
</p>

86
lang/en/help/permissions.html
View File

@ -1,86 +0,0 @@
<h1>Permissions</h1>
<p>
Permissions are the settings that you grant for specific capabilities.
</p>
<p>
For example, one capability is "Start new discussions" (in forums).
</p>
<p>
In each role, you can choose to set the permission for such a capability
to one of four values:</p>
<dl>
<dt>NOT SET</dt>
<dd>This is the default setting, generally. It's a neutral setting that
means "use whatever setting the user already had". If a role
gets assigned to someone (eg in a course) that has this permission for
a capability, then the actual permission they'll have will just be
the same as they already had at higher-level contexts (eg categories
or system level). Ultimately, if permission is never allowed at any
level, then the user will have no permission for that capability.
</dd>
<dt>ALLOW</dt>
<dd>By choosing this you are granting permission for this capability
to people who are assigned this role. This permission applies
for the context that this role gets assigned plus all "lower"
contexts. For example, if this role is a student role assigned
to a course, then students will be able to "start new discussions"
in all forums in that course, UNLESS some forum contains an
override or a new assignment with a Prevent or Prohibit value
for this capability.</dd>
<dt>PREVENT</dt>
<dd>By choosing this you are removing permission for this capability,
even if the users with this role were allowed that permission in
a higher context.</dd>
<dt>PROHIBIT</dt>
<dd>This is rarely needed, but occasionally you might want to completely
deny permissions to a role in a way that can NOT be overridden at
any lower context. A good example of when you might need this is
when an admin wants to prohibit one person from starting new
discussions in any forum on the whole system. In this case they
can create a role with that capability set to "Prohibit" and then
assign it to that user in the system context.
</dd>
</dl>
<h1>Conflict resolution of permissions</h1>
<p> Permissions at a "lower" context will generally override
anything at a "higher" context (this applies to overrides
and assigned roles). The exception is PROHIBIT which can not
be overridden at lower levels.
</p>
<p> If two roles are assigned to a person in the same context, one with
ALLOW and one with PREVENT, which one wins? In this case, Moodle will
look up the context tree for a "decider". </p>
<p> For example, a student has two roles in a course, one that allows
them to start new discussions, one that prevents them. In this case,
we check the categories and the system contexts, looking for another
defined permission to help us decide. If we don't find one, then
permission is PREVENT by default (because the two settings cancelled
each other out, and thus you have no permission).
</p>
<h1>Special exceptions</h1>
<p> Note that the guest user account will generally be prevented from
posting content (eg forums, calendar entries, blogs) even if it
is given the capability to do so.
</p>
<p>
See also
<a href="help.php?file=roles.html">Roles</a>,
<a href="help.php?file=contexts.html">Contexts</a>,
<a href="help.php?file=assignroles.html">Assign Roles</a> and
<a href="help.php?file=overrides.html">Overrides</a>.
</p>