Save Item as Future Revision (Draft of Published Item)

[benhaynes]

Currently you can...

• Create/update an item as draft or published
• Every update stores a revision of it's previous state (past)
• You can rollback/revert to a previous revision state

I propose that we allow:

• Saving a revision without updating the parent item (future)

Then we can use the same rollback/revert... but to advance to a future state. This essentially lets you stage future changes to an item, and should be as simple as saving a revision without updating the actual item. We'd want to update some language (eg: "revert" to "advance" when in the future), and when you actually revert/advance, that should be stored in activity (something happened) but we don't need to save the revision again (would be a duplicate).

Questions:

• How to deal with relational data
• How to handle permissions (eg: can create revisions, but not item or revert)

[benhaynes]

Based on a chat with @rijkvanzanten...

1. Add directus_collections.revision_scope to explicitly allow-list what fields (parent and relational) should be saved.
   • Ref: https://github.com/directus/next/discussions/259
2. Implement the logic in the API and App to allow saving a revision without an item update.
3. Add a head or current flag to the directus_revisions collection (likely a compound key with collection and item), so that we know exactly the revision that you are currently on (could be in the past)
4. Add new revise/suggest action type to directus_permissions that allows changing the permissions for this specific feature
5. Big warning when reverting to a revision that updates relational data, and advance UX on Item Detail page when suggesting but non ability to update.

[rijkvanzanten]

directus_collections.revision_scope should support:

• * for all current level fields
• CSV of fields
• dot notation in fields for nested / related records

[Crunchyman-ralph]

Could we have more details on this temporary solution ?

[rijkvanzanten]

Could we have more details on this temporary solution ?

