Feature Wiki

Information about planned and released features

Tabs

Adopt Settings From Other SCORM Modules

Page Overview

[Hide]

1 Initial Problem

SCORM settings are very complex, not always intuitiv and wrong settings can lead to unwanted behavior of the SCORM module. Therefore it is important to choose the correct settings for the SCORM modules.

There are no templates for SCORM settings meaning that the settings have to be changed for every SCORM module seperately.  Since the default settings are not suitable in most szenarios, this leads to a huge amount of workload on installations where SCORM is frequently used in multiple modules. And it can lead to mistakes when forgetting settings or selecting a wrong option. 

To solve this problem we suggest to implement a feature where settings from one SCORM module can be adopted to another. With this feature it would be possible to use specific SCORM module as templates to reduce workload and errors. 

2 Conceptual Summary

The settings of SCORM modules will get a new subtab in which another SCORM module can be selected from which the settings can be adopted.

It will be possible to select out of all modules with matching SCORM version. In addition to that the acting ILIAS-login need to have the permission "Edit Settings" for the SCORM modules.

Optional (depending on funding): After a SCORM module is selected for adopting the setting from it, a comparision with the divergent settings will be shown.

The relevant settings for SCORM modules are stored in the database table "sahs_lm". When adopting the settings from another SCORM module the column of the table can be used. Only the ID needs to be changed.

The following settings should be left out: title, description, online, tile Image. This is not a problem since they all are not included in the table "sahs_lm". 

3 User Interface Modifications

3.1 List of Affected Views

  • SCORM module -> Settings

3.2 User Interface Details

The subtab "Adopt Settings From SCORM Module" will be added to the settings of a SCORM module (see mockup).

In this tab the SCORM module from which the settings should be adopted can be selected using ilExplorer.

We optionally (depending on funding) suggest to implement a view that shows the differences in the settings between the current module and the selected module (see mockup).

3.3 New User Interface Concepts

The feature is implemented with existing UI components and does not introduce any new UI concepts.

3.4 Accessibility Implications

The use of existing UI components does not introduce any new implications for accessibility.

4 Additional Information

4.1 Involved Authorities

4.2 Technical Aspects

This feature depends on ilExplorer.

4.3 Privacy

No new personal data is collected or processed as a result of the implementation of the feature.

4.4 Security

The implementation of the feature does not introduce any new attack vectors.

The only security relevant consideration needed is to decide which permission needs to be granted for showing a SCORM module in the selection view.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers: Wischniak, Stanislav [wischniak], Mix, Eva [emix] 

4.6 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'.

5 Discussion

Kunkel, Matthias [mkunkel], 05 JAN 2026: Thank you for this feature request. I can well understand that it would be a great relief if you could easily apply proven settings with just a few clicks.

The request reminds of the revised Personal Default Settings in tests which has been implemented for 11 with Revision and Enhancement of the ‘Personal Default Settings‘. A comparable requirement is addressed in the test here.

Have you already had a look at this feature and how the workflow is designed there? It is a bit different to what you are suggesting above.

From the point of consistent user workflows in ILIAS, it would be great if the way of adopting settings would be the same in different components – except there are good and serious reasons to implement a different behaviour. But in this case, I would highly appreciate to know them and to see them in the feature request. Thank you!

Mix, Eva [emix], 05 JAN 2016: Thank you for your remark. We decided against an implementation similar to Revision and Enhancement of the ‘Personal Default Settings‘ due to the following reasons:

  1. During the development conference in Duisburg (27 MAR 2025) we presented our plan to implement the adoption of settings for SCORM modules and where explicitly asked to do it in a different way than it is implemented for the test. The main reason we were given are potential differences between ILIAS major versions as also mentioned in the feature request for the personal default settings in tests.
  2. Our proposal keeps the technical effort minimal since no new data structure is needed. The settings do not need to be stored in a separate table.
  3. The implementation we suggest avoids the potential maintenance errors that arise from differences between ILIAS versions. The settings are always synchronized since the settings are adopted from another SCORM module of the same ILIAS platform.
  4. At the development conference in Marburg (10 and 11 SEP 2025) we presented our idea for this feature as described on this page and the attendees agreed with our idea. The only concern was with which permission is required for allowing to take over the setting. So we revised it afterward and decided on the permission "Edit Settings".
  5. The use case for our feature is slightly different than the use case for "personal settings". With this feature it will be possible to adopt settings from your own SCORM modules and therefore use them as your own default settings. However, the main need is to create global defaults since SCORM needs special settings depending on the authoring tool. These settings should be provided centrally so the local administrators do not need to know about the specifics of the wanted settings and they only need to use the correct SCORM module to adopt the settings from. So, our feature proposal supports both the scenario of personal defaults and the scenario of central provided defaults.

6 Implementation

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

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

6.3 Privacy

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

6.4 Approval

Approved at {date} by {user}.

Full Screen

Last edited: 5. Jan 2026, 14:37, Mix, Eva [emix]