Define custom navigation targets of the app manager

[KralMar]

One should be able to design additional html-elements/pages that get appended to each page/widget/app. Examples are imprint/privacy policy or help pages.
Certain app manager elements (e.g. the top navigation) should be customizable and be able to specify custom endpoints to deliver the content of these links.

NEXT STEP:

• Define and agree on the concept

[m-rau]

Suggested solution is to reuse existing components:

custom content implementation

Custom content is to be implemented as a simple endpoint delivering static content.

Definition of a static file handler, e.g. from core4/api/v1/request/_content with a file about.html in this folder. The following static file handler will deliver all files out of this folder, e.g. http://domain/core4/api/v1/content/about.html

        (r'/content', CoreStaticFileHandler, {
            "path": "/api/v1/request/request/_content",
            "static_path": "/api/v1/request(_content",
            "title": "core4os static content", "protected": True
        })

define custom menu

The mapping of menu items to endpoint is to be specified in core4.yaml. This solution allows to customise the deployment by setting a custom core4os configuration, e.g. at /etc/core4/local.yaml.

The custom menu configuration is to be delivered to the FE. Suggestion is to use the existing /setting endpoint. This requires the mapping between menu items and endpoint as in the following example (see core4.yaml):

user_setting:
   _general:
     language: EN
     menu:
       About this App Manager: /home4/api/v1/about
       Imprint: /home4/api/v1/imprint
       Privacy Protection: /home4/api/v1/privacy

To access the custom configuration the FE addresses ``http://domain/core4/api/v1/setting/_general/menu

[marekmru]

From my point of view this is fine. It is extensible and covers the need for additional items. @m-rau

[m-rau]

please watch this: modification of the default user settings requires an update in current regression tests. To be more specific: to make tests successful, the (default) navigation must be included into the expected results. For example tests/api/test_setting.py::test_default_settings_override

[marekmru]

Resolved in #73:

• Addedd an about widget
• About widget is referenced in core4.yaml
• should be returned by the settings api
• is rendered in core4ui / webapps (remove node_modules, yarn.lock and do a 'yarn install')

#73

[m-rau]

I will merge and test. Need to consider #81

[m-rau]

merged and tested. The following issues have been identified:

1. Bug: /settings API doesnt include / merge settings from local.yaml #81 is rejected. Refactoring the navigation configuration from dict to list is the solution

2. bug identified: the custom link is not working. It seems that rather the key than the value is populated as the link (About instead of /about).

[m-rau]

assigned to @marekmru for fixing and refactoring

[marekmru]

No this is just the internal mapping. What happens on the page is:

const path = (this.menu.find(val => val.label === type) || {}).path

soo there is a lookup on the path for the iframe

[m-rau]

I will retest when the current pull requests are merged into develop and ready for testing

[m-rau]

Is working. Ticket closed.

[m-rau]

I was testing the wrong version. Latest version in branch develop is not working.
@marekmru: please check! The settings variable menu is now a list. This requires an update in the FE as expected.

[m-rau]

Furthermore: please remove the Profile link from the default menu. The only default item now is Logout.