What temporary solution? My comment above is just a thought on how this could work (but doesn't currently)

[jojomillennium]

Following a discussion with @rijkvanzanten I wanted to share our use case.

Directus offers apparently (just read the doc, not yet tested) a way to manage permissions so that people Editors cannot save edits on published items, but take them from published to draft and save them, and other users Publisher can change status to published and save them... that is great, but it is missing the critical aspect... an item moved to draft would suddenly not be visible from the frontend, as we should only display published(i.e. approved) content.

Basically, we want to have the time to update content from our platform without impacting what is currently published and visible by all.

Let's take a first concrete and theoretical example: a Terms and Conditions page from a website.

This Terms and Conditions content is manage in Directus and published to the website, therefore visible to all.
We will update our terms and conditions, so an editor will open the item, put it to Draft status and start updating where it needs to be updated. Question the legal department, ask for input from his manager, etc... but during this time needed to get the new version completed, we still want the current, and still valid, Terms and Conditions to be visible to all until the new version is ready and published.
Then, when the new version is ready, and approved by the validator to be set to status Published, the new version become the new Terms and Conditions visible to all.

My initial (and basic) assumption when I played around to find a way was that we could, for any object like items, have a way to GET all that are published. But not just a simple filter status = published, but an actual extract of the LATEST published version of an item.

What I had imaged doing at first if Directus cannot make it happen is to have two environment, the staging Directus for our staging front end as well, and the Prod directus, for our Prod front end. Noone can edit directly in Prod, but have roles set up in Staging, and webhooks so that only takes 'Published` content into our Prod instance... but that also has some possible challenges.

I'm fairly new to Directus, so not sure how it's built, but what if we have for each collection a secondary (hidden) collection where we only store the latest published version. Everytime we save an item as published, we override that other (hiddne) collection as well. Then the API could have a parameter published= true which would fetch from that collection.
That brings also new question:

• How to unpublish something we really don't want live anymore => If we can configure the status to have "internal logic", i.e. "Publish" = put to the "publish collection", "Unpublish" = delete from the "publish collection".
• Every field configuration change on the main collection, the hidden also needs to be updated.

Sorry for the long post, happy to discuss further!

[rijkvanzanten]

@benhaynes Instead of metadata in the same collection, I think @jojomillennium proposed having a secondary collection (a duplicate) which would be treated as the "published" versions of the records in the "draft" collection. This would mean that making something published / draft is moving things back and forth two collections 🤔

[benhaynes]

Ahhh, I missed that. Well, that concept makes more sense to me, and is worth discussing. I still think it feels a bit unfortunate to create duplicate tables for this — seems like a lot of risky opportunities for schemas to get out of sync in time. Still, it's an option... and it's less "proprietary".

[jojomillennium]

Right, I agree that the two statuses (draft + published) in the same collection can become a mess.

In any existing content based interface (app, website, ...) there is a notion of what is live to be viewed by end users, and what is in an editing process.
Directus allows to managed our own publication flow and statuses, so we will need somewhere to tell Directus "That status is my Published flag", then any other statuses based on a platform's custom editing flow (Draft, In Review, Ready for Approval, ...) are content that are not considered ready to be viewed by end users.

Unless we can query the revision collection to fetch the latest "published" version of collections/items, maybe the secondary collection could work out. Unless there is another approach.
Or instead of having for each collection its second "published" collection, could we have a single collection that works like the revision, which could be named publication and would receive only published content? And not stack it like the revision, but overwrite the published item to its latest published version ?
Issue with this is how to query, filter, sort on the big publication collection as it would probably be text/json blob.

[jojomillennium]

And without forgetting the ability to remove published content as well, as there are three cases:

• I want to edit the content of a page, but not remove the current published version until I publish the new one.
• I want to unpublish a content to edit it, and republish it when ready
• I want to unpublish completely a content that should not be live anymore.

[rijkvanzanten]

Technically speaking, this duplicate collection setup would mean that this "staging vs production" setup is technically user configured/configurable. The only thing that we would add from a directus perspective is a way to move (export/import?) items between collections 🤔

[jojomillennium]

One advantage of my initial idea to use two environments:

• Our Prod environment with its Directus instance, will only have "Published" content, not editor/approver access
• Our PreProd environment with its Directus instance, with Editors and Approver roles, with webhooks that would copy to the Prod instance items that are saved as "Published" by our Approver role.
  The advantage is that we would have the ability to preview the content being edited as draft in the PreProd environment.
  The "Unpublished" flag can also have its webhook to remove the corresponding item from Prod, witout deleting it from the PreProd one, until it is either republished, or archived.

Nevertheless, having native publication flow, that would allow to edit content that is published, without changing the published version until it is republished is still critical for a CMS. Also able to unpublished (remove from being live) it while still editing it.

Do you have an idea of the roadmap for such a feature?

[benhaynes]

There is no timeline for this yet, and while it's an important feature, we'll likely be focusing on stability and a few other features before this one... unless it gets sponsored.

As for "be able to unpublished (remove from being live) it while still editing it.", this is already possible... you can simply set a status from published to draft (with the proper code in your client project to limit status) and keep working on it.

[krazyjakee]

@benhaynes what would a sponsorship look like?

[benhaynes]

@krazyjakee — @rijkvanzanten and I will have to look at the time it will take to develop this feature. It touches on database, design, App, and API, so it will be a few day's work. You can email me at ben@directus.io to coordinate this if you'd like.

[MiniDigger]

I have a similar usecase as jojo.

I would argue that using separate environments for this is meh.
syncing could have all kind of challenges (schema changes) and since its automated mistakes could be kinda hidden.

Traditionally we would use staging for the development side, and then in prod, a publication flow for the content.
so we have a dev env, where we rapidly develop apps that use directus, playing around with the schema daily, nuking stuff. then a staging env where users can test the next software release, where no actually changes are done anymore, just bug fixes. and one prod env, where nothing is touched at all in the collection management and our apps, but where users are editing stuff which they may or may not publish already (scheduled publishing would be the cherry on top, new post on news page without having to manually press publish)

the revision approach sounds promising. having the current live copy of the data in the actual item table and the future, current working copy in some proprietary is not an issue for me, since I can't imagine a usecase where I would want to write data using sql but manually publish them later.
however this would fall apart if I would have some service that writes via sql and some user modifies the same version in an unpublished version in the frontend. would also need to decide if api writes to into publish or unpublished. I could also see the revisions diverging strangely depending on where you do changes and rollback and stuff.
a potential advantage of this more complicated system I see would that it could handle more complicated stuff like A/B testing, where you might have more than one HEAD revision thats currently live.

I think the dual table approach would be the simplest one from my point of view. yes, its kinda staging, but its would be strictly staging for content changes, not for collection setup changes. as such its simpler and could be nicely integrated into the UI. I think I would hide the published tables by default and add a buttons to an item to view/compare to the current published version.
this would also make sure that the history is clean, the published table would have revisions for every publish, could potentially even require an actual comment/integrate approval flows, while the draft/preview table would have tons of small changes and corrections a user does while using some app that uses directus to preview the changes.

[invendi]

Saw this discussion popping up again, I think the discussion went way off track in terms of what the actual feature request was about.

I think it shouldn't be overthought, as the title says 'Drafts of Published Items' - and that's it. Saving a revision without updating the parent item, so that people can have a publishing workflow.

I'm wondering; are there people here who consider sponsoring this feature, I might be willing to put in some money to have this feature baked in Directus.

[benhaynes]

Well, Directus could still allow for some magic behind the scenes that stitches things together. It's all up for discussion, but I can imagine requesting a specific item at /items/123 and having parameters to get previous/future revisions from there. The data could be returned exactly as a "normal" (in collection) item would.

We have options!

[jojomillennium]

Right, so lets have an example to illustrate.
Say I have a collection "movies" with the following items:

• "The Matrix" : latest status published
• "The Matrix Reloaded" : latest status published
• "The Matrix Revolutions" : latest status draft as it's being edited, but was published before, so has a published version.
• "The Matrix 4" : Status draft (no previous published version), so "Parent" = null

Requesting (I'll be fancy in the query parameters for the illustration):

• items/articles would return the 4 articles, keeping the current behavior unchanged
• items/articles?filter[status]=published would return only "The Matrix" and "The Matrix Reloaded", again, current behavior unchanged
• items/articles?revisions=published would return the "Parent" items : "The Matrix", "The Matrix Reloaded", and the last published version of "The Matrix Revolutions" (not its current draft)

Does it make sense?

Now, would we leave to custom logic the possibility to "unpublish" an item? I mean by that, I might have a draft version on going, but I do not want the latest published version to be kept live.
So either we has OOTB another status "unpublished" that "kills" the parent, putting it back like there is only a first draft going on, but not loosing all past revisions. OR letting people have a custom boolean field in their collection such as a "visible" and they manage it in their logic.

And BTW, Happy Holidays!

[krazyjakee]

To answer the initial question, I am considering to sponsor this feature. It's essential to my use case.

[ctheprinter]

Being able to create a new revision that goes to draft, while also still being able to use the published version is a requirement for most content approval / promotion flows.

Our use case is not necessarily for web content, but document production workflows where users change content for automated communications (email/post/sms). For this, being able to use the most recently approved / published version would be great, and then receive a "proof" or preview for a draft (triggered off a webhook).

Any hints of this being in dev? 😃

[benhaynes]

It can be sponsored, but is not in our pipeline as of now.

[jpetryk]

Found this will searching for discussions around auto-save. I found one discussion from 2015 for a previous version of Directus and this. Thoughts on extending this feature to being able to auto-save future versions in the case of browser crash, forgetting to save and leaving for several hours, etc.? It would seem like this would be trivial to be able to at least turn on if desired if this idea of future drafts existed behind the scenes.

[rijkvanzanten]

Totally!

It would seem like this would be trivial to be able to at least turn on if desired if this idea of future drafts existed behind the scenes.

I would agree 👍🏻

The only thing is that we'd have to make sure we add some sort of flag/field/config option to signal which future saves are auto-saves and which are user-created ones

[JonathanDoelan]

Auto-save would be amazing. I think „Draft of Published Item” will build the foundation for it.

[krazyjakee]

Moderation could get tricky with multiple futures. I would suggest the future revision screen show all prior changes yet to take place in its' "updates made" section.

I'd like to call it "suggested edits" which is less guaranteed. "Future drafts" may be misunderstood to be scheduled drafts.

Consider the following use case: wiki and wiki-like sites where the site accepts and moderates more untrusted user edits.

Per-user drafts where users can (optionally) only see their own drafts.

This would also require a better moderation tool where the "updates made" section would need to be visible with a single click to ease moderation at scale.

[CapitaineToinon]

Yes I agree! A wiki-like site is currently what I'm trying to replace and this is the key feature preventing me from leaving mediawiki currently. Although I am currently relying on the Moderation Extension which is also self described as an anti-vandalism tool first. I'm starting to think that the only modern logical choice for a wiki-like site would be to use a git based cms and rely on the power of git to moderate edits but I can't find any good free solutions online.

[dwene]

Just wanted to keep the conversation going here.

We're looking for a way to preview changes for a gatsby website built with directus, where you can preview the changes before deploying. For our use-case, what @krazyjakee was suggesting sounds like the best solution.

[benhaynes]

This is a very popular request, but it also requires a very complicated solution. No big news here, but it's not forgotten. In the meantime, perhaps this could be a good stop-gap?

#5897

[philleepflorence]

I am not sure how much of this helps with the various use cases, but ready to go into details...

A number of instances have admins pre-make templates and relationships for many collections that contributors can "copy to collection" or "create from template"...it helped solve many content moderation issues.

• Admin creates new item with detailed notes, but saves as template into a templates collection;
  • with fields: collection, item, json, notes, ....
• Temp can only create from template or perform curated edits.
• Moderators make edits to existing item and save as template, contributor applies moderator "notes".
• Activity has admin and moderator only on templates collection.
• Temp and contributor are still responsible for the items.

[Alv-sys]

Just here refreshing the discussion in 2022.
I think this is one of the few major functionalities Directus needs to move to the next level and be suitable for all kinds of projects, as many users say, for me is very crucial too.
Is there any plan to include it in the pipeline this year?

[invendi]

Hi @benhaynes Just wanted to clarify that I think you guys (the devs) are doing a great job, even on managing funding/sponsoring stuff like this. I personally will check back on Directus some day, it still seems like a promising product.

My frustration only applies to organizations/people that really 'need' to have certain features baked in but don't want to contribute in any way, technical nor financial.

[AaronBeaudoin]

One of the big blockers here is deciding between the two leading ways of storing future revisions... in the system revisions table, or in the parent itself. It's subjective, but figuring this out would really help push this along. Maybe a community poll on Twitter?

To me it makes the most sense to have the current "published" version be the item in the parent itself, and other versions be in the revisions table. To keep the table from getting huge, Directus could keep revision only to a maximum of a configurable number of days.

I would say that the term "drafts" is best used only to refer to a future revision. This is how the concept is used in Gmail, for example, where a draft is simply an email you haven't sent—or gone live with—yet. In this model there is also no limit to the number of drafts you can have, so multiple users could create separate drafts and later one could be manually "promoted" to published, making it the new "live" data in the parent collection.

Such a workflow would also benefit from a new type of permission level, allowing users to create their own drafts but not publish or see other users' drafts. And then at a higher level you are able to see all users' drafts and choose whether to publish or delete them.

Also, concerning the funding discussion, I agree that when a company is actively using a product it is poor ethics to not sponsor it somehow, but some companies want features that they may already be relying on in some other legacy software before they start utilizing a new product to begin with. In such a case, it is a risky decision as a company to sponsor a product you haven't even started using yet, especially if you're just a startup. Just my two cents. That being said, I agree that the Directus team is doing a phenomenal job.

[LasseRosenow]

First of all I generally agree with @AaronBeaudoin with the exception as to that I see some issues with the gmail example.

For example in directus I would expect future revisions to also be possible to apply to something that has already been published. That of course makes no sense with emails. Once an email has been sent, it is sent. But if I have a blog post for example, it might at first be a draft, then it might get published at some point, BUT in the future it might get some changes that will be saved as future revisions and then be published by someone who has the permission to do so, as the author might just not have that power.

[rijkvanzanten]

To me, this is the main use case that makes this discussion both difficult and important:

[...] in the future it might get some changes that will be saved as future revisions and then be published by someone who has the permission to do so, [...]

[CalebBarnes]

One of the big blockers here is deciding between the two leading ways of storing future revisions... in the system revisions table, or in the parent itself. It's subjective, but figuring this out would really help push this along. Maybe a community poll on Twitter? 🤔

I think it would make the most sense stored as a revision that is not currently published. This is the same way WordPress stores "preview" revisions.

[ederuiter]

Sorry for the long post ..

But I always found it puzzling that most CMS'es only rely on a published/draft status per item, and don't have a concept similar to branching in git. With branching you would be able to easily stage multiple changes (say for example everything related to a new product launch, or a new marketing campaign), (p)review them together and publish (merge) them in 1 step.

I could only find 1 example of a cms that implements this fully: https://cloudcms.com
Graphcms has something that looks promising that they call environments: https://graphcms.com/blog/working-with-multiple-environments , but unfortunately that is basically a complete copy of the cms (incl assets) without a way to merge changes back.

What I would like to support is a workflow like this:

• user creates a new branch
• makes all the necessary changes => no production content is affected (even when changing status to published)
• he previews all the changes together (for example by settings the previewData cookie of your next app to the current branch: https://nextjs.org/docs/advanced-features/preview-mode)
• after he is finished he marks the branch as ready to be reviewed
• the reviewer can see all the changes (diffs) in the branch + can preview them
• the reviewer merges the branch to the main branch

I think I have an idea of how this can be implemented in directus. Please let me know if you think this a feasible approach (I plan on working on a POC for this in the next couple of weeks).

The way I think this could be implemented is by

• instead of storing the changes in revisions or in a separate table/collection, I propose to create a new item in the same collection
• this item would belong to this branch and also include the reference to the original item it is now replacing
• subsequent changes to the original item would update the already created replacement item
• to handle deletion, a new item is created which belongs to this branch + indicates it replaces the original item + has status Deleted
• to handle addition, a new item is created which belongs to this branch
• for retrieving the items of a collection; in case the main branch is selected only 1 extra filter is needed: branch=<main branch>
• In case another branch is selected it gets a bit more complicated:
  • only return the items which have branch=<main branch> that are not replaced in the current branch
  • only return the items which have branch=<current branch> that have status != Deleted
  • instead of just using the primary key to determine the id of the item we would have to query something COALESCE(<replaces item>, <primary key>)
  • and we probably want to set a flag on the item to indicate it has changes in this branch

This would have no issues with making changes to child items, as for the outside world the parent would still have the same id. So when you delete / add a child that is simply stored as new item in this branch and it's parent would still be the object belonging to the main branch.

^^ I have not tested this, and I am new to the directus codebase; however it seems doable to implement this in run-ast.ts as that seems to retrieve items per collection and does not use joins for related collections.

To make this a bit more clear consider the following example blog posts collection:

id	branch_id	branch_replaces	status	slug	title	body
1	null	null	Published	first	First post!	This is my first post!!
2	null	null	Draft	hello-world	Hello!	TODO: tbd
3	null	null	Draft	second	Uhm nothing to say	TODO: tbd

When I create a new branch and change the hello world post and remove the last post
The collection would look like this:

id	branch_id	branch_replaces	status	slug	title	body
1	null	null	Published	first	First post!	This is my first post!!
2	null	null	Draft	hello-world	Hello!	TODO: tbd
3	null	null	Draft	second	Uhm nothing to say	TODO: tbd
4	1	2	Published	hello-world	Hello!	World ..
5	1	3	Deleted	second	Uhm nothing to say	TODO: tbd

retrieving all items in this collection for the main branch is as simple as filtering on branch_id=NULL and would return a result like this:

id	branch_id	branch_replaces	status	slug	title	body
1	null	null	Published	first	First post!	This is my first post!!
2	null	null	Draft	hello-world	Hello!	TODO: tbd
3	null	null	Draft	second	Uhm nothing to say	TODO: tbd

retrieving all items in this collection for the new branch would return a result like this:

id	branch_id	branch_replaces	status	slug	title	body
1	null	null	Published	first	First post!	This is my first post!!
2	1	2	Published	hello-world	Hello!	World ..

[rijkvanzanten]

My idea for the api was to never include the branched items until you explicitly set the branch. Ideally for the client application nothing should change until you need data from a specific branch.

This is a bit too opinionated (/ Directus specific) if you ask me. It's a similar thing as the archive field. IMO the API should just return it as regular content, as it's mostly an app presentation thing. Extracting the "main" branch can easily be achieved with a ?filter[branch_id][_null]=true 🙂

[benhaynes]

Thanks, @ederuiter — really love the comprehensive follow-up. I agree with @rijkvanzanten, the main thing we need to avoid is being too opinionated. And while keeping everything in a user table is quite transparent and unopinionated... the background of supporting that will be pretty rigid and limiting.

Also, I know there is a middle ground of using a separate table for revisions, but this has the negative side effect of doubling the table count for full support, the complexity of keeping schemas in sync, and still has issues with unique/FK constraints.

Of course, I defer to Rijk on what is best for the platform, but I do think that Revisions offers a way to stage API calls to update items in the future, which feels clean since it's just a delayed version of what already happens in the App. That said, there are limitations to this approach, mostly because storing this as JSON limits our ability to filter, search, and order revision data.

Perhaps we could discuss extending Revisions to handle some of these limitations? That would at least give us a good starting point of options.

[ederuiter]

@benhaynes @rijkvanzanten What do you think about an approach like this:

• think of a way to make revision id's work like global snapshot identifiers (think git commit hash)
• create new api endpoints to retrieve the contents of items/collections at a specific point in time (revision id)

/snapshots/:revision/items/:collection
/snapshots/:revision/items/:collection/:id

• these endpoints would retrieve the items from the table and apply/revert revisions (in memory) based on difference between the given revision and the current state of the item.
• we can already test/implement this without implementing future revisions
• we probably want a way to diff two snapshots; this would yield a list of revisions

Some issues/challenges that I see with this approach:

• how to deal with deleted / added items
• how to deal with differences between data in the table, and in the revisions (eg: when you manually update a row in the database)
• how to handle sorting / filtering in collections
• for future revisions we still have potential issues with uniqueness (but with transactions we could probably easily deal with that)

[benhaynes]

Love it! We should make sure that route structure makes sense to @rijkvanzanten — it seems a bit backward to me, but maybe I'm missing something. Also, this is at the bounds of my technical knowledge, but two other ideas for potential Revision helper endpoints:

• Find an item revision state based on a datetime/timestamp, eg: Give me Collection:articles/Item:123 at this exact point in time
• Find an item revision state based on an index from the current main, eg: -3 to get three revisions ago, 2 or +2 to get two revisions in the future

Another thing for the "challenges" list is how to manage edits to relational data within the parent.

[ederuiter]

I was looking at how git works internally ( https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ). It is actually pretty straightforward; basically for every commit git stores the complete tree with references (hashes) to each file/directory

For example:

# git cat-file -p master^{tree}

100644 blob 625a7f797cadc88897778ba75a5933b79969febb    .env
100644 blob 9f11b755a17d8192c60f61cb17b8902dffbd9f23    .gitignore
120000 blob 370390311bf5e13d79e598a459bce8f983b98b7a    README.md
120000 blob f2abb30bd1842f1f71f23c9fe1ddc3330594a0c7    TODO.md
040000 tree bc810a9372b454d536b7b72a76f5067e3dbc29b0    auth
040000 tree 85d5ab29c2727e10516ba0a4138f71ea2a412941    db
100755 blob c6c4797302255fb9ddeb086fc2412632d0c5d6a8    docker-compose.yml
040000 tree f3e193d739087392ef0df9f657724022fe9a3ea3    frontend

This way for each commit you can reconstruct the complete tree by simply fetching all the objects referenced in the commit's tree object and recursing into the nested tree objects in there ..

I think that for directus we could do something very similar. Instead of commits we are talking about activity records, instead of blobs in the git tree we have revision objects.
The missing pieces are linking commits together and having a complete tree (=per collection a list of revisions) in a commit (=activity)

So if we are able to store/construct the complete list of revisions for a collection, from a commit (=activity), we could use SQL functions like json_extract (or json path expressions if supported) to reconstruct a complete table at that point in time and with that we would be able to use sql filtering / sorting ..

The main issue is see with this approach is how to store/compute the complete tree which each commit efficiently; but that seems like a solvable problem. The other thing is JSON support for each database engine .. but it seems the major database engines all support some variant of json_extract/json_value/json operators

• Find an item revision state based on a datetime/timestamp, eg: Give me Collection:articles/Item:123 at this exact point in time
• Find an item revision state based on an index from the current main, eg: -3 to get three revisions ago, 2 or +2 to get two revisions in the future

Yes, with this git alike approach we would be able to support things like that, and even branching/merging should be relatively easy to support (famous last words ..)

[CapitaineToinon]

Is there any official way to handle this problem right now? I'm looking for a modern replacement of a mediawiki site I'm currently taking care of and versioning it a must have and directus doesn't seem to have that. I'm really confused to see that directus and many other CMS such as strapi all seem to have this draft publish system that works as a boolean visibility switch, which is extremely bare bone.

[CapitaineToinon]

Yes I understand directus offers more than a simple visibility switch but even those more in depth options don't allow me to get the only thing I really want like explained by others in the messages above. I really loved using directus for all the others features that it have and it pains me I versioning is the only thing blocking me right now, that's all. I know this is a free and open source product so I'm not expecting you guys to just start writing huge features like because one dude told you so on github 👍

But what I'm hoping to get through those messages here is at least a viable workaround and you guys know the product the best. At this point I'm starting to think that CMS and Collaborative Wiki are simply two very different products and from what I can see browsing various solutions online, there are pretty much no solution that offers both out of the box.

Right now I'm leaning toward setting up two backends for a single frontend: one headless CMS such as directus for stuff like blog, news, homepage, about page, etc - one headless wiki such as mediawiki through the rest api for a full revision system and a frontend in nuxt for example to group everything but that seems like an awful lot of work.

Now I know directus can just plug to any existing database so maybe I could share a database between mediawiki and directus and use a single admin dashboard? Could directus be setup to become an oauth provider so I could login using directus on other websites? Thoughts?

To reiterate I think directus is great and maybe this whole future revision idea should be considered out of scope for this proejct?

✌️

[benhaynes]

All great feedback... and also, it's votes/comments like this that surface a feature and get us to work on it sooner. To be clear, this is something we want to do now... we're just super busy at the moment and this needs some serious forethought. If we can find a contributor that wants to help "lead" this, then we can dive in sooner. 👍

Could directus be setup to become an oauth provider so I could login using directus on other websites? Thoughts?

I defer to @rijkvanzanten on this one 😉

[magosis]

This seems like a really valuable feature. What level of sponsorship would a feature like this require to expedite?

[benhaynes]

You can chat with the team via our website's live chat to coordinate a proposal.

[endlessuniverse]

Hi. The best Wordpress plugin I tried that saves future revisions works like this: https://publishpress.com/knowledge-base/revisions-api/

[CapitaineToinon]

What about using xstate on the revision object? This would allow for future revision, draft, pending review or anything we want and I assume should work fairly well with the current system? If the state machine was configurable by the user, we could even imagine complex editorial workflows.

[rijkvanzanten]

That could work! Though I'm still curious how that would play with relational data through foreign keys. Well have to think through what should happen when a revision includes a new related object, or when a revision uses a related item that no longer exists

[CapitaineToinon]

For foreign keys, we could store the id in the data and delta.

type Revision = {
	activity: number;
	collection: string;
	item: string | number;
	data: null | Record<string, any>; // here the old id
	delta: null | Record<string, any>; // here the new id
}

That would mean you can't create a new item AND add that newly created item in a revision. The item would need to be created first, then added to through the revision. But that's no problem since the revision workflow would also be applied to the other foreign item (or not depending on the configuration).

If the foreign item gets deleted then yeah that's a problem but using xstate we could easily create a new invalid state where we would force the user to select a new foreign key! Let's imagine something like this:

import { createMachine } from "xstate";

interface Context {}

const fetchMachine = createMachine<Context>({
  id: "revision",
  initial: "draft",
  states: {
    draft: {
      // aka future revision
      on: {
        SUBMIT: "pending", // submit for someone with x role to review the changes
      },
    },
    pending: {
      // waiting for someone to review the changes
      // we could also imagine that if we're admin
      // then this state automatically goes to validating
      on: {
        ACCEPT: "validating", // changes look good, submit changes to the api
        REJECT: "draft", // ask for changes
      },
    },
    validating: {
      // now we check if the changes can be applied
      // aka if foreign keys still exists and maybe more?
      // if for example a foreign key doesn't exist anymore, we
      // invalidate the revision and ask the user to provide a new one
      on: {
        VALIDATED: "published",
        INVALIDATED: "draft",
      },
    },
    published: {
      // when we reach this state, that's when we actually update
      // the real item in the database and the revision enter its final
      // stage
      type: "final",
    },
  },
});

That way, we could could see that a foreign key changed and verify that it still exists only at the moment we try to modify the real item in the database. The current revision history would be all the revision in the published state. Every new change request would be a new revision. Some would be rejected and stay in draft forever, some would be published, some would be pending. But since we only update the real item on publish, I think this could work.

Of course, this implies quite a lof of changes on the UI side. When it comes to restoring an old revision, we could either create a new revision with the data and deltas of the old one, or we could image a the published state as not being final, like this:

    published: {
      // when we reach this state, that's when we actually update
      on: {
        RESTORE: 'draft'
      }
    }

And if we're trying to restore a foreign key that points to a item that has been deleted then that will prevent the validating state to proceed.

So the TL;DR for foreign keys I guess would be to simple not deal with them at all until we try to actually modify the real item.

It's also worth noting that the context of the state machine could be serialized and saved in the revision as well if we want to pass messages or data around.

Of course this is all hypothetical at this point since I've never messed around with the codebase myself.

[racquetmaster]

I appreciate the discussion on this feature. I also appreciate the desire to implement a high quality solution rather than rush to implement something that adds unnecessary complexity and/or only satisfies a subset of desired use cases.

That being said, I think it is a valuable feature worth the time, effort, and consideration. We are in the same situation as some of the others above. This is the only feature blocking us from implementing directus.

I don't know the inner workings of directus enough to comment on the internal architecture but I'll add my desires / opinions.

1. I'm all for keeping it simple. Unopinionated powerful simple underlying functionality makes great software.
2. Multiple environments / tables do require a lot of syncing complexity.
3. Our use case desires to have content that is draftable (and approvable) regardless of whether is an existing page. As stated above, a page would go through the following stages:
   A. Draft for an unpublished pages
   B. Published page
   C. Draft of a revision to the page.
   D. Published revision to the page.

All while allowing the ability to require elevated permissions for the transition from A->B and from C->D.

And I've up arrowed this feature as I hope everyone else has 😉

[benhaynes]

Really appreciate this thoughtful response. We're working on Core stability for a moment, but this is high on our list once we're out of a feature freeze. That is, unless this gets sponsored before then!

[kamil-malinski]

my simple solution for this problem:

• as soon as the status of an item changes from "published" to "draft" a hook stores the data of the item in a (hidden) field (json.stringify) of that item
• a read-hook returns the data from this field instead of the "live"-data from the item when the item is in this "draft"-status
• as soon as the status changes from "draft" to "published" again the real data of the item is being returned on read

I know that this idea is flawed and in some cases not possible (joins to those items still return the "live"-data) but it works in my use-case

[rijkvanzanten]

This is effectively how the current directus_revisions setup works. However, it gets really tricky once you start considering updates to (nested) relational data.

[sarashino]

Not yet implementing it tho; it would work fine imho to copy record from raw collection to released collection if the record's status become to released, and to do nothing with draft mode stuff.

[CapitaineToinon]

Do you guys think flows could be used to implement a workaround now?

[rijkvanzanten]

You could use it to automate some of these ideas, but I'm not sure if it would solve for all use cases, as there's no general consensus on how this should ideally work in the first place

[max-mayorov]

My excuses for reviving the old thread, but what's the status of this? We also need such functionality for preview/prod website...

[dmegatool]

HygraphCMS integration of this is pretty nifty. You can tag changes for a future release and then publish that release at a specific date. Best implementation I've seen so far.

PayloadCMS allow you to update the content and schedule it for a later date. The content status is marked as draft but the live version (published) is still being push to api queries. It's a little more basic than Hygraph but they're like the only 2 implementations I've seen of this feature.

[LasseRosenow]

I really like the "publish with a release" feature :o that is such a cool idea!

[rijkvanzanten]

You can tag changes for a future release

I'm really curious how those changes are stored though, that seems to be the big problem in this whole thread 🤔

[Dont-ask-for-it]

Same as @max-mayorov here and @racquetmaster here 🙋‍♂️This feature would add major value to the product. It is also mandotory for us to switch to Directus.

@benhaynes : Any update on the development or is there a roadmap for this? Do we know if some client already sponsered such a thing?

Thanks in advance!

[AaronBeaudoin]

@benhaynes, after 2 years, I'd also be interested to hear if there is any concrete plans for this feature. Looks like it is definitely one of the most requested features by upvotes, right behind calculated fields and the extension marketplace.

I agree with @Dont-ask-for-it that this is a key missing feature, especially for users hoping to use Directus for editorial/blog content. Although users can workaround this by implementing their own code to filter records, it isn't obvious, and it depends on custom logic in whatever platform will be consuming Directus content.

The tough thing about sponsorship regarding this feature is that it probably isn't really something that people already using Directus are going to sponsor, rather it's more likely a feature that people are waiting for in order to actual start using Directus to begin with. We've decided to get started with Directus anyways, but not everyone else will.

[benhaynes]

@Dont-ask-for-it @AaronBeaudoin — absolutely something on our radar and that we're looking to implement, however, it is a very broad and complex feature that needs to be handled correctly, and our engineering resources are spread thin at the moment. I would hope to break ground on this before the end of the year, but sponsoring would always speed that up. Also, it goes without saying, but we don't really give time estimates unless things are sponsored... so this is all just a shot in the dark. ❤️

[Crunchyman-ralph]

Do you guys have an idea of how this could be done ?

I would love to contribute to this project and I think this would be a great thing to do!

I'm currently freelancing for a big company and am probably going to be implementing this anyway (at least as an extension) so might as well just contribute to this repo

[JesperWe]

Lots of people looking for this capability makes it sound like a good sponsorship crowd sourcing item. Is it worth making this discussion an issue and putting it on Issuehunt with a stated $ goal to get development going?

[jonlambert]

Would def be interested in a sponsorship discussion. I've loved the Directus experience so far, but we're having to bail because of the lack of this feature 😞 We thought we could work around it by moving content at the DB level, but it's proving near impossible to maintain.

[domsen123]

just my 2 cents as a workaround:

• define a "primary" key => like path or something like that e.g /page/xyz
• define a "published_at" dateTime field
• define a "status" dropdown (published | draft)
• define fields to copy in collection option (select all but: published_at, status, id, updated_at, created_at etc)

got to last "published" content -> change published_at -> make changes to content -> upper right, 3 dots, save as copy...

API query: order by published_at desc and status _eq published, limit 1

Revert szenario: change last published to draft

Benefit: you will have revisions on each published content - and "version" history by the primary key /page/xyz

[geoHeil]

Can this be accomplished inside directus? Do you mean using the events feature?

[CalebBarnes]

Can this be accomplished inside directus? Do you mean using the events feature?

Yeah I think this can already be done. It seems like he is basically saying to just duplicate the item, keep the same key, but change the status and created date. In prod, you can get the most recently published item with the same key, and in preview/staging you can query the draft item with the same key.

[domsen123]

I'll share a Schema Screenshot the next days with you...

You can do this with flows or with a hook...

[kumsw]

Hi @domsen123
I'm looking into this work around as an option for our project. Do you have a copy of that Schema screenshot? It would be great to have a look.
Thanks

[JesperWe]

@rijkvanzanten in your recent e-mail "Hop in there" you link to the top upvoted feature requests from the last 30 days, making it look like those are more interesting to you than long standing issues like this one (which is not even visible in the resulting list) with more than an order of magnitude more upvotes.

This looks a bit worrying to me, as the communitys most requested features lose visibility.

[paescuj]

Thank you for your feedback, which I will gladly forward!
I think the idea in the newsletter was to focus on newer feature requests in order to give them a chance to be discovered by the community.
In this case I can reassure you, this feature request here is very much on our list. I think the fact that the request was opened by our CEO should underline this 😄

[rijkvanzanten]

@JesperWe Heyo! The main thinking was to make sure that A) people know feature requests exist, and B) make sure that people every now and again take a look past page 1!

making it look like those are more interesting to you than long standing issues like this one (which is not even visible in the resulting list)

This is absolutely not the case. The list that I shared was the top-3 feature requests opened in the last month, seeing it's a monthly newsletter 🙂 The ones that are interesting to me are these: https://github.com/directus/directus/discussions/categories/feature-requests?discussions_q=is:open+category:%22Feature+Requests%22+sort:top

[lluishi93]

This is much needed for sites that require constant changes and tests. Looking forward to it! Is there a way this can be sped up?

[MiniDigger]

the RFC sounds wonderful, only edge case that isnt mentioned is that what happens if you "merge" a "branch" that contains like a FK but that element has since been removed from the table.
in general, I guess merging needs to trigger all kinda validations again before going thru to the table to catch cases like this.

[rijkvanzanten]

the RFC sounds wonderful, only edge case that isnt mentioned is that what happens if you "merge" a "branch" that contains like a FK but that element has since been removed from the table. in general, I guess merging needs to trigger all kinda validations again before going thru to the table to catch cases like this.

I imagine that a "merge" effectively puts the staged changes on top of the "regular" edit form, and saves them as a regular update. That way, all the regular validations kick in as if you were just directly editing that item 🤔

[MiniDigger]

that sounds sane, yeah

[LasseRosenow]

The RFC is not available anymore, so I don't know about the current progress, but I want to reply to how I remember it to be:

How it is in the RFC (I think)

I think I remember it was supposed to have multiple branches to create various versions of a content item.
I think in general that is a cool feature and certainly has many use cases, but for example in my case I fear that this is too complicated for our users. So I wonder if it will be possible to configure this so it works more simple?

My idea

Our requirement would be to just have 2 branches. One called "published" and one called "future" for example.
If you open an item, you would usually be in the "future" branch, so changes that you make are not automatically published.
Maybe you as an editor should also not even have the permission to publish them.
But if you have the permission to publish them, it would be good to just have a very obvious publish button next to the save button for example.

I think this workflow would be very good for our users to prevent them to accidentally make changes, that should not be published etc. but it would also be very transparent and easy to understand for them, that this change is not yet published, because there is a large publish button next to the save button.

What do you think about this?

[rijkvanzanten]

@w0kyj mind posting the most up to date one? 🙂

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[w0kyj]

Summary

Allow items to be changed, but not committed to the database yet. This allows editors to make and save changes, but not have those changes published yet. This unlocks more content-specific editing workflows.

Basic example

When changes on an item are made, these changes can be “soft-saved” to a new “branch”, which then allows the editor to continue working on the changes in the item, without committing to saving (”publishing”) the item to the database yet.

Motivation

This allows content teams to enrich their workflows by allowing editors to make and preview changes, without publishing them yet. Without allowing saving future revisions, there’s currently no good way to achieve a similar workflow. The closest workaround is setting up a duplicate table with a flow or custom hook that will keep content in sync from one table to another, but this is non-trivial to achieve for such a common use case.

Detailed design

App Usability

On the item detail page, users will be able to create a new “Branch” from the current item. When you switch from the “Main” branch to a new branch changes made will be saved to directus_revisions rather than the actual table. This means users can make changes, and keep updating those changes over time, without committing to saving the changes to the database. When the user switches between branches, the current item will be loaded in from the actual table (the published item), and the saved changes will be applied. This system is very similar to the current way “Revert” works from Revisions. When the published item is changed while working on a branch revision, we show the user a warning and (if need be) a confirmation to choose whether to keep the changes made, or use the value saved to the database.

When a user is ready to commit the item to the main branch, and the user has permissions to update the main branch, a secondary save action will allow the user to preview all the changes that will be applied to the main branch, and commit the changes to the main branch.

API Previewing

In order to enable previewing of edits in a branch, a new query parameter or endpoint will be designed that allows the user to pull in a given revision for an item.

Requirements List

Must haves:

• User can create new branches with a custom name
• User can switch branches at will
• User can rename an existing branch
• User can delete a branch
• Permissions can be configured for who is allowed to created “branches”
• Staged changes are saved to Revisions when in a branch that’s not the “main” branch
• Revisions saved to a branch can be “previewed” through the API
• User gets notified when changes happened on the “main” branch since they started their branch

Should haves:

• Allow the user to choose if they wanna keep their changes, or use the changes in the “main” update (field-by-field)

Could haves:

• Comparison “merge” UI that shows all changes and allows final editor to save the changes
• An ability to leave a “commit message” on saves
• Additional UI to compare various revisions (explore branches/revisions)
• The ability to mark a revision in a branch as “ready for review”
• Show comments made on current branch
• Flow operation to “advance” revision to published
• Limit/Control the number of revisions allowed

Will not have (at this time):

• Multi-user collaborative editing

Drawbacks

Comments and Shares might have to be adjusted to be branch-specific.

Alternatives

Instead of saving just the delta to Directus Revisions, a secondary “cloned” table could be considered, however there’s some downsides to that approach:

1. It would destroy the usage of unique constraints and foreign keys
   Seeing we would have to make a full copy of the table in order to allow people to make multiple copies of the item, it would mean that one to many relationships and unique constraints would be impossible
2. Tracking nested changes to relationships would entail also having duplicate tables for any of the related items down the whole tree, which in turn means you can end up with a copy of the whole database, just to keep track of branched changes for a single table

Adoption strategy

This would be an opt-in additional feature; there’s no breaking changes or migration path necessary.

Unresolved questions

• If you don’t have update permissions to the actual item, how do you control what fields can be edited as part of a branch:

  • Permissions for directus_branches controls who can do what to branches
  • Permissions for branches can be controlled on either the Branches row under System, or from the collection row (which is aggregated to the Branches permissions row)
  • Two new permissions “actions” will be added: merge and commit
  • Merge
    • The merge permissions will control when the data on a branch is allowed to be merged, and who is allowed to do this merge action
    • Merging is effectively acting like an Upsert. When the branch is updating an existing item, the commit changes are applied to the existing item, otherwise a new item is created
  • Commit
    • A commit controls what data is allowed to be saved to a specific commit
    • For the MVP, the only permission that is configured is the fields that can be edited in a commit
  • • Branching: Enable / Disable
    • Create Branches -> Saves to directus_branches
    • Read Branches -> Saves to directus_branches
    • Update Branches -> Saves to directus_branches
    • Control Commits (fields you can work with) -> Saves to [[collection]] COMMIT permissions
    • Merge Commits -> Saves to [[collection]] MERGE permissions
    • Delete Branches -> Saves to directus_branches

  Bulk Commit/Releases

  Allow users to create a “Release” that will have multiple items from one or more collections bundled. When committing a “Release” all associated “Branch” items would be applied.

  Project Release/Branch Features

  Should the same branching / revision logic be available for schema / settings?

  • Data Model Changes
    • Include the ability to add new field(s) to a collection as a “Branch”
      • New/Update item “Branch” would allow option to include new data model branch
      • Delete a data model “Branch” options:
        • Cascade delete item branch
        • Remove/Null in the item branch
  • Flows
  • Roles/Permissions
  • Project Level:
    • Env Configs
    • Project Settings
    • Presets & Bookmarks
    • etc

[LasseRosenow]

Thank you for the updated RFC :)
I have updated my previously asked questions as a feature request to this RFC.

