Settings tab

[nikku]

Adds a dedicated settings tab to the app:

Closes #2913

[crobbins215]

Will watch

[nikku]

I took another look into this PR and believe we have the following things to address:

• Sourcing settings ("config") for selected extensions
• Settings vs. flags, who wins? ➡️ I propose flags overrule settings, but we indicate if there is an override happening
• Settings UI (optional for first iteration)
  • Consider foundations for styling (Carbon UI)?
• Test the solution

---

I updated the PR, cf. attached screenshot:

[lmbateman]

Just a few comments and questions:

• I think a Settings page within the application will be very helpful.
• Are we showing all available settings options to the user? If not, we should probably provide a link to a documentation page that lists all available settings.
• I'm not sure I have a full grasp of flags and settings yet, but
  • If someone has gone to the trouble of setting up a flag in a separate file, it makes sense to me that the flag should override the setting (especially if the user doesn't have permissions to edit the file).
  • If a setting is overridden by a flag, we should definitely let the user know.
• Will there be other sections in the Settings page besides Canvas and Startup Flags?

[nikku]

Will there be other sections in the Settings page besides Canvas and Startup Flags?

Not for the moment, but the infrastructure will allow us to expand this.

If a setting is overridden by a flag, we should definitely let the user know.

Taken care of I think, cf. UI sketch.

Are we showing all available settings options to the user? If not, we should probably provide a link to a documentation page that lists all available settings.

What will be the benefit of that documentation page? Whatever is reasonable for the user to "edit" will be (some day maybe) possible to edit via settings, all flags are already documented.

[nikku]

Implementation wise we currently have two things:

• A config service, with pluggable providers
• flags, read in the app as well as passed and read in the client

I propose the following:

• Flags become a special configuration, with a flag: prefix, this allows us to query the existance of flags, i.e. config.get('flag:disable-plugins')
• Flags cannot be set, so config.set('flag:disable-plugins', true) will error

We could extend the config interface to allow querying different values, i.e. flags and user settings, returning the first match:

// ensure flags are considered first
config.get([ 'flag:enable-new-context-pad', 'setting:enable-new-context-pad' ], false)

To be considered:

• Change of some settings requires reload of the application / re-open of an editor tab. We want to indicate this to the user. Especially toggling camunda connector templates will be challenging with the current architecture.

To be considered:

• We currently set an ignore path for element templates (not reading camunda templates); alternatively we can simply hook up another element template provider if the flag is read, and disable it, and "unhook" it once the config is disabled. An elegant solution is to be determined.
• If we don't do this, then setting most flags as "setting" will require a "restart the editor for the changes to take effect" notice.

[nikku]

We were (again) able to make it without this 🙃, however we concluded that mid-term our users would benefit from a settings tab.