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
Parents

  • This item has been open since 2018 and has a top score.
    How many ups does an idea have to get to get picked up?

  • 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. 

Comment
  • 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. 

Children
  • 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