Extend the ‘Scope’ option for Global Content Styles

1 Summary

There may be instances where you use global content styles on your own system but do not wish to make them available to others for further use.

For example, here on docu.ilias.de, we use a content style in the administration area for the login page. This style has very specific styling elements that should NOT be used in other groups within the docu.

Therefore, the functionality of the scope of global content styles is to be extended.

2 Problem Statement

Global Content styles are automatically available to all users who have the relevant editing rights in a course, group, etc. They can only be assigned to specific categories and cannot be applied beyond that.

There is no way to restrict a global content style so that it can only be used for groups, courses or by the administration.

Pages that are designed by the administration cannot use its own style, that isn't available for all users. Examples: login page, logout page, dashboard

3 Concept

The ‘Scope’ option for global content styles should be extended.

When one clicks on ‘Set scope’, courses and groups should also be available to select.

To make it easier to tell them apart, the ‘Scope’ column should not only display the title of the scope but also provide a link to it. After all, there may be instances with the same names.

In addition, the option ‘For administrative use only’ should be added to the actions menu in the content styles tab. This means the style will be available, for example, under Administration > Users and Roles > Authentication and Registration > Style but NOT within categories, courses or groups.

4 User Interface Modifications

4.1 List of Affected Views

4.2 User Interface Details

4.3 New User Interface Concepts

No new user interface concepts needed.

4.4 Technical Aspects

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Non-Functional Implications

5.1 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

5.2 Privacy

{ Please list here all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. Use the Privacy Guidance for Feature Requests to fill out this section correctly. }

5.3 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

6 Process Information

6.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers: Seibt, Alina [alina.seibt]

6.3 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

7 Discussion

8 Implementation

Feature has been implemented by {Please add related profile link of this person}

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

8.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

8.4 Approval

Approved at {date} by {user}.