Product ideas | Community
Skip to main content

10000 Ideas

NickSkidmoreNew Participant

Fix Inconsistencies with Parent Task Constraints in TemplatesNew

Description:Parent task constraints in a template should yield the same results when applied to a project. Currently, this is not the case.Why is this feature important?If you need a specific phase of a project (with many child tasks) to start on a particular date, it makes sense to have the ability to set a start date for the entire group of tasks. Task constraints work as expected on parent tasks in projects, so it’s essential that a project template behaves the same way when creating a new project. Consistency between templates and projects is crucial for accurate task planning and scheduling. How would you like the feature to work?Parent task constraints in a template should function the same way they do in a project, ensuring that the template creates the project with consistent, expected results.Current Behavior:Some task constraints on parent tasks in templates are not respected when the template is used to create a project. For example, in a template, I have set a constraint on a parent task to start on day 5 (working days). However, when I create a project from the template, the task is pushed to day 10. With the project start date set to 2/4, a constraint for day 5 (working days) should set the task to 2/11, but it is instead set to 2/18. This discrepancy suggests a calculation error.Adobe’s response was that task constraints should not be applied to parent tasks. My counterpoint was: if that’s the case, then why is the option to apply constraints available in the first place? And, why does it work as expected when I apply it in a project? It also works on simple templates but seems to get confused on more complex templates. Adobe could not provide an explanation and reverted back to it's first response of not putting a task constraint on a parent task and to put in this idea. Anyone else having this issue?

UnjiBaEmployee

Increase Folder Depth Limitation for Export Metadata in AEM AssetsInvestigating

Request for Feature Enhancement (RFE) Summary: Increase the folder depth limitation for the Export Metadata feature in AEM Assets to support folders exceeding 10 levels. Use-case:  Some customers rely on deep folder hierarchies to manage large-scale asset libraries effectively. Their current folder classification system often exceeds 10 levels in depth. The existing limitation prevents the Export Metadata feature from functioning properly for assets stored in these deeper folders, leading to inefficiencies and an inability to extract necessary metadata. Current/Experienced Behavior: When using the Export Metadata feature, it fails to export metadata for assets located in folders deeper than 10 levels. This limitation disrupts workflows for customers with complex folder structures. (Case #E-001458355:  Support Response: I checked the code for AssetMetadataExporterProcess and found that the FULL_TRAVERSAL_DEPTH = 10, which means it only allow 10 levels of depth. This limit restriction can’t be increased.) Improved/Expected Behavior: The Export Metadata feature should support folder depths exceeding 10 levels, allowing users to export metadata seamlessly regardless of folder hierarchy depth. This enhancement would enable greater flexibility and efficiency for customers with advanced folder structures. Environment Details (AEM version/service pack, any other specifics if applicable): AEM as a Cloud (2024.8.17569.20240822T203847Z) Customer-name/Organization name: LG Electronics, Global HQ Korea Screenshot (if applicable):   Code package (if applicable):  

SuryaLakhani
SuryaLakhaniNew Participant

Highlight Description field changes (what was added/what was removed)New

Description - Highlight Description field changes (what was added/what was removed) in updates. Why is this feature important to you - This will save users a lot of time when trying to review changes to the Description field How would you like the feature to work - When the text in the Description field is updated, the System Updates section can:Option 1: Record the new text with the old text (combined as one), striking out anything that was removed highlighting it in red, and highlighting anything that was added in green. If colored highlights are not feasible, simply strike out removed text and use bold for added text.  Option 2: Record the system update in two columns, the left being the original text and the right being the new text. In the New Text Column, it would also be great to strike out anything that was removed highlighting it in red and highlighting anything that was added in green. If colored highlights are not feasible, simply strike out removed text and use bold for added text. A basic version of Option 2 is available in Jira. Current Behaviour—When the Description is changed, the system records the updated text as-is in the System Updates section. For a user to figure out what was changed, they have to read the entire description (sometimes this can be very long), and even then, it is hard to find what was exactly updated. Users are forced to use a third-party text comparison tool to determine what was changed. 

Mylah_DNew Participant

Support more than one (or a separate Workfront) Admin Console per company domainNew

Description: An organization with a single domain should be enabled to separate their products across multiple Administrator Consoles. (Of lower priority, a separate idea is that - once an organization is forced to share products on a single console - there should be a single point of contact at Adobe to help manage shared issues caused by console sharing.) Why is this feature important to you: We are a multinational company with a very distributed organizational structure. The R&D department has little business reason to interact with our Marketing department, for example. The introduction of the console has created a lot of work, the unnecessary need for added coordination, and layers of authorization/access because of the current Console constraint that a domain can only be controlled by one set of primary owners - and those owners are arbitrarily the first group of administrators to have migrated over to the console.  Until the admin console, it was very possible for separate business units to set up SSO for their own products and manage their Adobe products without the need to coordinate. This efficiency goes away once all units migrate to the console. If one group migrates to the console first, they essentially own the admin console. They gain decision-making authority for who can use the company's "claimed" domain. These admins are understandably reluctant to share their highest privilege in the console if it means granting access to sensitive or confidential information in their own applications. Furthermore,  at least make all decisions at the highest level going forward as to who else can be added to the console at the highest-provisioned level. Applications owners whose users later migrate to the console are now required to get authorization from primary owners to either share ownership (e.g. Application A's primary admins must decide whether or not to let Application B admins become global admins within the console) at this primary level, or grant permission for the new application to use the claimed domain to set up SSO for the Adobe product being migrated. In addition to the efficiency loss, Admins of one product lose the ability to completely secure their sensitive information from the admins of other products if those Admins "own" the primary console. Using the same example above, R&D information can be highly secretive. Another group should not have the ability to give themselves access to your R&D information simply because of the current architecture of the Admin Console. Furthermore, to set up or migrate accounts for users, the owners of the Primary console must have the SSO-enabled users first created on the primary console in order for the users to be set up on the secondary console. This creates a lot of work for the primary console owners, as well as duplicative work for the downstream application that wants to set up users with SSO. Because 2 or more business units in a company have different products, the units deal with different Adobe representatives who do not connect nor mutually solve a company's overall issues with the console migration. This causes delays, ambiguity as to the root cause of a problem, misinformation, ambiguity with whose responsibility it is to solve the issue, and the need to communicate repetitively. How would you like the feature to work: Let each business unit have a separate console regardless of whether or not they need to set up SSO for the same domain. Do not force groups with separate contractual relationships with Adobe to have to coordinate and set up a governance model simply because of this technical limitation that dictates 1 Domain/1 Console.  Current Behaviour:  The admins of the first application to migrate over effectively (and arbitrarily) gain global management rights to all applications later on-boarded onto the Admin Console.  Later application owners to on-board must request permission to either become global admins themselves or to use the already-claimed domain for their own SSO implementations.  Any user who is to be set up with SSO in that domain must first be set up at the global level (by the Adobe "global admins") at the company before being added as users to any application where SSO is enabled and this increases the administrative and coordination burden. 

