Feature Wiki

Information about planned and released features

Tabs

Extend Permissions of Competence Management

Page Overview

[Hide]

1 Initial Problem

Competences and Competence Profiles can only be created, edited and organised via the Administration. If you give a role the Permissions "Visible", "Read" and "Edit Settings" for the administration entry "Competence Management", the role can edit all Competences.

Within the competence management it is not possible to control which Competences/Competence Profiles can be edited. All competencies can always be edited. In many scenarios, users should not be able to edit and create Competences, but should be able to create Competence Profiles from an existing competence set. Such a separation is currently not possible. 

2 Conceptual Summary

Permissions-Tab in Competence Categories

Competence categories get their own tab 'Permissions'. In the 'Permissions'-tab local roles can be created, roles can be imported, global roles can be assigned permissions. The Permissions are

  • Visible
  • Read
  • Edit Settings
  • Create Competences
  • Create Competence Categories
  • Insert Competence Template
  • Change Permissions
Permissions for competence categories enables users to read only a certain competence category, but they cannot make any changes. It is possible to make certain competence categories editable only by members of a certain role.

Extend Permissions of Competence Management

The competence management as such gets a new right for profiles:
  • Profiles are visible
  • Read Profiles
  • Create Profiles
  • Edit Settings of Profiles

3 User Interface Modifications

3.1 List of Affected Views

  • Administration >> Competence Management >> Permissions-Tab
  • Administration >> Competence Management >> Competence Categories >> NEW Permissions-Tab

3.2 User Interface Details

Permissions for Competence Categories
Extension of permissions in Competence Management

3.3 New User Interface Concepts

none

4 Technical Information

This is possible but would require major changes in the underlying architecture. All competence categories would need an entry in object_data and ref_ids. We might need a migration to these IDs at some points. Permission checks need to be introduced at several places. We need decisions on default permissions for core roles.

4.1 Technical Implications and Alternatives (4 Feb 2021), EDIT, 22 Mar 2021: Conceptional Rationale added

Killing, Alexander [alex], 4 Feb 2021: I started to outline an implementation of the current proposal and I would like to avoid the massive complexity with it.

  • If competence categories can be nested and the behaviour should be similar to repository categories (lokal roles, change existing objects and the like), the whole tree competence structure must be migrated to the main tree. As mentioned, this will change all IDs, and all tables that reference these IDs must be migrated, not only in the competence management, but also in consuming services like survey, tests and courses. This will be a lot of effort and error prone.
  • Even if this is done we end up with a technical structure that is overly complex, since the concepts of referencing in the repository (ref IDs for linking, no re-use of tree substructes, all instances are equal) and referencing competence templates (allowing to re-use tree substructures with one main instance) are not really compatible. This ends up with both reference concepts being part of the technical structure with makes it really hard to document already the underlying data structure.
A technical much simpler way would be to put permissions not on every competence category, but only on the top level of nodes in the competence hierarchy. Each top level node would define a subtree in the hierarchy that has its own permission as a whole (subtree). Not on each node. This could be compared to multiple ILIAS learning modules, that have their own chapter trees, but permissions are only defined on the top node.

Additional rationale (conceptional, not technical) mentioned in the Jour Fixe 22 Mar 2021, Killing, Alexander [alex]:
  • Our current experience when implementing competence structures with customers is that having a central (HR) department that works out a consistent competence taxonomy in negotiation with different stakeholders for the whole institution is a best practice. In this case a small number of people actually edit the competence taxonomy, there is no need for any change in the permission management.
  • The requirement to have substructures under distinct permission contexts is originated in the fact, that institional departments do not share a common agreement on the competence taxonomy. They are not willing or able to feed their requirements for a common competence taxonomy into a central place ensuring a consistent experience for the learner (and the institution as a whole, e.g. when it comes to reporting needs).
  • The current (second) concept allows to have these permission contexts only on a top level, the original idea tried to allow an even deeper structure of permission structures.
  • Having a high granularity in the responsibilities and management of the whole competence structure will foster bad practices. Negotiation on common consistent structures will not be necessary, the risk that cross-sectional competences (like soft skills, language or mathematical skills) will be defined multiple times in inconsistent ways will be higher. The lifecycle management of competence profiles that aggregate skills from very different places in the hierarchy might become impossible.

Zenzen, Enrico [ezenzen], 17 MAR 2021: Due to technical issues the feauture had to be revised. We still want to be able to use rights to control who can manage competences in individual areas. Accordingly, a new top level note "Competence Tree" is introduced. Access to the competence tree can be configured via rights.

