Dependency system for relation fields & editorial workflow.

[cassiozen]

Currently, the relation widget only display fields already published and available through search integration.

But the ideal flow should work like this:

• the relations just work, whether something is published or not
• So if the user is working on an "event" kind of entry
• He/she can create new speakers, events, etc, and create the relations, everything marked as in progress in the editorial workflow
• Once he/she do “Publish” for the event, the CMS notices that a bunch of relations are not ready to be published, and tells me those needs to be ready for publishing as well, once those are ready for publishing, I click “Publish” and the CMS tells me:

* Cassio Zen (speaker)
* The React Way (workshop)

Publish all items now?

[cassiozen]

Thoughts on how to implement this:

From the point of view of architecture, I can create a new metadata field for unpublished entries, something like dependencies

And when we try to publish, it would check all the dependency three to see which ones were not published yet…

Obs.: Since metadata exists as long as the entry is on “unpublished” state, we will need to validate across metadata AND published entries. (And maybe throw an error if the entry wasn’t found in any)

[ikaikahussey]

What's the code for implementing a relations widget in a layout?

[erquhart]

@ikaikahussey we really should document that widget. Here's an example implementation:

- {label: "Author", name: "author", widget: "relation", collection: "authors", searchFields: ["first_name", "last_name"], valueField: "title"}

The collection should indicate which collection to search, the searchFields indicate which fields to search against, and the valueField should be the name of the field that contains the value that you want to use from the matching entry.

[ikaikahussey]

Thanks @erquhart for the response. Can you point me to an implementation in a frontend layout?

[erquhart]

That sort of depends on your build system. The relation field's value is accessible in the same way any other field's value is, it's yaml frontmatter.

[ikaikahussey]

Ok thanks. I'm experimenting with Spike.

[erquhart]

@ikaikahussey reach out on our Gitter if you have any other questions, happy to help :)

[verythorough]

Some discussion of this in the (closed for now) PR #243. A possible alternate way of handling multiple items that must be published simultaneously is to allow the user to create a 'project' (or something similar) that's essentially a UI wrapper for a named branch with multiple file changes on it.

For example, if a user wanted to post a new conference talk description and a new speaker profile to go with it, the workflow could be something like this:

1. User starts a new item in the talk description collection, and before saving, selects a UI option to save the item to a 'project'. They select an existing project, or type a name for a new one.
2. On the backend, when the CMS creates a branch to commit/PR, instead of using the post title, it uses the project title to name the branch.
3. User starts a new item in the speaker profiles collection, and before saving selects the UI option to save the item to the project created for the talk description.
4. On the backend, rather than creating a new branch, the CMS commits to the existing project branch.

There are certainly other problems to solve here, like how to show these grouped items in the UI, and how one might go about requiring certain items to go together (i.e., every talk description needs a speaker profile), but I think it can be a fairly simple way of leveraging built-in Git functionality for what could otherwise be pretty complex.

[erquhart]

Note: this dependency system should also include deletion.

[lmaddio]

Any updates here?
Is it possible to overwrite the function of the remove button?

[erquhart]

Not currently possible, but can you explain a bit more of how that could help your use case?

[lmaddio]

@erquhart I have a collection of sections in a blog, a collection of notes that has a field of relation between the note and the section, I wanna delete the notes thats depends on that section so after the commit the notes doesn't break everything (of course that, in my case using Gatsby, I can take care of this situation) but I think It would be nice to be able at least to overwrite the function of this button or extend it so its get able to prevent this things to happen.

[erquhart]

Ah, understood. Custom functions for CMS internals aren't really a thing, but deletion is within the scope of this ticket, so this issue being resolved should provide the functionality you need.

[dkarbayev]

This is a needed feature, especially for content-rich websites, where some entries might reference to others as "Featured" or "Related", so when those entries are deleted, we need to keep in mind, that there're some article that is referencing to the one that's being deleted. Warnings (blocking or not) about dependent entries and/or cascade deletion would be nice to have.

[verythorough]

I just happened across this issue which is somewhat related: #1025

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[begonaalvarezd]

What is the status of cascade deletion? Once the content is published and I remove an entry that is linked in multiple places, I am having hard times finding where all these broken dependencies are and fix them by hand. I feel that this is really a needed feature, or am I missing something?
Thanks!

[erezrokah]

Hi @begonaalvarezd, a quick win for handling deletions might be to add a preDelete, postDelete events:
https://www.netlifycms.org/docs/beta-features/#registering-to-cms-events

Then at least a user can have some kind of automated way to handle it.
If that makes sense you can open a new issue for adding those events.

Having the CMS track dependencies and cascading deletion is a much bigger lift.

[panzacoder]

Is creating relations "on the fly" in progress? It is a major blocker for me adopting NetlifyCMS.

When content editors are creating new pages, they aren't going to want to create every type of content in silos and then link them. I understand the intention is for a really simple use case like a blog and blog author, but the way relations are currently implemented is super limiting.

[erezrokah]

Hi @panzacoder, before adding this feature we would probably need to do #1025, as the CMS doesn't have any functionally to manage multiple content files (entries).
Both require effort from a UX perspective and internal implementation work.

That being said we would love any kind of contribution for this - it doesn't have to be code. It can also be help in defining how this would look like from the user's side.