Reverse ownership

[maxime-rainville]

Story

As a developer I want Link objects to have a sensible ownership model so that Link objects behave in a sensible way when versioned operation are performed.

Acceptance criteria

• We have validated what the ownership relations between Link and their owner object should be.
• Usage doc provides clear guidance on how to configure ownership when creating Link relations.
• Ownership model can accommodate situation where link is in Has_many or a Has_One relation.
• The scenario where two "HAS_Many" link relations are managed on the same DataObject is considered.

Note

The links belongs to a single owner relationship.

POCs

Option one:

• NEW Linkfield ownership #101 rejected, use option 2

Option two:

NOTE: This option could be mostly implemented in framework if we have some new way to define it (e.g. has_one_special) - that's necessary so we know when we should have and use the new dbfield which existing has_one relations won't have.

• POC Add new extension hook to update hasmany lists silverstripe-framework#10973
• NEW Link ownership (alternative to #101) #102

INSTALLER CI RUN

https://github.com/creative-commoners/silverstripe-installer/actions/runs/7160809301
Note the SilverStripe\CMS\Tests\Model\SiteTreeTest::testRelativeLink failure is pre-existing. See silverstripe/.github#169

PRs

• NEW Allow a single has_one to manage multiple reciprocal has_many silverstripe-framework#11084
• DOC Document multi-reciprocal has_one relations developer-docs#417
• ENH Respect new has_one config silverstripe-versioned#427
• API Add new Owner relation for handling permissions #127

[GuySartorelli]

Added an alternative solution.

[michalkleiner]

No input as to the issue itself, just o note on the story language — 'sensible' can be quite ambiguous and it's not clear (to me) how to quantify that and what it should express/mean.

[maxime-rainville]

I had a glance at Guy's solution. I didn't think it was obviously wrong or horrible ... although it seems like a lot of effort to accommodate a rather simple use case.

In the spirit of iteration, what would happen if we just declared that only one link list can be tied to one record? We could wait to see if anyone actually has a use case for having two or more link lists. Could support for multiple Link List on one DataObject retroactively added later on?

[GuySartorelli]

We could wait to see if anyone actually has a use case for having two or more link lists.

No need to wait, I had that exact use case multiple times when I was working at signify (different link module, but same use case)

Could support for multiple Link List on one DataObject retroactively added later on?

Arguably yes but adding a relation field like this after the fact would be hard to retrofit, since the data won't be there to filter against.

The better option if you don't want to implement this right off is to just have a simpler permission model, remove the has_one, and accept that we never have access to the 'owner' from the link side of the relationship.

[emteknetnz]

The better option if you don't want to implement this right off is to just have a simpler permission model, remove the has_one, and accept that we never have access to the 'owner' from the link side of the relationship.

Isn't the difficulty with the can*() checks only an issue for the has_one's on a Page/DataObject?

Seems like what Max is talking about is a separate issue which is support for multiple has_many's on a Page/DataObject.

I don't think there's any issue finding the owner to do can*() checks with the has_many relationships

I'd agree with Guy that we should solve the multiple has_manys now. I don't think Guy's solution was particularly much effort, it's really just an extra column added next to a couple of existing columns.

[GuySartorelli]

Isn't the difficulty with the can*() checks only an issue for the has_one's on a Page/DataObject?

It's also a problem for multiple has_many relationships if you don't use a workaround to have all has_many relationships use the same has_one. I'd be strongly against saying we can't support multiple has_many, so we either have to point them all at the same has_one or not have the can* rely on the owner.

[emteknetnz]

I'm a bit confused - on Max's has_many implementation there was already Link.has_one = [ Owner => DataObject::class ] - which will add the columns OwnerClass + OwnerID to the Link database table - that's enough for you to get the owner easily? Your PR adds OwnerRelation so that we can assign Links to the correct Relation, though I'm not sure why that's necessary to get the Owner specifically?

[GuySartorelli]

We have decided to proceed with option 2, pending the creation of a version of the linkfield that can handle has_many relationships. This card is blocked until that has been implemented.

[emteknetnz]

Linked PRs have been merged