William--
William--New Participant

Provide additional fields on Category and Parameter objectsNew

DescriptionWe have hundreds of Custom Forms and thousands of Parameters, many of which are referenced in dozens of automations across multiple platforms, both in and not in Fusion. The only tool that is built into Workfront to help us document and govern these objects is the Description field (forms) or the Instructions field (parameters). The absence of a full-featured data dictionary within the platform is very limiting in what and how we are able to document.We would like additional fields on these object types so we can spend less time tracking down all the areas throughout our stack that are impacted by things like changing a parameter name, or deleting a custom form, etc.While we do want the ability to attach custom forms to a wider array of object types (especially including Teams, Roles, Reports and Dashboards), I believe this need is better served by the addition of a few extra system fields on these objects. Doing so will allow us to build our data dictionaries directly in Workfront. Why is this feature important to youThe frequency in which we or teams we work with encounter errors due to benign changes on Categories and Parameters is having a strong negative impact on our efficiency, productivity, and the perception of Workfront's quality by our users because "it's always breaking." While a data dictionary can be maintained externally, there's no way to encourage or enforce admins/group admins to use or update it as they interact with these object types, as it's not built in to the form editor. How would you like the feature to workOn both Categories and Parameters (maybe even Parameter Options!), we would like multiple additional system fields made available in the form editor so we can add and reference additional details relevant to each object. Open to suggestions on what these fields should be or how they behave, but anything that allows us to input and edit the various entity relationships of a field or form will be helpful. Current BehaviourWe do our best to document dependencies in the one field we're allowed to do so, but it is limiting to us and also confusing to users. (E.g. when using a custom field's Instructions field to document entity relationships of the parameter, that is shown to users interacting with forms and they have no idea what it means.) We have explored using Fusion to seed a collection of Projects and Tasks as a pseudo data dictionary, which allows us to add a lot of detail and metadata about these objects, but its tedious to maintain and isn't easily seen when someone is making updates to one of these objects.