Skip to main content

Ideas

Filter by idea status

10000+ Ideas

user01245Level 3

Ability to add custom design/styling to custom forms and request queues (i.e. font size, font weight, color, etc), also support WCAG 2.1 AA complianceNew

Description:I'd like the ability to have a little bit of control over the look and feel of custom forms, particularly how they are displayed when used as a request queue. Ideally we'd be able to adjust font size, font weight, color, bolding, etc.  Even if we could apply a default font-size for the form, and selectively bold some text, that would be a huge improvement. Additionally, a complaint I've received multiple times is that the font size for a question is smaller than the font size for an option within that question.  If we could change the font size we could fix this ourselves. Or, if it's easier, make the question font-size match that of the options below it.  Example: Why is this feature important to you -There are new rules that go into effect in April 2026 around accessibility of internal and external documents for Government agencies. All documents must be WCAG 2.1 AA complaint. Depending on your reading of the guidelines the current request queue forms may not be in compliance.  More information here:  https://www.ada.gov/resources/2024-03-08-web-rule/How would you like the feature to work -I can think of a few different ways to address this:1.) Allow admins to set a default font size for request queue forms and be able to selectively bold descriptive text in forms.2.) Give us complete control over the font size, color, etc, on a per-question basis.3.) As a stopgap, increase the font-size of the question label to match that of the options below it, and ensure request queue forms meet all other WCAG 2.1 AA guidelines.  Current Behaviour:We have no control over the design of custom form/request queue design, and current request queue forms may not be WCAG 2.1 AA compliant.

Action to move Workfront Documents into an AEM Linked Folder via WF Connector (or even HTTP request)New

Description - Please enable a way to us to automate the moving of regular Workfront documents (i.e. local in the Project) into an AEM Linked Folder via the API (preferably a Fusion action module).Why is this feature important to you - It's laborious and prone-to-error for users to manually drag and drop Workfront Documents into an AEM Linked Folder. We have many clients where this could be a big time-saver both in terms of reducing the effort to move files and also improving the accuracy of where they place them as we could automate that based on Document metadata.How would you like the feature to work -  Have a Workfront module in Fusion where we can map in the Document ID and also the ID of the (Linked) Folder or its associated Linked Folder ID it is to be moved into. Even if we have to use a Workfront Custom API call or plain old HTTP Request that would be fine as long as it is via a Production API.Current Behaviour - There are various internal API calls we have tried to emulate via Fusion and there is an experience league article from last year with a accepted answer post from @victorto2 (please note that the original question is not relevant...only the answer) which indicates it was possible at that time but I've been unable to get that to work yet. And, even if I did, it is an unsupported internal API call which is not ideal for production use by customers. So, basically there is no current workaround.

webera
Adobe Champion
weberaAdobe Champion

Provide OOTB Renditions to Asset Compute microservice extensibilityInvestigating

  Request for Feature Enhancement (RFE) Summary: Provide a way for the "Asset Compute microservice extensibility"/Asset Compute workers to access the default renditions for an Asset so the custom worker can use those as a baseline for further conversions. Either: Pass a default rendition to the worker (instead of, or in addition to, the original). Or: Defer worker invocation until default renditions are generated (opt-in), so the worker can fetch them reliably. Or: Allow non ARM64 containers and installation of custom binaries like imagemagick for the Asset Compute microservice Use-case: We need to generate custom renditions (e.g., square JPEGs with white borders) from assets like .ai (Adobe Illustrator), .psd (Adobe Photoshop), .svg, .eps, etc. These file types are already supported by AEM’s default rendition generation, but not by Asset Compute workers directly (see below for reasons). If workers could use AEM’s default renditions as inputs, they could reliably transform these assets without needing external tools. Current/Experienced Behavior: AEM Assets and the generation of (default) renditions already supports a wide range of file types. However, the "Asset Compute microservice extensibility" is fairly limited in the filetypes it can process. There currently is no way we and Adobe Support found to support mentioned filetypes (ai, psd, ...).There is no way of reliably accessing the generated (default) renditions which then could be used as a baseline for the actual conversion from within the microservice, as they are not generated at the time of invocation microservice Technical details/background: The "recommended" library "JIMP" which is referenced in the demo project is super limited in the filetypes it can support (currently only jpeg, png, bmp, tiff, gif) Using other image conversion libraries wasn't successful either, as they always rely on binaries (like imagemagick) which don't work on the ARM64 containers the microservice runs on As mentioned previously, trying to access the default renditions and using them as a baseline for the conversion doesn't work either, as they are not generated/available at the time of the invocation of the microservice In summary: Asset Compute microservice currently only works for a very limited set of filetypes. Improved/Expected Behavior: Three possible solutions (either would solve the problem): Allow default renditions or custom defined renditions to be passed into workers instead of only the original Asset binary Invoke custom workers only after default renditions exist (opt-in, via processing profile checkbox), so the worker can fetch and transform them. Allow non ARM64 containers and installation of custom binaries like imagemagick for the Asset Compute microservice Environment Details (AEM version/service pack, any other specifics if applicable): AEM as a Cloud Service (2025.8) with Asset Compute microservice running on Adobe AppBuilder/Runtime) Customer-name/Organization name: (private), see support case E-001769596 for customer specific details Screenshot (if applicable): N/A Code package (if applicable): N/A