Product ideas | Community
Skip to main content

Ideas

Filter by idea status

10000+ Ideas

Baseline RDE code after resetInvestigating

Request for Feature Enhancement (RFE) Summary: Ability to re-baseline RDE environment after reset / Backfill code image from Prod to other environments Use-case: After a production release we backfill our environments. This is done by executing pipelines for the various Dev environments however this could be different to whats deployed to production depending on when the master branch was deployed.For our RDE environments however, this is manual and when we have multiple RDE's for our developers its a time consuming task to reset each environment. It would be great if we could simply select an image that has previously been deployed to an environment such as Production and be able to deploy that to any dev/rde environment without having to run a build pipeline.This would minimise effort from executing multiple pipelines and manual effort and would also minimise processing by Adobe as the image would already be built and validated. Current/Experienced Behavior: Manual for developers to deploy code after resetting it Improved/Expected Behavior: Create the ability for an environment to be backfilled based on an image that has already been deployed Eg: Production code image can be deployed to Dev & RDE Environment Details (AEM version/service pack, any other specifics if applicable): AEM cloud manager Customer-name/Organization name: Spark NZ Screenshot (if applicable):   Code package (if applicable):  

rwunsch-adobeAdobe Employee

Provide a means of permission and user-management for AppBuilder Applications (through Adobe IMS, AdminConsole)Investigating

Request for Feature Enhancement (RFE) Summary: Provide a means of permission and user-management for AppBuilder Applications (through Adobe IMS, AdminConsole) Use-case: When developing App Builder Apps, the question occurs how to give different users different permissions within the App (or access to the app at all).How can access to an App be granted or denied - and what about granual permissions within the app?How is permission-management / user-management within Appbuilder Apps handeled?IF we do not yet support something like that ..I think each app should have the ability for product profiles in the admin-console, which could then be customized to have as many different permission levels as required by creating additional profiles.(Naturally these should be easily available on runtime "OOTB" for developers to use. And not though something like the UMAPI - which is very cumbersome ... ) Current/Experienced Behavior: Unfortunately ORG level is the only granularity in terms of access to an app which is way too broad. Everything else currently needs to be handled within your app.IDPs like Auth0, cognito, supabase, must  be integrated directly into the app (so only "non-Adobe IPDs can be used). This is not simple when you inevitably get into MFA, SSO, password rules enforcement, fraud detection, etc Improved/Expected Behavior: I'd also like to see more fine grained control built in on our side, e.g. via profiles added to an IO project, which would change the required scopes to invoke the action, so only users with that profile/group would be able to access it with their token Environment Details (AEM version/service pack, any other specifics if applicable):   Customer-name/Organization name: Adobe & serveral customers using App Builder extensively Screenshot (if applicable):   Code package (if applicable):  

Rohan_Garg
Community Advisor
Rohan_GargCommunity Advisor

Developer Console AEMaaCS - OSGi Configuration - Runtime Environment Variables DisplayInvestigating

Request for Feature Enhancement (RFE) Summary: Developer Console in AEMaaCS should display runtime environment variables values too - This helps to know which is the current value being picked (default or custom) Use-case: Currently the config.json displayed in the pod at cloud manager for an instance displays configuration for environment variable as is in the codebase -  "configKey": "/configValue/$[env:CUSTOM_KEY;default=9876543210]/rohan",   If the CUSTOM_KEY is configured in environment variable then the value that should be displayed is the actual one and not the above one. If it's not configured then the default value should be displayed to give a better idea of whether an environment value is configured for an instance or not. Current/Experienced Behavior: User has to navigate to the Environment Variable console to manually verify whether CUSTOM_KEY is configured or not. In a project with 150+ env variables this becomes an unnecessary lookup. Improved/Expected Behavior: The config should display the proper correct value. If no environment value is configured then display the default one else display the custom one. Environment Details (AEM version/service pack, any other specifics if applicable):   2024.10.18311.20241017T104455Z   Customer-name/Organization name: EPAM Systems Screenshot (if applicable):   Code package (if applicable):  

sureshkumarvNew Member

Update BPO report on CDN Cache metricsInvestigating

Request for Feature Enhancement (RFE) Summary: The Cache metrics report generated by Adobe SME named "AEM CS BPO Tech Staff Report.pdf" monthly basis recommends improving the CDN Cache ratio but the way its generated needs to be revisited as the internal call, or URL forwarding requests, internal redirects are all being tracked differently causing the cache hit and coverage ratio scores reported low. Use-case: Ex: when the request is made for our website like fiserv.com gets (302) redirect to  https://fiserv.com and to https://www.fiserv.com/ in this case considered as different requests and reports miss or pass. As this is the homepage and the number of page visits to the homepages are high the score gets impacted significantly.   other examples like A) there are calls like /autodiscover.xml and other that gets originated from network or bots or health checks and not from core AEM application which also gets reported as MISS/PASS and impacts the score. B) json responses with url params cannot be cached due to impl nature and requirements but this also gets reported as MISS   After detailed manual analysis and cache coverage details the Adobe SME confirms we are on excellent coverage beyond the minimum standards and no issues but as per BPO report and score from Cloud manager dashboard we are not. Hence request for revisiting of reporting to reflect actuals appropriately. Current/Experienced Behavior: The Cache score is low Improved/Expected Behavior: The Cache Ratio should reflect the relevant and appropriate scores Environment Details (AEM version/service pack, any other specifics if applicable): AEM CS Customer-name/Organization name: Fiserv Screenshot (if applicable):   Code package (if applicable):