Product ideas | Community
Skip to main content

10000 Ideas

Brad_morrisNew Participant

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

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
Rohan_GargNew Participant

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 Participant

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

Integrate Accessibility Testing into AEM Cloud Manager PipelineInvestigating

Request for Feature Enhancement (RFE) Summary: We propose adding accessibility testing to the AEM Cloud Service Cloud Manager pipeline, providing a baseline assurance for compliance with the European Accessibility Act (EAA) and the Web Content Accessibility Guidelines (WCAG) 2.x.   By embedding accessibility checks directly into the CI/CD process, this feature would enable proactive identification and resolution of accessibility issues, fostering a more inclusive user experience and aligning with industry standards. Use-case: Compliance with Accessibility Standards (EAA, WCAG 2.x):Ensuring compliance with the European Accessibility Act (EAA) and WCAG 2.x is critical for organizations operating in Europe or serving global audiences. Automated testing within the Cloud Manager pipeline would provide a baseline for meeting these legal standards, reducing the risk of non-compliance and associated penalties. Early Detection of Accessibility Issues:By running accessibility checks at each deployment, teams can catch issues as they arise in the development lifecycle rather than after the website has gone live. This proactive approach enables timely fixes, reducing the effort and cost of retrofitting accessibility after deployment. Consistent Accessibility Checks Across Updates:Websites evolve over time with new content, features, and design updates. Automated testing ensures that accessibility remains a consistent focus, regardless of these changes. Testing at each deployment helps maintain high accessibility standards without relying solely on manual checks. Enhanced User Experience for All Audiences:Regular accessibility checks improve the overall user experience, particularly for users with disabilities. By identifying and resolving barriers to access, organizations can create a more inclusive experience that caters to all users, increasing engagement and satisfaction. Real-Time Visibility into Accessibility Status:Integrating accessibility testing into Cloud Manager provides real-time feedback for each deployment, helping teams monitor the site's accessibility status over time. This visibility allows for better tracking of improvements, trends, and issues, fostering a culture of accessibility awareness. Reduced Dependence on External Tools and Manual Processes:Teams often use separate tools or manual processes for accessibility testing, which can lead to inconsistencies and require additional setup. Having accessibility testing directly within AEM Cloud Manager centralizes this process, reducing dependency on external resources and making it easier to manage compliance in a unified way. Quick, Actionable Reporting for Developers:Axe DevTools CLI provides actionable insights into specific accessibility issues, helping developers understand and fix problems more efficiently. Integrating this into Cloud Manager would give development teams immediate feedback on violations, with clear paths to resolution, accelerating the remediation process. Simplified Audits and Documentation:Regular automated testing creates a log of accessibility compliance that can be used for audits, internal reviews, or reporting to regulatory bodies. With consistent testing and reporting, organizations can better document their commitment to accessibility and provide proof of compliance if needed. Improved Cross-Functional Collaboration:Accessibility compliance often involves collaboration across teams, including developers, designers, and content authors. With a centralized testing system in Cloud Manager, different stakeholders have easy access to results and can work together to address issues, fostering a more collaborative and inclusive approach to accessibility. Optimized Resource Allocation for Accessibility Work:Automated testing helps teams identify which pages and components are non-compliant, allowing them to allocate resources more effectively. For example, developers can prioritize fixes on the highest-traffic pages, ensuring that accessibility efforts are strategically focused on areas with the most impact. Simplified Enablement of Accessible Design Practices:Regularly surfacing accessibility issues through automated testing encourages teams to design and develop with accessibility in mind from the start. Over time, this helps build a team culture that prioritizes accessibility, reducing the frequency of issues in future releases. Risk Mitigation in High-Visibility or High-Risk Deployments:For major releases or updates to high-traffic pages, automated accessibility testing provides an extra layer of assurance that all users will have a positive experience. This is especially important for key marketing pages or campaign launches, where accessibility oversights could negatively impact a large audience. Simplified Accessibility Compliance for Multiple Geographies:Many organizations operate in multiple regions, each with different accessibility standards. Automated testing within Cloud Manager can help ensure compliance across various legal frameworks by testing for standards like WCAG 2.x, reducing the risk of non-compliance regardless of location. Current/Experienced Behavior: Adobe Experience Manager (AEM) Cloud Service currently does not include built-in accessibility testing as part of its Cloud Manager pipeline. Accessibility compliance checks are often handled through external tools or manual processes, resulting in potential inconsistencies and increased risk of non-compliance with standards like WCAG 2.x and EAA requirements. This can make it challenging to maintain consistent accessibility standards across updates. Improved/Expected Behavior: We recommend integrating automated accessibility testing within the AEM Cloud Manager pipeline. This enhancement could use a solution like Axe DevTools CLI to conduct accessibility tests on either a set of pre-configured pages or the customer’s 20 most-visited HTML pages, provided the site is not headless. This would give developers a reliable way to identify accessibility issues within the CI/CD process, ensuring regular compliance checks and addressing issues early in the development lifecycle.   Key benefits would include: Consistent accessibility testing aligned with WCAG 2.x and EAA standards. Proactive issue identification within the CI/CD pipeline. Enhanced usability for all users through improved accessibility compliance. Environment Details (AEM version/service pack, any other specifics if applicable):   Customer-name/Organization name: e.g. VodafoneZiggo Screenshot (if applicable):   Code package (if applicable):