Skip to main content

Filter by idea status

10000+ Ideas

RichardPe3New Participant

Cannot mark project complete explanationNew

Description - When attempting to mark a Project Complete and there is an open issue or task, popup should at minimum list the task/issue stopping the project from being marked complete. Step better would be why the task/issue is not complete if due to missing approvals, bad dates, or anything else definable. Why is this feature important to you - Just wasted time trying to get close a project. First, all tasks were marked 100% and standard view does not include status so wasted time looking for a task not complete but 100%. Second, once the task was found I could not update the status because it was "Calculated by System", but all subtasks were complete and 100%. Waste more time looking through experience league for what could be stopping, try a number of suggestions with no results. Come to find out Planned start and end dates cannot be the same. Update dates to fixed because ASAP is not changing them. Still the parent task remains open. Thinking I have not found what is stopping the status update continue to waste time looking for more suggestions. Circle back to the dates and force time recalculation, things start working. Could have saved time if the popup notification just stated X task is not complete - Dates/Timeline error or message that is stopping the system. How would you like the feature to work - Keep the current popup when attempting to complete a project, but add details Current Behavior - Popup only states project cannot be marked complete with open tasks or issues.

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):  

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.