Product Communities

Request for Feature Enhancement (RFE) Summary: Automate TLS certificate renewal Use-case: Imagine you have 20+ different websites running on your AEMaaCS instance, each one with its own domain name, and therefore its associated TLS certificates. Further imagine that there are dev, staging and prod environments, both for preview and publish. Finally, the certificates may not be wildcard certs (*.example.org) but specific subdomain (preview.example.org, preview-st.example.org, ...).   So you have easily 50+ certificates to renew, and they will not renew at the same time, but across the whole year. Having to manually renew each certificate is error-prone and time-consuming. Also, in order to do this job, the person needs to have elevated administrative rights, but the job itself does not have a lot of added value.   It would therefore be appreciable to automate the renewal of the TLS certificates. In a different environment in the past I was using the certbot tool integrat

Request for Feature Enhancement (RFE) Summary: We should have an improved way of authentication and  authorization of GraphQL endpoint.In the current design, even unauthenticated or improperly authenticated requests are allowed to hit the endpoint with 200 response code. Instead we should have 401 or 403 response code with proper messages. Use-case: If we are doing any implementation on basis of response code the current implementation will not work as it will always giving 200 as response code. Current/Experienced Behavior: In the current design, even unauthenticated or improperly authenticated requests are allowed to hit the endpoint with 200 response code.  Improved/Expected Behavior: If access token is not correct or request is unauthenticated then we should have 401 or 403 response code with proper error messages. Environment Details (AEM version/service pack, any other specifics if applicable): AEM as SaaS Customer-name/Organization name:   Screensho

Request for Feature Enhancement (RFE) Summary: I want to be able to migrate content created in each AEM environment (dev, stg, prd) to another environment on the console without going through the package manager. Specifically, I would like to be able to migrate by environment on the content fragment screen. Use-case: Example: It will be possible to migrate a content fragment created in the dev environment to the stg environment on the console. (In this case, the status of the public information will not be carried over.) Current/Experienced Behavior:Content fragments cannot be migrated to a different environment on the console Content fragments cannot be migrated to a different environment on the console Improved/Expected Behavior: Content fragments can be migrated to a different environment on the console Environment Details (AEM version/service pack, any other specifics if applicable): AEM version：2025.1.19352.20250131T194709Z Customer-name/Organization name: Yuki Mama /

Request for Feature Enhancement (RFE) Summary: Better way to create custom AEM components Use-case: One needs to build from scratch a new AEM component Current/Experienced Behavior: In the current AEM world, there are way too often the situations when developers end up building new AEM components (and not use the core components).   The experience of building a new component is not very pleasant, prone to human mistakes due to the heavy ponderous coding. Working manually with the XML to define the dialogs makes the developer very often lose focus on the big picture and easy get lost into details about not forgetting to add the well-known <items> element, or to keep track of tabs, or to properly arrange dialog fields, or to make the dropdowns work (specially when we have multiple dependent ones) and so on. All becomes even more complicated when he needs to (also manually) add extra clientlibs having to careful when writing it and not add a typo. On top of this, h

Request for Feature Enhancement (RFE) Summary: Making timelines more resilient to heavy workflow activities.  Currently timelines timeout because the number of nodes that it has to transvers is over the threshold.  We had to purge and reduce our timelines from 30 days to 5 days in order for us to see the timeline results. Use-case: We heavy workflows that causes the timelines to transverse over 30,000 and fail to return results. Current/Experienced Behavior: We expect the OOTB functionality of timelines should work as expected. Which out create custom indexes Improved/Expected Behavior: OOTB indexes should be able used to ensure timeline return in a timely fashion and not timeout. Environment Details (AEM version/service pack, any other specifics if applicable): AEM 6.5 SP19 Customer-name/Organization name: Toyota Screenshot (if applicable):   Code package (if applicable):  

