Suppressing Chapters if Functionality is deactivated

1 Initial Problem

The help chapters are hung to screen Ids. Some chapters describe functionality that is inside the main menu to call attention to it and point out how very handy it is. Since the help cannot know what is switched. Thus we need to decide either to hide stuff or to expose users to texts about functionality not available to them. 

Currently we take a ridiculous way: We produce one release that is "overhung" with chapters asuming everything is switches on and one release "sparse" assuming that some things are switched off. 

2 Conceptual Summary

We want to assign Main Menu Items IDs (like mm_pd_port) to help chapters. If the installation the help is running on has not activated toe Main Menu Item that very chapter is suppressed and not shown. 

3 User Interface Modifications

3.1 List of Affected Views

Online Help Learning Module > Content > Screen IDs 

3.2 User Interface Details

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}

4 Technical Information

Killing, Alexander [alex], 27 May 2019: I think it could be possible to use the information from the global screen here. Fabian should als have a look at this idea. In the long run an "is a feature activated" information should be provided from a different component api, not from something coupled to the UI imo.

5 Contact

• Author of the Request: Tödt, Alexandra [atoedt]
• Maintainer: Killing, Alexander [alex]
  
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

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

• …

7 Discussion

Killing, Alexander [alex], 27 May 2019: I support the general idea.

Schmid, Fabian [fschmid], 28 May 2019: The linking of the chapters with the "external" IDs of the MainBar items is good from my point of view. One reason for the introduction of these internal IDs in the GlobalScreen service was the online help. So this is the right way out of mine to use this. The components from which the (MainBar-) items originate have control over these IDs. The IDs are currently also used, for example, in the rendering of the MainBar.
More problematic is surely to query the status of a feature via a respective (MainBar) item, i.e. whether the respective feature is available. The query will of course provide the correct result, but it is the wrong place to request this, so to speak. As Alex rightly says, this coupling to the GS service is not quite right. But for now it could be the solution. The question is still, how the online help can get a single item the easiest way.
Go ahead and thank you very much for your ideas for solving the problem with the OnlineHelp!

JourFixe, ILIAS [jourfixe], 03 JUN 2019 : We highly appreciate this suggestion and schedule it for 6.0.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

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

Approval

Approved at {date} by {user}.