nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Alfresco Content/Process App Module/extension mechanism

binduwavell

I have created the following issue for the Alfresco Content App (ACA):

Module/extension mechanism · Issue #179 · Alfresco/alfresco-content-app · GitHub

Following is the initial detail, let's use this page on the community to discuss our needs in this area:

I believe that there has been some work to create a module system where we can create an Alfresco Content App (ACA) customization artifact and drop it into a location in the OOTB app without extending the code of the ACA. It would be great to have some discussion about the approach(es).

There are a few higher level goals here:

Provide a way for implementors to create re-usable enhancements to ACA that can be composed when creating a solution.
- e.g. I want to add AOS and Case Management
Provide a way for implementors to create enhancements that are likely to be upgrade safe

Following is an initial list of highly desirable features of such a system (in my opinion):

It should be possible to add page components to the router via configuration
- It should be possible to configure that certain custom pages show up in the toolbar
- It should be possible to configure that certain custom pages don't show up in the toolbar (if they are contextual.)
It should be possible to add buttons to the main toolbar
It should be possible to configure actions for the "New" menu
It should be possible to configure actions for the User menu (far right of toolbar)
It should be possible to add document list actions (and associated logic for when to display/enable the same) via configuration
- Ideally it should be possible to affect the ordering of these actions via configuration
- Ideally it should be easy to add an action to route to a custom page
- Ideally it should be easy to route to another ADF app; passing context, credentials and a back link (I will create an ADF issue for this.)
- Ideally one action can be configured as the default in certain conditions (i.e. don't go to preview, instead route to another application when a document is activated.)
It should be possible to configure custom result columns
- Ideally it should be possible to configure different columns depending on context. e.g. under contracts I want to show one set of columns, under finance a different set of columns should be displayed
It should be possible to configure custom cell content renderers
It should be possible to configure flag providers
Once search is fleshed out it should be possible to configure advanced search providers
- It should be possible to configure the zero state when a search returns zero results
It should be possible to configure additional "smart folders" like "My Favorites", "Shared Documents" etc.
- Ideally it should be possible to affect the ordering of these via configuration
It should be possible to configure preview components
It should be possible to configure metadata forms (create, edit, view at least)
It should be possible to configure custom field renderers fro metadata forms.
It should be possible to configure Open With menu items
It should be possible to configure "More Options" items
Would be great to allow us to configure components to trigger during the upload process
- Some might be passive (once upload completes perform some API calls against the uploaded docs)
- Some might be active, gather metadata before or after the upload
It should be possible to configure left and right trays based on contextual information/logic
Ideally "modules" can interact with each other. As such, having some control over load order of modules may be important.

As an overarching goal there should be a single config file in ACA and one in each "module" that plugs the module into the ACA. i.e. don't make devs sift through many different configuration files. Ideally configuration merging/replacement strategies will be well documented and easy to determine the effective configuration once all modules have been deployed.

I'm sure other folks will have additional ideas, I hope this is a reasonable starting point.

Find more posts tagged with

Application Development Framework

Comments

douglascrp

It would be useful to have something similar to evaluators (both document list and module).

About the items below, a good example would be to be able to implement something just like the uploader-plus addon:

Would be great to allow us to configure components to trigger during the upload process
Some might be passive (once upload completes perform some API calls against the uploaded docs)
Some might be active, gather metadata before or after the upload

binduwavell

I just posted the following ADF feature request related to this discussion: Provide a best practice / sample implementation for cross-app routing · Issue #2871 · Alfresco/alfresco-ng2-components ·…

Here is the detail from that issue:

As ADF starts being used we expect implementors to create and share many types of components. Additionally it is likely that some special purpose apps will be created. I believe it will be very useful for such apps link to each other, passing context and credentials and possible a return path.

I realize that this is likely more of an Alfresco Content/Process App type issue. However I believe it will affect bespoke apps as well built with ADF. As such, I think that providing some guidelines on how to perform app linking (and return) will be beneficial for folks creating ADF solutions.

Imagine we are creating an ADF application for a large company. Realistically we may want to create apps for each department or possible for each role/use-case. Imagine a sales rep is in the Sales App and they find some documentation related to a product that is in development. It would be ideal if the Sales App could route to the Engineering App passing along the context of the product the sales rep located and also any credentials that were used to log into the Sales App. This way, the sales rep will enter the Engineering App without having to provide credentials again and they will be navigated to the appropriate user experience for the product they are interested in. Ideally the routing mechanism would understand that the user came from the Sales App and would in the case provide a button in the toolbar to go back to where they were in the Sales App when they entered the Engineering App.

dvuika

Good feedback, thanks. We already have an Upload Service with a set of hooks: ADF Component Catalog It's a good candidate to extend with more lifecycle events like you've mentioned above.

mromano

Great list

afaust

While the specific features / use cases for individual components may be useful as examples / validations, I personally am much more interested in a generic extension / customisation concept at this point, which should be applicable to any part of an eventual DMS/Collab app - even those added by extensions from 3rd-party providers.

Regarding components / component instances...

Ability to

Remove a component instance
Replace a component instance
Change the component type while keeping all other attributes (i.e. replace base implementation with extension)
Add a component instance before / after another component instance
Add / Modify / Remove configuration attributes of a component instance
Target a specific component instance, i.e. if same component type is used twice in a context / page, I only want to apply customisation to one of them
Target component instances of a specific type
Target a component instance at any level of nesting, i.e. when components wrap each other (nesting in top-level markup or via component specific markup), don't have to unwrap/modify all layers just to add/modify a minor thingy

Regarding other stuff...

Ability to

Remove / modify / add a routing
Bundle multiple customisations into an atomic bundle
Provide multiple bundles of customisations per extension / addon module
Have customisation / bundle of customisations or extension / addon module depend on another (for activation / implicit order)
Have customisation / bundle of customisations or extension / addon module ordered on additional priorities / via administrator intervention (latter unlikely without a server component)
Have customisation / bundle of customisations or extension / addon module be enable/disable-able at runtime via administrator intervention (unlikely without a server component)
Target a single customisation / bundle of customisations only to
- specific routing, generally or based on tokens from the route
- specific user / role / group
- arbitrary dynamic evaluation via provided evaluator function / component
Provide configuration (app.config.json, and others?) mutations (removal / modification / addition)
Provide custom i18n resources, potentially overriding defaults
Provide custom SCSS variables, potentially overriding defaults
Switch between SCSS variable sets for different routes / contexts (or reload browser with current app state but different SCSS variable set)
Have end-user / customer "guaranteed-last-wins" override over any customisation applied from extension / addon modules

deas0815

Excellent write-up Bindu!

To be honest, getting (retrofitting?) all this (Share alike) runtime extensibility into the ACA and/or ADF looks like a huge effort to me. I might be wrong, but I don't think this functionality has been a first class design goal. Maybe there were even compromises sacrificing potential implementation. I'd appreciate designers and stake holders of those components making a statement about their feelings with regards to general technical feasibility.

dvuika

For ADF 2.2 release we are working on Lazy Loading support that opens doors to many great scenarios, including modules that are loading extra features on demand and adding extra routes for the application and main routing. So I suggest reading on that: Angular Docs

mikel_asla

I published this post trying to expose our view, hope it helps

ohej

We really appreciate the momentum on this topic. Keep the good feedback coming.

‌ and I will pick up this topic early next week for internal discussions to see how we can plot a strategy for covering some of these use cases. Please note that this is not a commitment (yet), but we are listening and discussing. We will most likely be reaching out for some interviews to gather more structured feedback.

Stay tuned.

anakin59490

Hi,

alfresco-content-app is a great job !

But it will be very useful if ADF app could communicate with platform-jar structure in order to reproduce this kind of simple scenario : Form from sdk3 to ADF

Congratulation for your work !!

ohej

Hi all

I just wanted to give a heads up that we have not forgotten about this topic. We've had quite a few internal meetings about the topic last week, and we are actively exploring options.

Essentially we are working on a mechanism that allows runtime loading of "plugins", which would allow you to hook into different parts of the application - routes, content projection and much, much more.

We're currently doing some internal evaluation to see if the potential solution is fit for purpose. Once we feel good about it, we will start doing some validation with you guys where we present the proposed solution and gather feedback.

We haven't planned out the exact way we share the findings, if it will be a blog, tech talk live, individual or group meetings - most likely a combination.

We will start sharing some technical details soon!

deas0815

This page seems to be one of the entry points with regards to the recent UI runtime-extensibility-/module efforts. People jumping in at this time might get the impression it is already over. The other day, Denys Vuika mentioned on Twitter it is covered somewhere in TTL. Just saying.

cjose

I just saw this thread for the first time and thought I'll add an example approach which we took recently for a demo which we built on top of Alfresco Process Workspace aka APW (OOTB ADF based app with APS) and leveraging some components of ACA . In this case I leveraged the "App" container in APS as a case container. Then used the app.config.json in APW to determine the things I want to include/exclude in each Apps. An example entry in the app.config.json show below. Hopefully this will help someone develop case management style apps using ADF!

"1001": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Drone Case Management",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "defaultLandingPage": "insights/support-cases",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showOOTBDashboards": false,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "apsApp": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showInsights": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showProcesses": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showTasks": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showCreateTask": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showCreateProcess": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showContents": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showAdvSearch": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "showDataLookup": true,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"accordionGroups": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"insights": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"default": "support-cases",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"items": [{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "support-cases",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Cases & Faults"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; },
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "sentiment-analysis",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Sentiment Analysis"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}]
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"advsearches": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"default": "case-search",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"items": [ {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "case-search",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Search Cases"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; },
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "fault-search",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Search Faults"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}, {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "recall-search",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Search Recalls"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}, {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "repair-search",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Search Repairs"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}]
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"datalookups": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"default": "models",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"items": [{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "customers",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Customers"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}, {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "id": "models",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "name": "Drone Models"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}]
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; },‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The above config resulted in..

afaust

This requires the customer / client to override the packaged app.config.json, which violates the idea of an immutable app shipped by the vendor (which was a big argument for Alfresco to push for JAR extensions in ACS). Ideally, any extensibility feature would not require overriding default files.

Are there any plans for APS to support moving away from "magic numbers" for targeting such customisations to specific apps (i.e. the DB ID 1001 for your app) towards proper app naming? I.e. I'd like to be able to create a customisation for process app using the same abstract (logical) ID in DEV, UAT and PROD, without having to account for their different DB IDs, e.g. having separate config files for each target environment.

I hope all those "names" are localised somewhere, i.e. not like the ADF / APW language selection list which is always English even after user already selected German language.

dvuika

Would be nice if you raise a ticket for the language selection list with steps to reproduce and ADF version. If you find JIRA difficult, we also accept the GitHub tickets and then manually move them to JIRA if needed: https://github.com/Alfresco/alfresco-ng2-components/issues/new. Thanks in advance.

afaust

Since APS is an Enterprise product, the proper way is to go through Support, which I can't. The customer has filed their ticket today as ACT 00964167. They are typically a few weeks behind on reporting issues we find in our project(s), because 1st level support is annoyingly inefficient in reproducing obvious out-of-the-box issues and requires a substantial amount of hand-holding.

cjose

Thanks for the feedback Axel. As I said, this is something that I adopted for the current version of APS. Creating a logical environment-agnostic name for all deployment models is an item that I hope will be tackled as part of Activiti 7 and APS 2.0, and agree it is a pain! Feel free to provide your valuable comments to all the Activiti 7 related RFCs such as https://community.alfresco.com/community/bpm/blog/2018/04/11/rfc-activiti-cloud-application-service

Btw, the environment specific model ids eg:1001 were replaced with model keys (environment agnostic) in Activiti 6. Another reason for me to believe that it will be fixed in APS 2.0

john_knowles

Quick update for you Denys just merged version 1.4 which includes the first phase of extensibility work. Please see the documentation for more info on the details.

We are looking forward to feedback on the progress so far on both extensibility in the app, and the associated documentation.