feat: Ckeditor custom configuration enhancement

[azayati]

Rationale

Currently, for each module using Ckeditor, in order to configure a custom ckeditor with custom plugins, we base on /commons-extension/ckeditorCustom/config.js, this my cause problems with custom plugins displaying

1. Functional requirements

This feature must not change the display of the custom ckeditor plugins for each module.

2. Non Functional Requirements

• Expected volume & Performance requirements

  • No change.

• Security requirements (Authentication, Authorizations, Audit track / traceability, data retention…)

  • No modification with actual behavior

• Extensibility requirements (Identified extension points, pluggable implementations...)

  • Define a ckeditor custom config as a shared js module for each module using ckeditor instead of commons one (/commons-extension/ckeditorCustom/config.js)
  • This may need a fix in require.js to be checked and confirmed:
  • eXo.require.config = cfg = requireJs
  • eXo.require.config = cfg = require
  • Introduce the load-group tag in module configuration of gatein-resources.xml which will avoid the module loading by a dedicated portlet injected in an addon container as we are doing generally. This will be based on this change

• Configurability requirements (properties introduced, default settings, jobs, etc...)

  • No configuration

• Requirements related to existing users data

  • No change

• Requirements related to existing features (ex: Add a button to existing modules...)

  • No change.

• Feature Flag (property name, default status, target audience, functional behavior)

  • No feature flag

• Other NFR (ex: Use of VueX, Vue, Vuetify)

  • No change.

3. Impacts

• Documentation to update?

  • No documentation to update

• Training level / Change management needs

  • No change management needs

4. Software Architecture

Architectural impact has to be evaluate with a technical study

• Security

  • No security change

• Access (GUI, API…)

  • No change.

• Services & processing

  • No change.

• Data and persistence

  • No data model modification

• Support for clustering

  • No change.

• Support for multitenancy

  • No change.

• Integrations

  • No change.

• Migration strategy

  • No change.

5. Annexes

• Reasoning that explain the technical choices
• Impacts (ex: impact on public REST/Java API)
• References (links...)

[rdenarie]

@margondicco I put this mip in open status, as there is no priority on that

[plamarque]

requirements will be covered by MIP-59

[rdenarie]

@azayati can you confirm that MIP-59 cover your needs and close this one if yes. Thanks

[boubaker]

@azayati @rdenarie This was my suggestion to give some solutions about an MIP that was in progress at that time by you. Knowing that it was a cross cutting concern, I though you will do it before we do, which wasn't the case because we needed this technical enhancement on Gamification Connectors (MIP #64) and Rich Editor Configuration Extensibility (MIP #59).

So, both enhancements was already considered in previous MIPs. Thanks for having created the MIP. You can close it @rdenarie @azayati if you are ok.

[azayati]

So, both enhancements was already considered in previous MIPs. Thanks for having created the MIP. You can close it @rdenarie @azayati if you are ok.

closed @boubaker