Is your feature request related to a problem? Please describe.
As of right now, the internal identifier for relationships is the object ID, which can be a duplicate across compendiums.
Which means that if two items have the same ID, either randomly, or because dragging folders across compendiums preserve ID of the items inside it, only one of those item can be added as a relationship.
Describe the solution you'd like
Maybe use the full UUID as internal identifier ? I'm not familiar enough with the code to know if that would break things.
To avoid breakage during migrations a function could be run in the init hook and replace .id with .uuid if fromUuidSync(.id) returns undefined.
Additional context
Stumble upon that when migrating objects across compendium folders, PR #672 somewhat related, to allow the deletion of defunct relationships through the UI.
Is your feature request related to a problem? Please describe. As of right now, the internal identifier for relationships is the object ID, which can be a duplicate across compendiums. Which means that if two items have the same ID, either randomly, or because dragging folders across compendiums preserve ID of the items inside it, only one of those item can be added as a relationship.
Describe the solution you'd like Maybe use the full UUID as internal identifier ? I'm not familiar enough with the code to know if that would break things. To avoid breakage during migrations a function could be run in the init hook and replace .id with .uuid if fromUuidSync(.id) returns undefined.
Additional context Stumble upon that when migrating objects across compendium folders, PR #672 somewhat related, to allow the deletion of defunct relationships through the UI.