Details

    • Similar Issues:
      Show 5 results 

      Description

      As described in LPS-13066, web content, images (from Image Gallery) and documents (from Document Library) can be deleted even if referenced (web content being referenced in a Web Content Display portlet, images and documents being referenced in a web content object). It would be helpful to have this function for finding out where such a Liferay object is referenced also available as a context menu item on the corresponding Liferay object in the Control Panel.

        Issue Links

          Activity

          Hide
          Juan Fernández added a comment -

          Hi Holger:
          do you propose this to be a method in a service? Something like assetEntry.getUsageCount() so that you can check before deleting or something more informative for the administrator (just in the UI)? I mean, you want to "see" the usage statistics of each asset or you want to behave depending on that statistics?

          Show
          Juan Fernández added a comment - Hi Holger: do you propose this to be a method in a service? Something like assetEntry.getUsageCount() so that you can check before deleting or something more informative for the administrator (just in the UI)? I mean, you want to "see" the usage statistics of each asset or you want to behave depending on that statistics?
          Hide
          Holger Koschek added a comment -

          Hi Juan,
          I would like to have this functionality available in the UI - not only for an administrator, but also for an editor who wants to find out where his/her assets are being used. Instead of a usage count, I'd expect a list of portal pages or web content objects as a result. It would be great if the technical implementation of this functionality would also be available as a service. This would simplify the implementation of a delete hook. This hook kicks in whenever a Liferay asset is going to be deleted. It informs the user where this asset is currently being used and offering him the choice to cancel the delete process.

          Show
          Holger Koschek added a comment - Hi Juan, I would like to have this functionality available in the UI - not only for an administrator, but also for an editor who wants to find out where his/her assets are being used. Instead of a usage count, I'd expect a list of portal pages or web content objects as a result. It would be great if the technical implementation of this functionality would also be available as a service. This would simplify the implementation of a delete hook. This hook kicks in whenever a Liferay asset is going to be deleted. It informs the user where this asset is currently being used and offering him the choice to cancel the delete process.
          Hide
          Juan Fernández added a comment -

          Hi Holger:
          I think this is quite interesting, but there are some problems we need to solve in order to implement this.

          This pattern should be applied to the assets framework so that all assets can profit this. Right now we have view count, so that'll be something similar.
          The problem I see is that you want to know WHERE the asset is being used, and there's no easy way to know that, as an asset can be used in many different places. If you add an asset to a page (via a static asset publisher or a web content display) it's easy to store the layout Id, but what happens with embeding images in web contents? I don't see an easy way to implement this.

          Apart from that, assuming we have the layout ids of all places where an asset is shown, we have to be careful with performance issues (update the database record every time you add/remove an asset to a page can be costly)

          I'd like you to define the user cases to use this and a set of methods you'll need as a service. Have you think about a UI for this?
          Thanks a lot for your feedback!

          Show
          Juan Fernández added a comment - Hi Holger: I think this is quite interesting, but there are some problems we need to solve in order to implement this. This pattern should be applied to the assets framework so that all assets can profit this. Right now we have view count, so that'll be something similar. The problem I see is that you want to know WHERE the asset is being used, and there's no easy way to know that, as an asset can be used in many different places. If you add an asset to a page (via a static asset publisher or a web content display) it's easy to store the layout Id, but what happens with embeding images in web contents? I don't see an easy way to implement this. Apart from that, assuming we have the layout ids of all places where an asset is shown, we have to be careful with performance issues (update the database record every time you add/remove an asset to a page can be costly) I'd like you to define the user cases to use this and a set of methods you'll need as a service. Have you think about a UI for this? Thanks a lot for your feedback!
          Hide
          Holger Koschek added a comment -

          Hi Juan,
          I have found the following use cases:

          Use Case 1: Deleting an asset
          Whenever a user wants to delete an asset, Liferay should check if this asset is being used on a portal page directly or indirectly. If references to an asset have been found, those references (i.e. portal pages) are displayed, and the user is asked if she still wants to delete that asset.
          With directly, I mean that the asset is referenced by one of the two portlets. With indirectly, I mean assets (e.g. images or documents) that are used by the directly referenced assets.
          The reference check only takes into account the published version or (where applicable) the draft version of an asset. Older versions are ignored.
          I would restrict this check to Web Content Display portlet and Asset Publisher portlet, since those are the standard ways to publish an asset on a portal page.

          Use Case 2: Deleting a version of an asset
          Whenever a user wants to delete the published version of an asset, Liferay should check if the version that will become the new published version contains references to assets that do not exist (anymore).

          Use Case 3: Check if an asset is being used
          In the Control Panel, the user can check for every asset if it is being used on a portal page directly or indirectly. The reference check only takes into account the published version or (where applicable) the draft version of an asset. Older versions are ignored.
          This function is useful if an editor wants to clean the content pool by removing unused objects.

          Use Case 4: Bulk check for unused assets
          A user can check (with just one click) the references of all assets of a community. The result of this function is either a list of all assets without a direct or indirect reference, or a list of all assets, together with a reference count (direct/indirect) or a list of referenced assets.

          I unserstand your issue with the indirect links. However, to us this is very important, since we heavily use structured content. I could imagine a two-step process. In a first implementation, only the direct links will be evaluated. Later on, the indirect link analysis can be added. What do you think?

          Kind regards,
          Holger

          Show
          Holger Koschek added a comment - Hi Juan, I have found the following use cases: Use Case 1: Deleting an asset Whenever a user wants to delete an asset, Liferay should check if this asset is being used on a portal page directly or indirectly . If references to an asset have been found, those references (i.e. portal pages) are displayed, and the user is asked if she still wants to delete that asset. With directly , I mean that the asset is referenced by one of the two portlets. With indirectly , I mean assets (e.g. images or documents) that are used by the directly referenced assets. The reference check only takes into account the published version or (where applicable) the draft version of an asset. Older versions are ignored. I would restrict this check to Web Content Display portlet and Asset Publisher portlet, since those are the standard ways to publish an asset on a portal page. Use Case 2: Deleting a version of an asset Whenever a user wants to delete the published version of an asset, Liferay should check if the version that will become the new published version contains references to assets that do not exist (anymore). Use Case 3: Check if an asset is being used In the Control Panel, the user can check for every asset if it is being used on a portal page directly or indirectly . The reference check only takes into account the published version or (where applicable) the draft version of an asset. Older versions are ignored. This function is useful if an editor wants to clean the content pool by removing unused objects. Use Case 4: Bulk check for unused assets A user can check (with just one click) the references of all assets of a community. The result of this function is either a list of all assets without a direct or indirect reference, or a list of all assets, together with a reference count (direct/indirect) or a list of referenced assets. I unserstand your issue with the indirect links. However, to us this is very important, since we heavily use structured content. I could imagine a two-step process. In a first implementation, only the direct links will be evaluated. Later on, the indirect link analysis can be added. What do you think? Kind regards, Holger
          Hide
          Holger Koschek added a comment -

          Hi Juan,
          any comments on my use cases?

          Kind regards,
          Holger

          Show
          Holger Koschek added a comment - Hi Juan, any comments on my use cases? Kind regards, Holger
          Hide
          Juan Fernández added a comment -

          Hi Holger:
          I'm really sorry for the delay on my response. This got lost in my always growing "to be answered" list :$
          I think this is very important on portal administration of contents, so we should definitely look at this.
          I'm going to speak with other core developers to look for the best way to implement this without having a big impact in performance.
          I think we can do this step by step, asset by asset, instead of doing it for all the portal.
          According to your experience, what are the most important checks that should be done? I mean, if you could choose a single use case, which one would be the most important for you?
          For the moment, this is being checked on structures, templates and web content (you can't delete a structure if there's a web content using it): what would be the next use case?
          Thanks a lot for your patience!
          Juan

          Show
          Juan Fernández added a comment - Hi Holger: I'm really sorry for the delay on my response. This got lost in my always growing "to be answered" list :$ I think this is very important on portal administration of contents, so we should definitely look at this. I'm going to speak with other core developers to look for the best way to implement this without having a big impact in performance. I think we can do this step by step, asset by asset, instead of doing it for all the portal. According to your experience, what are the most important checks that should be done? I mean, if you could choose a single use case, which one would be the most important for you? For the moment, this is being checked on structures, templates and web content (you can't delete a structure if there's a web content using it): what would be the next use case? Thanks a lot for your patience! Juan
          Hide
          Holger Koschek added a comment -

          Hi Juan,
          for us, use case 1 is the most important, with a focus on direct links (i.e. references of web content objects in either Web Content Display portlet or Asset Publisher portlet instances on portal pages). It would be nice to also have all images and documents checked that are referenced by a web content object, but this could also be added later.
          I would assume that once this check has been implemented, use case 3 could be solved quite easily, so this is my second choice.

          Kind regards,
          Holger

          Show
          Holger Koschek added a comment - Hi Juan, for us, use case 1 is the most important, with a focus on direct links (i.e. references of web content objects in either Web Content Display portlet or Asset Publisher portlet instances on portal pages). It would be nice to also have all images and documents checked that are referenced by a web content object, but this could also be added later. I would assume that once this check has been implemented, use case 3 could be solved quite easily, so this is my second choice. Kind regards, Holger
          Hide
          Juan Fernández added a comment -

          Hi Holger,
          So the first step would be to check on deletion time (for all assets):

          1) Web Content Article: is it published on any of the Web Content Displays of the portal?
          2) The rest of assets (blogs, documents, wiki pages, MB comments...): are they in asset publishers configured to show *only* that asset?

          This is something easily doable. We are now closing the current version (6.1), but this could be introduced in the next one.

          Are you a developer? Are you willing to contribute this feature to the Liferay project? I think this first step would be a nice contribution and the starting point for many interesting new features for the project

          Tell me what do you think about this
          Thanks a lot!
          Juan

          Show
          Juan Fernández added a comment - Hi Holger, So the first step would be to check on deletion time (for all assets): 1) Web Content Article: is it published on any of the Web Content Displays of the portal? 2) The rest of assets (blogs, documents, wiki pages, MB comments...): are they in asset publishers configured to show * only * that asset? This is something easily doable. We are now closing the current version (6.1), but this could be introduced in the next one. Are you a developer? Are you willing to contribute this feature to the Liferay project? I think this first step would be a nice contribution and the starting point for many interesting new features for the project Tell me what do you think about this Thanks a lot! Juan
          Hide
          Randy Zhu added a comment -

          In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”. Additional information to follow soon.

          Show
          Randy Zhu added a comment - In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”. Additional information to follow soon.

            People

            • Votes:
              13 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since last comment:
                2 years, 10 weeks, 5 days ago

                Development

                  Structure Helper Panel