Skip to main content

Filter by idea status

10000+ Ideas

lutzULevel 3

MSM: Improve Page Move Rollout config functionality - manage re-publication after rolloutInvestigating

Request for Feature Enhancement (RFE) Summary: Page Move rollout config should not only adjust links in referencing pages but also should re-publish them if editor does not decides against Use-case: For managing multinational and multilanguage websites with AEM, we use MSM with blueprint/livecopy to maintain it in a efficient way. Also, as we want to have also structure every time in sync, we are using Page Move Rollout configuration to ensure that also page moves are applied in the livecopies through the rollout. See chapter "To fully realize a page move ..." here: https://experienceleague.adobe.com/docs/experience-manager-65/content/sites/administering/introduction/msm-best-practices.html?lang=en#structure-changes-and-rollouts Current/Experienced Behavior: Let me give you a most simple example: Imagine you have two pages, page A and page B. Page B has a link to page A. Both pages are rollout out to a livecopy and are published. Livecopy has page move and standard rollout config. Now, you move page A to some other structure in the blueprint (e.g. below page C). Doing that, the page move dialog provides option for adjustment and republishing of the referencing page - this is fine and works. To bring this changes to the connected livecopy, you roll out page A. With that, page A getss moved in the livecopy as well and the referencing page B is modified. But because page B was published before, you as an editor now have to manually re-publish this page!Imagine you have 10 livecopies or more connected and not just one page which links to the moved one (but maybe 100) => this is an ENORMOUS effort to do the manual re-publishing since you first have to gather all the referencing pages! To sum up: this is not Enterprise CMS like and does not match our expectations how a CMS should support editors work. Improved/Expected Behavior: If you have Page Move rollout config in place, the system should check if the page you roll out has a cq:LiveSyncConfig node with the property cq:moveTarget in the livecopy page (which indicates that blueprint page has been moved). If yes, system should bring up a dialog showing the referencing pages in the livecopy were user can decide if adjustment or re-publishing should occur similar to standard move dialog. With that the manual work not apply!And, I mean the system is currently adjusting the links - it knows that pages and touches them but it is NOT performing the other step about re-publishing. This is really disappointing! Environment Details (AEM version/service pack, any other specifics if applicable):   Customer-name/Organization name: Carl Zeiss AG Screenshot (if applicable):   Code package (if applicable):  

sandramr
sandramrLevel 2

Prevent Users from Moving Tasks with Logged Hours Across ProjectsNew

Description - Add Admin setting to prevent users from moving Tasks that have logged Hours tied to it. There already exist settings to prevent users to delete hours with logged hours here and here. We need to be able to configure a similar setting but with respect to the ability to move a task from one project to another with logged hours.  Why is this feature important to you - Without this feature, users are able to move a Task with logged Hours from one Project to another and the Hours get stuck in a state where they stay with the original Project but are no longer tied to a Task. We leverage meta-data on Tasks when reporting on Hours so it's critical that all Hours are tied to a Task.  How would you like the feature to work - Ideally this works similar to the settings that manages whether users can delete Tasks with logged Hours, except we want to prevent them from being able to move tasks with logged Hours. Current Behaviour - When a user attempts to move a Task that has Hours tied to it, they get a pop up that states that the Hours will stay with the Project but most users don't understand what that actually means or the downstream impact of that decision. In most cases, users are actually trying to just copy a Task and accidentally select the Move option instead, not realizing it until it is too late. This results in Hours that are no longer tied to any Task and are unable to be tied back to a Task without needed Adobe Workfront Engineering Support.