Important: I don't want to change anything regarding the main concept. I think it is really good.
I only ask for additional configuration options to enable more simple use cases with less overhead.

Use Case

The design with multiple branches certainly has many good use cases, but I think more simple use cases should also not be forgotten. That is why I propose not to change the RFC and make it less complex, but rather to introduce additional configuration options for this.

• Our requirement would be to just have 2 branches. One called published and one called draft for example.
• If you open an item, you would usually be in the draft branch, so changes that you make are not automatically published.
• It would be good to just have a very obvious publish button next to the save button for example.

I think this workflow would be very good for our users to prevent them to accidentally make changes, that should not be published etc. but it would also be very transparent and easy to understand for them, that this change is not yet published, because there is a large publish button next to the save button.

My main concern with the current design is, that it is too complex for many users and would end up not being used by them.

Proposed Solution

• Add a very obvious publish button on branches that are not main. (Next to the save button?)
• Add the ability to configure the default branch that is selected for a collection.
• (optional) disable the ability for every user (including admin) to create or delete branches => To prevent accidentally destroying the 2 branch configuration outside of the data model settings page
• (optional) make this configurable via ENV variables, This way all my collections in all my projects could automatically have a draft default branch and I could always rely on this workflow without needing to configure it for every collection every time :)

=> This way I could create a draft branch for all my collections and set it as the default branch. Now every user would just edit the draft branch and click the publish button to publish the changes.

