Under Community Review

Change object icon in Publication Manager to automatically indicate that an object is in more than one map (shared)

This is similar to another request, except that the icon color/change would not depend on object title naming conventions.  In a publication in SDL Publication Manager 12.0.4, you can display a the "where used" window, but you have to click and check each object--the information is available, but hidden. 

Most of us work in a publication.  It's all to easy to go down the list of topics in pub as you incorporate SME comments or make updates, but totally miss that an object is shared with another map.  It would be really great if the icon were different for shared objects (such as a little S partially superimposed), just to give you the warning that it's reused somewhere (and you should check where...). 

Trish Billard

  • Here are some ideas to implement it:

    1. Custom Icon Indicators

    • Create a Custom Icon for Shared Objects: Develop a small icon overlay (e.g., a chain link) that indicates an object is used in multiple maps. This could be achieved by customizing the user interface to display a different icon when an object is found to be shared across maps.
    • Dynamic Icon Color-Coding: Implement color-coding for objects in the map based on their shared status:
    • Green for objects used only in the current map.
    • Orange for objects shared across 2-3 maps.
    • Red for objects shared across more than 3 maps.

    2. Metadata-based Visuals

    • Automate Metadata Tracking for Shared Objects: Set up metadata fields that automatically track the number of maps an object is included in. Use this metadata to trigger the icon change in the Publication Manager.
    • Add a ‘Shared Object’ Indicator in Metadata: Use a metadata field to check if an object is shared and reflect that in the icon display within the UI.

    3. Rule-Based Icon Change

    • Leverage Business Rules for Icon Updates: Establish rules in the CMS that change the object’s icon in the interface based on how many maps the object is linked to. For example, a script could check how many maps an object is part of and adjust the icon dynamically.

    4. UI Enhancement for Shared Objects List

    • Show a “Shared Across” Icon Tooltip: When hovering over an object icon, display a tooltip that shows the names of the maps the object is shared across. This can help users quickly identify shared items.
    • Object List View Enhancement: Add a new column in the object list view that visually indicates if an object is shared and how many maps it’s part of.

    5. Integration with Event System

    • Use Event System for Real-time Updates: Configure the event system to track when objects are added to multiple maps and then trigger the icon update. The event system could automatically update the UI to display the correct icon.

    6. Component Sharing Report

    • Shared Object Report Integration: Develop a real-time report or panel in the Publication Manager that lists all shared objects and highlights them in the UI, allowing users to identify shared objects without needing to manually check each one.

  • in reply to Varun Sood

    A Graph database would be an interesting, and definitely significant, architectural change for the Content Manager. Out of curiosity, separate from the effort, might a Graph database also go well with a GraphQL API? Nerd

    And not to suggest a solution, but a "flag" of sorts to track if an item is in use or perhaps the next improvement to Content Management search might be ideas to explore as well. 

    One trick we've used in Dynamic Experience Delivery is how images were historically "published." Perhaps this may have changed, but rather than calculating how the images are used during publishing requests, the Content Delivery Broker kept a counter of how an image is "in use." When the counter reaches zero, the items is removed from Content Delivery, so it's not really unpublished. So... maybe the "in use" status of an item doesn't have to be done in real time but rather tracked when used? Relaxed

  • in reply to Roy Janssen

    Hi Roy, We understand the need for such a feature and appreciate the support from the community. However, implementing it is a bit more complex process.  

    To clarify, gathering "Where used" information for an object requires making an API call to the database each time the object is selected. This information is not stored in the database and must be retrieved every time it is needed. With thousands of objects, this means a large number of API calls, which can significantly slow down the performance of the application.

    We have explored various options for implementing this and believe that using a graph database is the most efficient approach. Graph databases are specifically designed to handle complex data relationships with high performance. This is a major architectural change and is something we continue to investigate and evaluate for future developments.