Build better products with our product team
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: Screenshot (if applicable): Code package (if applicable):
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, he often needs to go on the Granite UI Foundation specification page to lookup for the component in question and see what is the overall structure, what attributes it accepts and what they do, and then come back in the XML and manually add what he needs. Currently the Components tool (/libs/wcm/core/content/sites/components.html) is very poor. It is only giving you info data, not giving you much power to edit the component. Improved/Expected Behavior: Have a built-in UI tool to design a component in a more visual way rather then manual XML work, that should do the following: 1. It can be integrated with the available Granite typical components for an easy drag and drop in the dialog design. It can also provide easy access to each Granite component behavior, elements and so on. By having a visual drag-and-drop approach it can prevent developer for breaking the XML. It can contain with hints and documentation tooltips, for ease of understanding and guidance for making best choices 2. It can provide a list of available clientlibs from project for selectionIn this way it will prevent the developer to make typos and not properly link his component to the expected clientlib 3. It can better control granite data, renderconditions, granite classes, *-showhide-target etcHaving a holistic way across the entire dialog will avoid having inconsistencies or mismatches. 4. I can define component title, group, icon, initial field values and so on. 5. It might even allow developer to add a Readme.md file. The readme would contain the component’s documentation (like usage instructions) which can later be used by the editors and developers alike. 6. It might even be able to run the component in isolation, before even include it in project. Here there might be some potential constraints, considering component will run outside project context, so in the real project we might have slightly different results, but this a details left open to be clarified later on. 7. And it can also grow as a tool in the future, to add more component related features. - For example the OOTB Component tool allows you to see where is the component used. But it can do much more, like for example to have an one click away button to update all component instances with the new updated version. 8. It might even had a integration feature with project’s github, so that the component could be directly committed to basecode, once is verified and approved. Currently developers do this in two cumbersome-ish ways: - either create a package, download it, unpack it and put the stuff in the project codebase- or, when the component is already in project basecode, use aemsync to make manual changes on the component in their IDE and verify them in AEM afterwards 9. For now we can keep the HTL out of this tool, even if this could potentially be handled here as well. ------------------------------------------------------------------------------------------------------------------ The solution is not refined in depth, so there is a lot of room to change the idea. But the whole point is that we need a better, safer, easier and faster way to create AEM components. Environment Details (AEM version/service pack, any other specifics if applicable): All new AEM versions (AEM 6.5, AEMaaCS) Customer-name/Organization name: tethich.com 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 applicable): Above #1 - Content Fragment Model with multi-line field and rich text type selected Above #2 - The old classic console displays the option of "Source Edit" allowing us to write HTML Above #3 - The new console does not show the option of "Source Edit" Code package (if applicable): N.A @kautuk_sahni
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 present in the HTML, and custom data attributes can be retrieved by custom plugins. Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS, release 2024.10.18311.20241017T104455Z Customer-name/Organization name: Assa Abloy Screenshot (if applicable): Code package (if applicable): <confirmation-title jcr:primaryType="nt:unstructured" sling:resourceType="granite/ui/components/coral/foundation/form/textfield" fieldLabel="Confirmation title" granite:class="mycustomclass" metaType="text-single" name="confirmationTitle" valueType="string"> <granite:data jcr:primaryType="nt:unstructured" mycustomdata="123" /></confirmation-title>
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 we cannot do in the generic CF model. This would enable us to improve the editorial experience. Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS, version 2024.10.18311.20241017T104455Z Customer-name/Organization name: Assa Abloy Screenshot (if applicable): Code package (if applicable): <story-industries jcr:primaryType="nt:unstructured" sling:resourceType="dam/cfm/models/editor/components/fragmentreference/multifield" allowNew="{Boolean}false" fieldLabel="Industry" filter="hierarchy" fragmentmodelreference="/conf/global/settings/dam/cfm/models/cfm-tag" metaType="fragment-reference" name="storyIndustries" nameSuffix="contentReference" renderReadOnly="false" showEmptyInReadOnly="true" valueType="string/content-fragment[]"> <field jcr:primaryType="nt:unstructured" sling:resourceType="dam/cfm/models/editor/components/fragmentreference" fragmentmodelreference="/conf/global/settings/dam/cfm/models/cfm-tag" name="storyIndustries" renderReadOnly="false" rootPath="/content/dam"> <granite:data jcr:primaryType="nt:unstructured" customCFRootPathFolder="tags/industry" /> </field> </story-industries>
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 input fields that do get hidden, but leave a margin that creates unnecessary blank space (this happens because the style is not applied on the container DIV) Improved/Expected Behavior: Fix both bugs and enable plugin developers to properly apply style to toggle input fields Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS, version 2024.10.18311.20241017T104455Z Customer-name/Organization name: Assa Abloy Screenshot (if applicable): Code package (if applicable): api.setStyles(fieldName, {"display": "none"});
Zusammenfassung der Funktionsverbesserungsanfrage (RFE): When a component is moved from a container to another container in a livecopy the component appears again after sync. There should be a ghost component to prevent this. Anwendungsfall: If you move a component from one container to another in a livecopy, the component appears again in the original container after syncing with the blueprint.Steps to reproduce:- Create a new page with the template Content Page and open it- Add a Layout Container to the page- Add a component to the layout container (for instance a Text Component) and fill in some text.- Create a LiveCopy of the above page with Standard Rollout Config and open the LiveCopy- Add a second Layout Container to the LiveCopy- Drag (move) the component in the first container to the second- In the page settings synchronize with the blueprint- The component appears again in the first container There should be a ghost component in the first container when the component is moved, but none is created. Aktuelles/erlebtes Verhalten: The component appears again after sync Verbessertes/erwartetes Verhalten: A ghost component should be created in the original container to prevent the reappearing of the component Umgebungsdetails (AEM-Version/Service Pack, ggf. weitere Angaben): 6.5.22 Name des Kunden/der Organisation: Atruvia Screenshot (sofern zutreffend): Code-Paket (sofern zutreffend):
There are legacy queue topics that should no longer be used but deleting them results in a loss of historical data from already-submitted requests. The ability to deactivate queue topics will allow to toggle them off so that they no longer appear in the lists when submitting new requests to the same queue but will still preserve the queue topic data on the old requests.
We have several directors who all want to be able to track a project in their portfolio, even though it's managed by a different director's team. Only being able to put a project in one portfolio leads to projects being created multiple times so that each director can manage their team members work on the project and it just makes a mess!
The Activity ID is a unique identifier assigned to each activity in Adobe Target. It plays a crucial role in various processes, including tracking, reporting, and raising queries with Adobe Support.The addition of an "Activity ID" column in the Activities List would allow users to:1) View the Activity ID directly in the Activities List without opening each activity.2) Search for activities using the Activity ID in the search bar, improving efficiency.3) Quickly reference Activity IDs when raising support queries or managing multiple activities.Currently, users have to open each activity individually to retrieve its Activity ID.
Summary Description of Your IdeaI propose a feature in Workfront that allows administrators to lock deliverables, objects, or specific project components from further edits after a defined cutoff time. This functionality would help teams, especially those managing time-sensitive deliverables, maintain consistency and prevent unauthorized or last-minute changes that could disrupt workflows. The goal is to ensure that once a project reaches a designated phase, certain users (e.g., Dentsu/PMs/Planner/CMs) can no longer make changes, while maintaining flexibility for those who still need access.Why Is This Feature Important to You?Prevents disruptions: Last-minute edits from external teams can disrupt Creative Services' workflow, leading to inconsistencies in project deliverables.Ensures process integrity: Locking objects ensures that final versions remain untouched once a project moves to the next phase.Reduces manual oversight: Currently, permissions must be updated manually, requiring extra effort to monitor and enforce deadlines.Enhances collaboration: Allows teams to work freely within a defined timeframe but ensures stability after the cutoff dateHow Would You Like the Feature to Work?Configurable Locking Mechanism:Admins or project owners should have an option to set a lock date for specific deliverables, tasks, or documents.Past this date, the defined objects become read-only for designated users or teams.The ability to edit can still remain for admins or specific roles (e.g., Project Owners).User-Specific Access Controls:Ability to lock objects for specific groups (e.g., Dentsu) while maintaining edit rights for internal teams.A "Locked State" should be configurable within user access settings.Manual & Automated Locking:Admins can manually apply a lock at any time.Option to automate the lock based on project phases or due dates.Visual Indicator for Locked Items:Clearly mark locked items with an icon or banner to indicate restricted access.Provide an error message when restricted users attempt to edit locked objects.Audit Trail & Override Option:Maintain a log of when an item was locked and by whom.Allow authorized users (e.g., Creative Services leads) to override the lock in special cases.Current BehaviorThere is no direct way to lock deliverables, tasks, or objects from edits after a certain date. Teams must manually adjust permissions for users after deadlines, which is time-consuming and prone to human error.Users with past access can continue making changes unless an admin removes their permissions.There is no visual indication of an object being locked or restricted, leading to confusion.While projects can be marked as Complete, this status change locks access for all users, rather than just a select group.
The ability to change the owner of a Dynamic Board has been removed (only the admin can be the owner). In the most recent release Jan 2025 the change of ownership was given for basic, retrospective, and Kanban boards, but not dynamic boards. Our business cannot own the boards, as the admin was set up by an external provider. Functionality to change the owner of a dynamic board is highly desired.
Description -This is a feature we did have until recently. We had an external user landing page with a couple dashboards. One was a dashboard with that specific request type those users would need to make requests on. Why is this feature important to you -This is important to centralize things for our external users. Simplifies their experience and keep s them on one page. How would you like the feature to work -Until recently we could put the path to the request type in the "external page" field and the dashboard would show the request menu open to that request form/type. Current Behaviour -Recently doing things the way we had been now shows a dimmed unclickable request menu option. The current "fix" is to take the user to the regular request page.
Description - It would be wonderful to have a feature to force all/specific fields to lowercase in datasets (similar to CJA component settings) Why is this feature important to you - When adding lookup datasets to CJA, if there's variance in casing the metadata isn't returned, even if the dimension is displayed in all lowercase. How would you like the feature to work - Radio button to force all fields to lowercase. Checkboxes to allow only specific fields to be forced to lowercase. Current Behaviour - Can use data prep to lower case specific fields. But that's not retroactive and only applies to one field at a time.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK