Product ideas | Community
Skip to main content

Filter by idea status

10000 Ideas

lutzUNew Participant

Bring changed page order to publisher by only publishing the changed item itself, not whole websiteInvestigating

Request for Feature Enhancement (RFE) Summary: Changed Page Order - Fix Publishing Process Use-case: The main navigation of your website is build by the order of the first level pages. Now, you want to change the order. To achieve that you change the order of the item in the Sites Console and publish the reordered item. Let's take the WKND example. Here the initial main navigation is: MAGAZINE | ADVENTURES | FAQs | ABOUT US. Now, we want to have ABOUT US entry at very first item, so we move position of the corresponding about-us document before magazine document and publish the about-us document.Pls see screenshots. Current/Experienced Behavior: The changed order is not present on the publisher, instead you still get the old order in the main navigation.To get this working you need to publish whole website content which is basically not possible in daily work as you have always some prepared pages (status = modified) which should not go online yet and of course you don't want to overwrite the publication timestamp of all your pages just because you have change the order of ONE item! That's just not applicable. Improved/Expected Behavior: The behavior is different in On-Prem with AEM 6.5.16.0. Here it works like expected: to bring the changed order to publisher, you just need to publish the reordered page itself, nothing more! Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS Customer-name/Organization name: Carl Zeiss AG Screenshot (if applicable):   Code package (if applicable):  

FrederikWerner
FrederikWernerNew Participant

Introduce JSON view of Analysis Workspace and componentsNew

Description - Building content in Analysis Workspace can be challenging. We've all been in situations where someone asks for support (within our company, the Experience League, or other platforms like Measure Slack) when trying to build a Segment, Calculated Metric, or Analysis Workspace Project. Oftentimes, this then leads to length discussions of "drop this one slot below! No, not at the very bottom, above that! No, that's where you started! Let me give you a screenshot! No, don't drag it onto the screenshot! Argh!" and lots more screenshots, messages, and "can't we just hop on a quick call?" of 2 hours length. As a second scenario, agencies and consultants often want to easily bring content from one IMS Org to another one. Even admins within a company wish they could just quickly make changes like replacing all instances of a wrong Segment with the correct one in a Workspace Project. However, there is no quick way to do this today. Thirdly, enthusiasts like me tried building communities around sharing components, like I did on Github. Without easy access to a technical definition, nobody wants to go through the hassle of providing any content. For active community members like me, there is little point in trying to document our work in blog posts with screenshots like this:     To help with all cases, I want to propose a view similar to the existing debugger for API requests in Workspace. For components like Segments, Calculated Metrics, entire Projects, or even Panels and Freeform tables within Workspace, I want to have a "view as JSON" button, which gives us the technical definition of the component and allows us to edit it directly. Why is this feature important to you - To help with user support, accessible advanced components that are easy to copy and paste, and efficient batch changes for expert users. How would you like the feature to work - In the builder for Segments and Calculated Metrics, introduce a new button to bring up JSON view, similar to this mock: Upon clicking, this would open a modal similar to the existing debugger, with an editable JSON definition of the component: Once edited, the user could then apply this new definition to the component. Of course, it should be validated first, but the changes should then be reflected in the component builder. Ideally, there would also be a button to download the definition as a JSON file as well as an upload for a previous export. The same workflow could be used for Freeform tables, Panels, or even entire Projects: This could help massively speed up support and community sharing of components. Current Behaviour - "No, don't drop it there you buffoon! No, that's where we started 20 minutes ago! Just close it and open it again, but DON'T SAVE!"

FrederikWerner
FrederikWernerNew Participant

Make Extension development easier by allowing direct Extension uploads and releasesNew

Description - Companies are able to develop and release both private and public Extensions to Adobe Tags to provide new capabilities. However, the process of making an Extension available internally or externally is complicated to a point where companies and individual community members (me included) refrain from doing so. While the development can be complicated on its own due to the mandatory Node JS tool stack, releasing an Extension (even internally) is even more convoluted and requires work with the APIs, managing Adobe IO integrations, and certificates/keys. To help with that, I want to propose an extension to the web interface of Tags to allow easier Extension management. Why is this feature important to you - Because I would like to see a more active community around providing capabilities for Adobe Tags. How would you like the feature to work - In an Extension-development Property within Tags, provide new menu items to manage Extensions. Specifically, I can think of options for uploading and releasing the custom Extensions: In the "upload" tab, provide a simple drop-zone for .zip files created by the @61380/reactor-packager tool. Dropping a file there would do the same as the @61380/reactor-uploader tool, without all the API shenanigans. In the "release" tab, we would see a listing of the company's packages and have them available to be released and discontinued. Again, this just uses the available API without all the normally required overhead. Current Behaviour - Very few contributors to the Adobe Tags catalog, even fewer active contributors, and many hours wasted on API wrangling.

heatherw8018699New Participant

Mass export/delete entities based on filter in Target RecommendationsInvestigating

I can't take credit for this idea. It was suggested ~2 years ago by @brendanjaffary It's desperately needed for clients who maintain large catalogs in Adobe Target. It was suggested to me to post this again so it's more recent.  Summary We need to have a feature that can mass delete entities based on a filter. I manage a catalog of over 400,000 entities so running a full catalog deletion is a huge impact to the business.  There is no real solution to manage your catalog as the comma delimited string for singular deletion requires the user to have a list of entityIDs to delete which they are not able to export from the catalog.In the documentation, it states that the more entities in your catalog, the longer your criteria’s will take to process.  I’ve also noticed that the larger my catalog is, the less accurate the recommendations are. Temporary SolutionThrough a recommendation of a forum user... once you filter your catalog to whatever your deletion needs are, you can override the API call in the network tab of developer tools to expand the pagesize of the call.  Just simply adjust the pagesize in this network call : "target/products/productSearch.halosearch.at.json?pageSize=10". Once you have the data, you can parse through it to get all of the entityIDs, concat them into a comma delimited string and send the request off. This is a poor solution as both the query and the delete command can't handle more than 10,000 entities at a time and requires additional development work.  I tried to write an application to manage this locally but ran into CORS issues with the API.  I'm sure that these APIs arent intended to handle this amount of data either.Ideal SolutionThe most ideal solution would be:Filter the catalog by “lastModifiedDate”  **Currently not an available filter but data is available in catalog**Add any additional filtersExport the data to an Excel file for further analysis on the data as the Catalog UI lacks sorting functionalityBatch delete all of the entities within the filtered selectionBeing able to filter by “lastModifiedDate” is essential as it will identify entities that haven’t been viewed by users in a long period of time, often indicating that the entity isn’t available anymore.