Archive / delete action customisation

[mfendeksilverstripe]

Description

This module supports both cases where the link model is versioned and non-versioned but it doesn't allow the customisation of related archive / deletion actions in the UI (the ability to choose specific action on top of the default choice).

There are cases where link model is versioned but the archive action is not desirable as individual edits such as archiving a link should not be executed right away at the time of edit but rather be batched together with other changes and copied to live stage as a part of page level publishing process.

GridField allows you to decide which publishing path for deletion you need so it would be great if this ability would also be covered for LinkField UI.

Additional context or points of discussion

No response

Validations

• You intend to implement the feature yourself
• You have read the contributing guide
• You strongly believe this feature should be in core, rather than being its own community module
• You have checked for existing issues or pull requests related to this feature (and didn't find any)

[GuySartorelli]

There are cases where link model is versioned but the archive action is not desirable

Can this be resolved by setting canDelete() permissions via an extension? think we made it so the action doesn't appear if the user doesn't have delete permissions for the link.

Cascade archive/delete doesn't check canDelete() on the child records IIRC so I think that would solve this use case and still allow the link to be deleted/archived along with the owner record.

[mfendeksilverstripe]

Hey @GuySartorelli thanks for the suggestion but that's not the case that we're after though. Let me try to surface more details. This is my test setup:

• page -> text block -> has one link
• I want to delete the link without immediately impacting the Live version of the page
• then I want to use the page publish button to propagate the link deletion to live stage

What we're after is having the control when deletions are applied to the live stage of the page.

[GuySartorelli]

I want to delete the link without immediately impacting the Live version of the page

I don't understand what you mean by this.

• For an unversioned link, deleting it deletes it and it no longer exists in any stage regardless of what is stored on the owner record itself.
• For a versioned link, archiving it will remove it from the live stage, regardless of what's happening on the owner record.

Do you mean you want to unlink the link record from the relation on the owner record, so the owner record's draft stage has no link relation, but the relation (and link) are still available on the live stage?

If so, how do you intend to resolve the fact that the link itself will still exist, and now be orphaned, when you publish the owner record? Or would we be saying "if you do this, it's up to you do deal with orphan links" - i.e. that part is out of scope for the module itself?

What UX and technical solution would you propose for unlinking the link, if that is what you meant?

[mfendeksilverstripe]

Sorry for the confusion @GuySartorelli , I think the best way to describe it is via impact on data.

Initial Test setup

• Content page has a text block
• text block has one link
• all content is published

LinkField 3 behaviour

• delete the link attached to the text block
• impact on data below:
• Text block (draft stage) - link ID is set to 0
• Text block (live stage) - no changes
• Link record (draft stage) - deleted
• Link record (live stage) - no changes

Then publish the page (can happen at a very different time, it's not bound to the previous action)

• impact on data below
• Text block (draft stage) - no changes
• Text block (live stage) - link ID is set to 0
• Link record (draft stage) - no changes
• Link record (live stage) - no changes (it would be nice to get this one deleted as this one becomes orphaned but it's not a functional issue as the live page content is not impacted)

This behaviour separates editing from publishing giving content authors greater flexibility when ti comes to control over the live content.

LinkField 4 behaviour

• archive the link attached to the text block
• impact on data below:
• Text block (draft stage) - no changes
• Text block (live stage) - no changes
• Link record (draft stage) - deleted
• Link record (live stage) - deleted

So as far as I can see the changes are done immediately on live stage as well which is something we are aiming to avoid.

[GuySartorelli]

I'm not sure how you would achieve the desired result without either:

1. Removing the link from the relation in the draft stage (which would result in an orphaned link when publishing the owner record), or
2. Using Versioned::deleteFromStage which should probably be avoided. I'm not sure what ramifications this could have for things like reverting versions of the owner record, etc.

It's possible I'm still misunderstanding something about this though - I'd be interested in what your intended technical solution would be to implement this. That might help me more fully understand what you're intending.

[mfendeksilverstripe]

i will post new updates as we're still in the middle of the upgrade. I'm currently not sure about the technical solution but the aim is to separate draft stage editing from publishing the draft content to live as two separate actions that can be executed at different times.

I guess "publishing" is a bit misleading term here as we use it as "transfer current draft changes to live".

[n8-dev]

One should be able to "publish" the "removal" of a relation though, and not be beholden to immediate changes that are public facing.

This is the point of the publishing concept right?

I feel the option 1: should be optional to enable.

I'm curious about this statement though.

i.e. that part is out of scope for the module itself?

Is it wrong to not have a doc section outlining an example clean up job?

[GuySartorelli]

One should be able to "publish" the "removal" of a relation though, and not be beholden to immediate changes that are public facing.

That's the first option I mentioned above:

Removing the link from the relation in the draft stage (which would result in an orphaned link when publishing the owner record)

You're removing the relation between the records, rather than removing the record itself. So the word "delete" or "archive" isn't technically true there. I think gridfield uses the word "unlink". Though I don't know if that would cause more confusion in the case of links or not. And having orphaned links isn't ideal.

I'm curious about this statement though.

i.e. that part is out of scope for the module itself?

Is it wrong to not have a doc section outlining an example clean up job?

That's an option that could be considered... though not getting into a situation where there are orphaned links to begin with would be better. Having a clean up job feels like a bandaid that shouldn't be necessary.