To clarify the procedure, I have adapted the mockups and made them available in the following accordion.

Administration > Achievements > Competences (Mockup 1)
Administration > Achievements > Competences (Mockup 2)
Administration > Achievements > Competences (Mockup 3)
Administration > Achievements > Competences (Mockup 4)
Administration > Achievements > Competences (Mockup 5)
Administration > Achievements > Competences (Mockup 6)

5 Privacy Information

No relevant privacy issues involved.

6 Security Implications

Permission structure and complexity in ILIAS will grow. Admins need to understand these new permission nodes. Access checks need to be introduced in the code an we will need a greater number of test rail test cases.

7 Contact

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

9 Discussion

Kunkel, Matthias [mkunkel], 06 JUL 2020 : I still have some questions:

  • What impacts have these new permissions on the permission "Edit Settings"? At the time being, this permission allows to create new competence categories, new competencies, insert templates and – I assume – import competencies. It is also needed to create templates and template categories. Does the introduction of the new permission mean that the related actions are no longer possible with "Edit Settings" permission (similar to splitting up "Edit Settings" into "Edit Settings" and "Edit Members" in courses and groups)? Or are the new permissions only "sub-permissions" of "Edit Settings" (similar to "Edit Navigation" and "Edit Page Metadata" in the wiki)?
  • And I assume that having the permission "Create Competence" allows a user also to edit existing competencies in the related competence category, right? So the permission could also be labeled "Create and Edit Competence".
  • And what happens with a category in a category? Are permissions inherited? Do we need a "change existing objects" option to push permissions to already existing categories?

JourFixe, ILIAS [jourfixe], 06 JUL 2020 : We highly appreciate this suggestion and schedule the feature for ILIAS 7. The permissions for creating competencies and competence categories are extracted from the "Edit Settings" permission and have to be given to create related objects. "Create Competencies" is a distinct creation permission and not connected with "Edit Settings" (q2 by Matthias). Competence categories behave like usual RBAC objects and also offer "Change existing objects" like other RBAC objects.

JourFixe, ILIAS [jourfixe], 25 JAN 2021: We highly appreciate this suggestion and re-schedule the feature as decided in the last JF for ILIAS 8.

JourFixe, ILIAS [jourfixe], 22 MAR 2021 : We follow Alexander's suggestion and accept the introduction of a new element "competence tree" to handle the RBAC policies easily and to keep substructures free of RBAC settings (as already known from components like ILIAS learning module or media pool). Please add related test case(s) to the RBAC test case suite and update chap 2 accordingly.

Killing, Alexander [alex], 23 Mar 2021: I added some non-technical reasons to my comments above that reflect our current experience when implementing competence management in institutions. Especially the management of competence profiles that agreggate a collection of skill requirements requires a common lifecycle management and semantic consistence in the whole competence taxonomy. Spreading the responsibility to manage the competence taxonomy on a high-granularity-permission-substructures will simply foster bad practices in our opinion.

And another clarification: The second approach is a lightweight approach in comparision with the first one. It will only require an additional node type in the existing tree structure. This feature will still be based on Services/Tree. This feature will not add "an additional tree implementation".

10 Implementation

Because every Skill Tree includes its own export files now, the path for these files has changed. That is why no export files will be shown in the Export-tab of the Default Tree after updating from ILIAS 7 to ILIAS 8. Please simply create a new export file. If old export files are absolutely needed, they can be found by the sysadmin under the old path (with the old Skill Tree ID).

Test Cases

Test cases completed at 11 OCT 2021 by Zenzen, Enrico [ezenzen]

  • C1341: Kompetenzmanagement aktivieren
  • C49235: Recht „Kompetenzbäume anlegen“
  • C49229 : Kompetenzbaum anlegen
  • C49230: Recht „Lesezugriff“ auf Kompetenzen und Kompetenzvorlagen eines Kompetenzbaums
  • C49232: Recht „Kompetenzen bearbeiten“ innerhalb eines Kompetenzbaums
  • C49233: Recht „Kompetenzvorlagen bearbeiten“ innerhalb eines Kompetenzbaums
  • C1342: Kompetenzen anlegen und Kompetenzausprägungen hinzufügen
  • C49231: Recht „Lesezugriff“ auf Kompetenzprofile eines Kompetenzbaums
  • C49234:  Recht „Kompetenzprofile bearbeiten“ innerhalb eines Kompetenzbaums
  • C18542: Kompetenzprofile anlegen

Approval

Approved at 2021-11-23 by Falkenstein, Rob [rob].

Last edited: 20. Oct 2022, 13:57, Famula, Thomas [tfamula]