What do you think about this?

[rafaeldsousa]

@w0kyj From the perspective of many other CMSs that have draft/revision ability, everything @LasseRosenow said makes a lot of sense and sounds a lot more simple for users/CMS editors to understand.

[w0kyj]

Really appreciate the thought and details here. Excellent suggestions and we'll continue to enhance this feature in the coming months. If these don't make the first release, we will add enhancement requests to augment the capabilities in later releases :)

[JesperWe]

I see no mention above of the ability to set a publish date (or should I say "scheduled merge" 😄) for a branch?
This is a pretty standard feature of publishing systems with in the type of workflow proposed by @LasseRosenow above...

[w0kyj]

I think the best solution for this to maintain unopinionated flexibility would be to use Flows for this. Administrators can then provide manual, cron or data change triggers to implement publishing of content.

[JayShoe]

Would branches site-wide (all or nothing) or content item only?

For example, which would be the organization method for the branches and the "commit" system?

Branch 1
 - modified content 1
 - modified content 2
 - modified content 3

OR

Content 1
 - branch 1
 - branch 2

The usefulness of either would depend on the scope of the updates. If you want to update multiple content items at one time having a site-wide "release everything at once" branch would be best. If you want to update just a single content item at a time, then the content/branch method would be best.

If a marketer wants to go in and modify 4 pages all at once with a new rebranded logo or product name, having a site-wide branch would work nicely. If a marketer wants to just create a simple change on a specific page, then a content-specific branch would be nicer.