Request for Feature Enhancement (RFE) Summary: New content fragment editor console doesn't show the "Source Edit" option despite being enabled and visible. It appears correctly on the old/classic console Use-case: Our Content Fragment Model has a multi-line text field configured with default type as "rich text".Under path -  /apps/dam/cfm/admin/clientlibs/v2/authoring/contenteditor/editors/StyledTextEditor.jsWe can find source edit under "uiSettings" as seen below -  The source edit option appears on the old/classic console -    But is missing on the new console -  Current/Experienced Behavior: Source Edit option is missing on the new console for editing CF Improved/Expected Behavior: Source Edit option should be displayed on the new console for editing CF Environment Details (AEM version/service pack, any other specifics if applicable): AEM Release - 2025.3.19823.20250304T101418Z Customer-name/Organization name: EPAM Screenshot (if appl

Request for Feature Enhancement (RFE) Summary: Ability to use "granite:class" and "granite:data" in the new CF editor Use-case: We developed a show/hide fields plugin for the new CF editor based on a type selection made in a select field. For this purpose we used the example provivided in the docs: https://developer.adobe.com/uix/docs/services/aem-cf-editor/api/data/#setting-styles-to-the-field api.setStyles(fieldName, {"display": "none"}); However, this is not an optimal solution, as we need to hide each field per name instead of creating a generic plugin that could be reused on any content fragment. If we had an option to retrieve the value of a custom data attribute, then our plugin could be reusable. Current/Experienced Behavior: The "granite:class" and "granite:data" set in the CF model is not present in the HTML, and custom data attributes cannot be retrieved by custom plugins. Improved/Expected Behavior: The "granite:class" and "granite:data" set in the CF model is p

Request for Feature Enhancement (RFE) Summary: Add an API/extension point that would allow developers to change the rootPath for the Asset/CF/Content picker via a JS plugin: https://developer.adobe.com/uix/docs/services/aem-cf-editor/api/ Use-case: Our AEMaaCS project hosts more than 100 websites, each site has its own dedicated root folders for sites and assets (including subfolders for specific content fragment types). We had a custom, JS-based solution in the old CF editor to change the root paths of the CF/Content picker so that when an author opens the picker, it takes him to the correct location by default. This greatly improves the editorial experience of our 700+ authors that work on multiple sites. Current/Experienced Behavior: Asset/CF/Content picker always opens the root folder and editors need to navigate manually to their site and the correct folder. Improved/Expected Behavior: Customization can be enabled to programmatically set the correct root folder via JS, as

Request for Feature Enhancement (RFE) Summary: The current API and the example shared in the docs to toggle (show/hide) fields in the new CF editor does not work as expected and contains multiple issues. Docs: https://developer.adobe.com/uix/docs/services/aem-cf-editor/api/data/#setting-styles-to-the-field Use-case: We have a few CF models where fields are shown or hidden depending on the type selection an editor makes. After creating a new CF, the editor first needs to select a provider, and then different fields show depending on the selection. Current/Experienced Behavior: While developing a small plugin for the new CF editor to show/hide fields based on a selection according to the documentation provided [1]. Concretely, we are relying on the api.setStyles , but we noticed two bugs:1) This approach works fine for standard input fields, but not for select boxes/enumeration fields, they remain visible even after we try to hide them with CSS display:none2) The standard i

Request for Feature Enhancement (RFE) Summary: New permission to remove the replace button on assets. Use-case: We have a lot of squad working in AEMAACS and for some areas we need to have more granularity on the permission, for example some areas can't publish, others can't upload assets and some areas can't replace the assets, so we need to have this permissions on the access control. Current/Experienced Behavior: We don't have this granularity to change this access level. Improved/Expected Behavior: The expectation is to have an access profile created with the “Replace” option profile disabled, in order to eliminate the risk of accidentally replacing the campaign image. We are currently exposed to this risk at all times. Environment Details (AEM version/service pack, any other specifics if applicable):   2025.3.19823.20250304T101418Z Customer-name/Organization name: Santander S.A Screenshot (if applicable):   Code package (if applicable): &