[MGNLCDEP-133] Strange behavior regarding assets dependencies on removal Created: 24/Mar/23  Updated: 27/Jun/23

Status: Accepted
Project: Content Dependencies
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Carlos Cantalapiedra Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File shark_brian_warrick_0824.JPG    
Issue Links:
Problem/Incident
supersession
is superseded by MAGNOLIA-8951 Link generation for non existing node... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: AuthorX Support
Team: AuthorX

 Description   

Steps to reproduce

  1.  Go to demo, open pages-app and create a basic page
  2.  Edit the page and within the main area, create a Text&Image component
  3. Within the Text tab, at the Rich text editor, click on "Link to DAM document" and select the asset /tours/shark_brian_warrick_0824.JPG
  4. Go to Assets app, select the asset /tours/shark_brian_warrick_0824.JPG and click on Delete item
  5. Check a warning is shown regarding dependencies with the page
  6. Proceed to delete the asset + publish deletion
  7. Go to pages-app and check that tho the link still exists, it is broken
  8. Back to assets-app, upload the /tours/shark_brian_warrick_0824.JPG asset
  9. Go to pages-app and check that the asset can be download sucesfully
  10. Go to Assets app, select the asset /tours/shark_brian_warrick_0824.JPG and click on Delete item
  11. Check that this time, no warning is shown regarding dependencies and the asset can be deleted without knowing is is referenced on a page

Expected results

The second time you try to delete the asset, a warning message is shown regarding dependencies

Actual results

The warning is only shown the first time, the second time you try to delete the asset there is no warning.

Workaround

N/A

Development notes

N/A



 Comments   
Comment by Roman Kovařík [ 24/Mar/23 ]

By uploading new asset, even though it's the same binary file, a new asset new a new UUID is created. This could be only done with export/import.

Comment by Antonín Juran [ 14/Jun/23 ]

DISCOVERY

References are searched by node identifier, see here.
Newly uploaded asset gets a new identifier despite it has the same path as the previously deleted.

Suggested solution

Search references by path instead, see here.

Comment by Roman Kovařík [ 14/Jun/23 ]

Search references by path instead, see here.

Could you elaborate on consequences?

  • migration effort
    • all workspaces
    • bootstrap files
  • move operation
    • by fixing this use case, all moved references would be broken

One could argue that the behaviour is correct and should work only when reimporting bootstrap file which includes the correct UUID. After fixing this, we might expect more curious use cases in the future such as:

  • Should it work also if I rename the file but the binary is still the same?
  • Should it work if I upload the same binary file somewhere else?
Comment by Antonín Juran [ 14/Jun/23 ]

Possible solutions:

  1. We could update our documentation and provide a groovy script searching assets which have no UUID or path references see original customer requirement on SUPPORT-16172 ticket.
  2. The searching of references could be extended with searching by path but it could cause performance issue in case large data (could be configurable).
  3. Remove the node properties storing the references when referenced asset is deleted - could be performance expensive but could run in separate thread.  

The issue described in the related SUPPORT-16172 ticket should be solved in core module (possibly in LinkUtil#createLinkInstance), there shouldn't be generated valid links by path if specified uuid doesn't exist - created ticket MAGNOLIA-8951. 

Generated at Mon Feb 12 00:12:51 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.