Product ideas | Community
Skip to main content

10000 Ideas

Seung-ju
Seung-juNew Participant

Cloud Manager : Add emergency production deployment pipelineInvestigating

Request for Feature Enhancement (RFE) Summary: Cloud Manager Deployment: Add emergency production deployment pipeline Use-case: LGE.com is trying to roll back the deployment after a successful production deployment. Currently, the only way to roll back is to re-deploy the code in Cloud Manager, which takes 2 to 3 hours. Given that they are supporting 24 websites (with more to come in the future), they need to reduce the build time for any rollback operations. The best way to achieve this is to enable re-deployment using an earlier stable built image. Current/Experienced Behavior: The production deployment is completed. After the deployment, the customer discovered blocker issues on one of the 24 websites. They decided to roll back the deployment. They reverted the change that caused the issue and pushed the revised changes to Cloud Manager. They restarted the Stage/Prod build, which took 2 to 3 hours. The customer is trying to minimize this 2 to 3-hour downtime as much as possible. The current production deployment pipeline is as follows: 1.Stage Deployment(77m) validation → build & unit testing(38m) → code scanning(14m) → build images(10m) → deploy to stage(15m) code scanning(14m) : code coverage(42%) 2.Stage Testing(5m) product functional testing(3m) → custom functional testing(2m) → custom ui testing → experience audit custom functional testing : Only library downloads required for testing, no actual testing 3.Production Deployment schedule production deployment → deploy to production Improved/Expected Behavior: The basic idea is an expedited deployment pipeline is a staged deployment after production deployment. Deployment using the emergency production deployment pipeline begins. first task :  Production Deployment Only build (Excluding unit tests)→ build images → deploy to production second task : Stage Sync deploy to stage   Since testing and code verification pipelines exist in QA or DEV pipelines and are verified by our deployment team, we believe that this task is unnecessary in production pipelines. Environment Details (AEM version/service pack, any other specifics if applicable): AEM as a Cloud (2024.4.16145.20240430T082417Z) Customer-name/Organization name: LG Electronics, Global HQ Korea 24 subsidiaries (UK,DE,PE,TR,JP,FR,SG,CO,SA,SA_EN,CA_FR,CA_EN,KZ,ID,IT,CL,TH,PT,IN,HK,HK_EN,BR ,MX ,PA) Screenshot (if applicable):   Code package (if applicable):  

martinkastler
martinkastlerNew Participant

Pickers should remember their last location and start from thereInvestigating

Request for Feature Enhancement (RFE) Summary: Pickers must remember their last location and start from there  Use-case: Our editors create pages on specific topics and upload assets related to that topic. They very often upload the assets into the same folder to have everything in one place. Then they start to build a page and add the assets to the page.  Current/Experienced Behavior: For the first image asset:  1. Drags in Image Component 2. Opens asset picker 3. Navigates all the way to the sub-sub-sub-sub folder 4. Selects asset 5. Confirm 6. Confirm   For the second image asset: 1. Drags in Image Component 2. Opens asset picker 3. Navigates all the way to the sub-sub-sub-sub folder 4. Selects asset 5. Confirm 6. Confirm   ... repeat for each asset Improved/Expected Behavior: For the first image asset:   1. Drags in Image Component 2. Opens asset picker 3. Navigates all the way to the sub-sub-sub-sub folder 4. Selects asset 5. Confirm 6. Confirm   For the second image asset: 1. Drags in Image Component 2. Opens asset picker 4. Selects asset 5. Confirm 6. Confirm   ... repeat for each asset   So, pickers should remember their last location and start from there, at least for the current session. Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS Customer-name/Organization name: VERLAG DES ÖGB GMBH Screenshot (if applicable):   Code package (if applicable):  

martinkastler
martinkastlerNew Participant

Add Save as Version to Page Information menuInvestigating

Request for Feature Enhancement (RFE) Summary: Add Save as Version to Page Information menu Use-case: Many of our users miss a saving button. We don't promote that. Their need is to: Create page Modify it to their liking Save the page once they reached a "milestone" Colleagues then publish the "milestone" version or use it for approval The main editor continues working on the page Currently, the main editor must leave the page editor, go the Content Tree and create a version from there. They wish to create a version from within the page editor. Current/Experienced Behavior: The menu is not existant yet.   Currently: User must close the page editor User goes to location of page User selects page User switches to the Timeline sidebar User clicks the three dots at the bottom (see screenshot) User clicks Save as Version User fills in Label User fills in Comment User clicks Create System saves Version Improved/Expected Behavior: User clicks Page Information menu (see screenshot) User clicks Save as Version User fills in Label User fills in Comment User clicks Create System saves Version Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS Customer-name/Organization name: VERLAG DES ÖGB GMBH Screenshot (if applicable): see attachments Code package (if applicable):     Somewhat related: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/enable-page-versioning-on-save/m-p/420886

JessicaKl2New Participant

Update Timewarp to Support Nested LaunchesInvestigating

Request for Feature Enhancement (RFE) Summary: Update Timewarp functionality to work with nested launches and with launches utilizing experience fragments.  Use-case: Successfully utilize Timewarp functionality within all AEM  launches, to avoid capturing manual screenshots of all scheduled updates to have on record. This will allow us to compare our home page to older versions of itself in order to compare metrics, trends, and any other data needed to help us improve our business.  Current/Experienced Behavior: Timewarp does not work as desired for Nested Launches or when experience fragments are used. The experience fragment is not loading when the page is viewed in Timewrap or the Version UI for Preview or Compare versions. The experience fragment does load appropriately if it was part of the initial template.    Our process for home page launches today involves creating nested launches off each Sunday's home page. The breaking the inheritance on components that will change for the next launch. Then we reauthor those components changing and set up for a future launch date.  Improved/Expected Behavior: When utilizing timewarp we expect to be able to review previous version of any page regardless of how it was launched or what components were used on the page.      Environment Details (AEM version/service pack, any other specifics if applicable): Production  Customer-name/Organization name: DSG (DICKS Sporting Goods) Screenshot (if applicable):   Code package (if applicable):