Branch tags might be a way to sub categorize branches. Using tags you can commit "anything in this branch with tag xyz" or "just this content item inside this branch".

Branch Tags?

Branch tags might be very useful in general. You could have tags such as "revisions" or "a/b tests", tags (for example). This will help the moderators to know which branch was made for what purpose and to allow scripts to find tests by looking for branches with matching tags. If branches are setup in the Systems Collections content model folder, the site builder should be able to add fields manually - directus style. Or tags could be baked into the feature.

A/B Testing Revisions via Branches!!!

This revision feature would also be an excellent tool for doing A/B Testing... The system would display revision X and revision Y and record/report the results (page1?branch=A vs page1?branch=B). I believe a content-specific analysis would be helpful here, but to create a bunch of branches for each content item you want to A/B test would potentially be very cumbersome (BranchA1, BranchB1, BranchA2, BranchB2, etc...). A site-wide A and B branch with the ability to focus your analysis on individual content items might be easier for the content moderator to handle. I recognize this is outside of the scope of the "future-revisions" system in general - but it is exciting to consider.

[rijkvanzanten]

Would branches site-wide (all or nothing) or content item only?

The way we're currently implementing it is per-content-item, though that being said, it shouldn't be too crazy to add a flow or even core-feature down the line to visualize and allow you to merge all branches that match by name or (to your second great idea) tag!

