[ACS-6630] Added models and API classes for extensions manager config table

[swapnil-verma-gl]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x")

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation
• Other... Please describe:

What is the current behaviour? (You can also link to an open issue here)
APIs and models do not exist for the extensions manager configuration table feature

What is the new behaviour?
Added models and API classes for extensions manager. Moved some models from extensions library to js-api library

Does this PR introduce a breaking change? (check one with "x")

• Yes
• No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Certain model classes from the extensions library have been moved over to the js-api library. As such, if there are imports of any such classes (listed below), then those would have to be updated to be imported from @alfresco/js-api

1. ActionRef
2. RouteRef
3. RuleRef
4. RuleParameter

Other information:

[eromano]

@popovicsandras @DenysVuika @swapnil-verma-gl Extension should not depend from JS-API please review this PR

[swapnil-verma-gl]

@eromano The dependency of extensions library on js-api is not something that is being added in this PR, but rather something that is pre-existing. This can be seen in the following instances -

1. dynamic-tab.component.ts
2. viewer-extension.interface.ts
3. rule.extension.ts
4. navigation.state.ts
5. profile.state.ts
6. selection.state.ts

Having said that, if we do decide that this is not a valid approach, then we would have to figure out another solution to provide the availability of the actionRef, ruleRef, routeRef and ruleParameter classes in js-api as we need to create backend endpoints using these classes

[eromano]

I guess we need the opposite we need to clear the one you have indicated and remove js-api as dep

[DenysVuika]

Do not move interfaces to js-api if they do not belong to REST api calls and ACS backend

[DenysVuika]

this should not be part of the JS-API library as it has nothing to do with the REST api calls and ACS backend

[swapnil-verma-gl]

This interface is used by the RuleRef model, which is in turn being used in the newly created REST api call for saving the extension state on the ACS backend.

[popovicsandras]

To not repeat the same mistake again, would it be possible to define the nx enforce-module-boundaries rule and whitelist only those packages which a package can really rely on?

[swapnil-verma-gl]

Do not move interfaces to js-api if they do not belong to REST api calls and ACS backend

The interfaces and classes were moved because they are being planned to be used in the new REST api for saving extension state on the backend.

@DenysVuika @eromano If, however, we do not want to move those models over, then I guess some of the options we have are

1. Create duplicate models between the extensions and the js-api libraries.
2. Keep the models in extensions as-is, and for only the js-api layer, use a more permissive type for parameters/return types/etc like any. For any of the other layers (i.e. components, services etc), we can use the models being exported from extensions.

IMHO, I would prefer the second approach, as it would minimise code impact, and ensure that there are type restrictions in places that matter the most (components, services). However, it would also mean using the keyword any at a time when we want to reduce its usage.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[swapnil-verma-gl]

Since the movement of interfaces from extensions to js-api was impacting HxP and was not deemed a good approach, for now, what I've done is revert the movement back to its original state. The JS-API layer (settingsApi.ts) now uses the 'any' keyword for its all its purposes instead, with the layers following that (for e.g., extensions-manager.service.ts, present in adf-core) using the models and interfaces from extensions instead.
@DenysVuika @eromano do you guys think this is a viable workaround for now?