Feature Wiki

Information about planned and released features

Tabs

Permission Screen Revision

Page Overview

[Hide]

1 Description

The current permission screen needs to tell the user a little bit more on the status of a given role:
  • Parent nodes where "break inheritance" is set.
  • The fact that the role has no read permission up to the current level, if this is the case. See also bug #5370. This has been topic in recent devconfs already.

2 Status

3 Additional Information

  • If you want to know more about this feature, its implementation or funding, please contact: Alex Killing / alex.killing (at) gmx.de

4 Discussion

JF 2 Nov 2009: We highly appreciate both features for 4.1. We should discuss how this information is presented in the user interface in the best way.

Former feature reports in Mantis by Florian Suittenpointner:
  • Short explanations for available permissions: Within permission tables (above all those of global roles), there isn't any facility to get to know what a specific permission is exactly for. There could be another two columns that shortly explain the effect of activating a permission and the necessary permission prerequisites to do so, i.e., which other permissions have to have been granted before.
  • Permission inheritance sitemap: Up to now, the permission inheritance (and/or its discontinuation) cannot be viewed all over the Repository. Thus, with scenarios that use a lot of Courses, Groups, local roles, inheritance discontinuation and permission protection, it can become hardly comprehensible and understandable which role still has what permission in which position. There could be a kind of permission sitemap for a role that depicts the validity and inheritance of roles, based on a diagramm of the Repository tree.
Matthias Kunkel & Stefan Meyer, 31 May 2010:
  1. Removing table "Add new role" and adding toolbar button "Add New Role"
  2. New create screen for role with
    • title
    • description
    • radio options for "Initial Permissions" with values "Empty permissions" | "Copy permissions" (IF "Copy..." radio options for all available roles and templates are shown)
    • "Change existing objects"
    • Add role | Cancel
  3. Role permission screen (see also "Role Permission Screen Revision")
    • Page title should not use role name as description but as title and show role description in description row
    • Acccordeon for "Copy role permissions" (currently at the bottom of the page)
    • Box for "Role permissions" with accordeons for each object type
    • "Special options" ("Change existing objects", "Protect permissions")
  4. Moving "Administrate" to section "General Operations" and rename it "Edit permissions" (as it is called on the role permission screen)
  5. Renaming section "Permission settings" to "Special permissions settings"
  6. Adding "Protect Permissions" checkbox
  7. Adding "Revoke Permissions" checkbox: option takes away all permissions, sets local policy and gives no permissions for any object, incl. protect permission; if checked, JS is enabling "Local Policy" and "Protect Permissions" automatically.
  8. If "Hide Permission Settings" is enabled for an object type in «Administration > Modules, Services and Plugins», there is no checkbox for this object in the Create New Objects section.
  9. The sorting of create permissions is following the settings "Position in Add-New-Object List" in «Administration > Modules, Services and Plugins».

Needs clarification:
  • Visibility of roles with revoked permissions:
    • Are roles with "Revoke Permissions" setting shown with filter "...current content"?
    • Should all possible permissions be displayed for these roles?
  • Where do we place information about "revoked permissions" and "break inheritance" for each role?
Matthias Kunkel, 01 June 2010:
  • Another idea concerning sorting of permissions: why do we separate General and Special Operations? For users this is not really helpful. And sometimes it is even misunderstanding, e.g. for forums: WRITE is often interpreted as "writing a post" (because people do not read the entire list and do not find this permission in the special operations). To ged rid of this distinction would also allow to sort the permissions better according to our progression concept (weak to strong permissions).
  • Concerning Create New Role: It would be great to have a checkbox at the creation screen to make the "home category" of this role a selected desktop item of all role members. This workflow is currently very time-consuming for such a simple action.

5 Follow-up

Full Screen

Last edited: 17. Apr 2025, 15:10, Kunkel, Matthias [mkunkel]