[NigmaX]

Is it possible to have the new branch switched to the main one? ("set as main" button)
That way, there's going to be a history of all versions that we can refer to or go back to.

[paescuj]

That's correct! It creates a single revision event at the moment, meaning the exact history of versions from a branch would be lost when the branch is merged and then deleted. But we're exploring different possibilities here which would help to keep the history 👍

[NigmaX]

Thanks!

[JayShoe]

Wouldn't the standard revisions function still work though? Once you merge in a change to the content, I presume the revisions system will create a new revision.

[paescuj]

Wouldn't the standard revisions function still work though? Once you merge in a change to the content, I presume the revisions system will create a new revision.

Yes, that works! And you can "revert" the merge as every other revision. It's just that the individual revisions made inside a branch are lost once the branch is merged and deleted.
If I understood it correctly, @NigmaX was wondering whether there would be a possibility to have those individual revisions applied to the main branch when merging so it wouldn't be lost even if the branch would be deleted.

[NigmaX]

@JayShoe @paescuj, the standard revision is kind of useless for us, as it doesn't support relations, so if we would like to go back, it will change only the stuff that usually doesn't change (as we change most of the time items on a specific collection and not the static fields).

[bartosjiri]

Appreciate all the discussion and proposals in here!

I've been looking for a lightweight alternative CMS to wikis and similar knowledgebase systems and Directus with this feature could possibly be the best option (I can provide a full list of my requirements if desired). Please let me share the following use case:

Base role users are able to log in the Directus and view existing content. They can choose to provide updates to it or create new content. All such changes then get into "pending review" or similar status. During this, the previous original version of the content is still available, while the updated version has to be first approved by other users with relevant role(s). Once approved, the updated content is merged as new current version.

From my understanding of everything in here and in the blog post, this could be feasible with some extra work. The main concern, as also discussed in the related Discord channel, is the understanding of the merge concept to non-tech people and UX in general (see jesperwe's message). Are there any other obstacles that I am missing? Did anyone consider any similar use case? Thanks!

[rijkvanzanten]

This has been released in 10.7! 🥳