V8-archive: Add revision to /items endpoint

[NicoBijl]

Feature Request

Please add the ability to retrieve the revision_id when retrieving a list of items,

What problem does this feature solve?

Main problem: We are building an app that ask the user some questions. These questions are stored in directus. When storing the answer, we want to store not just a reference to the question, but to the actual revision so we can trace which version of the question was asked.

Another problem we have (but I might need to create a new ticket for that) is the way to 'stage' changes without publishing it. For example; we have a question that is published, but we want to rephrase it. Then we change the status to draft, make the changes. (during this time we want the API to return the lastest published question). Then we publish the updated question (and the API will return this latest version)

How do you think this should be implemented?

Add a new Query Param to Get Items endpoint called "revision". When this query param is present, add the join to the code to retrieve the latest revision id and add it to the response body as attribute 'revision.id'.

Another implementation would be to just add it to the response body, and use the already existing 'fields' query param to retrieve it.

Would you be willing to work on this?

Sure, but this would be my first work on the directus project so it would probably take me a bit more time then someone else.

[benhaynes]

Thanks @NicoBijl — I really like this idea, and would love to see a deeper set of features regarding revisions. As for your second point, does this existing feature request I made seen accurate?

https://github.com/directus/app/issues/762

[benhaynes]

To achieve better clarity/visibility, we are now tracking feature requests within the Feature Request project board.

This issue being closed does not mean it's not being considered.

[NicoBijl]

Hi @benhaynes
How do we continue? Would you be able to build this yourself?
About the second problem, the existing feature request indeed matches my ideas on how to solve it.
Closing this issue kinda looks like it is done, but it is not right? Should it not just stay open.. and on the feature request project board?

[shealavington]

@NicoBijl , Keeping it open makes it more difficult to go through actual issues compared to feature requests, therefore requests for features are closed and added to a special feature board.

Currently, there are 14 issues open, meanwhile, there are over 100 Proposed and Accepted feature requests, trying to find those 14 issues would be more difficult if we said we had 114 issues, and would also look like Directus has MANY more issues than it may have to newcomers.

[benhaynes]

I voted (👍) for the feature, and which enhancements we (the Core Dev Team) work on next is based on that... so you and anyone else should vote! We can't keep all feature requests open or we would have hundreds of open tickets and not be able to properly see bugs.

[NicoBijl]

Cool, i want to start working on it, do you have a preference for the way to solve it?

1. add a new query param 'revision' to enable the retrieval of the revision number.
2. Use the existing 'fields' query param to add the revision number (or object??)

[benhaynes]

This would be metadata, so we would need a revision flag (off by default) added here:

https://docs.directus.io/api/reference.html#metadata

I don't know where/how this is added technically, but @directus/api-team might be able to give some pointers.

[rijkvanzanten]

Like @benhaynes mentioned, I think we should go with a meta field to return this data:

&meta=revision

{
  "meta": {
    "revision": 15
  },
  "data": {
    "id": 45,
    "question": "Question 1?"
  }
}

---

The one downside with this approach is that it doesn't play nicely with _multiple_ items.

[rijkvanzanten]

@benhaynes This might also be solved by support for multi-collection relationships:

between questions and directus_revisions. questions would have the alias one side which points to a compound many on directus_revisions.collection and directus_revisions.item. That way, you can return the revision as a nested field in the actual item, also delivering support for multiple items at the same time.

[benhaynes]

If requested, would we want to return just the revision id, or all of the revision info (eg: data delta, and/or parent)? Also, would we want to include the activity info (eg: created on, or have that as a separate flag?

[rijkvanzanten]

All of this would be taken care of by the fields parameter if we have the compound one-to-X 🤔

[benhaynes]

Very true. This would be more work for the developer (if they need it on a lot of collections) but should work. If we added something to metadata it would just be a "helper" I guess.

[rijkvanzanten]

If we added something to metadata it would just be a "helper" I guess.

The problem with the metadata route is that we can't return the revision info _per item_. We don't / won't inject meta info _inside_ the items themselves, so best case scenario we end up with an array that matches the items by index:

  revision: [15, 32, 61]

data: [{ id: 5 }, { id: 15 }, { id: 26 }]

[benhaynes]

Right, or it's only available on GetItem. OK, let's plan on using the relational field option for now since that solves the problem better than metadata.

[rijkvanzanten]

Right, or it's only available on GetItem.

Yeah, but that won't resolve the original feature request 🙂

Add revision to /items endpoint

[NicoBijl]

Uhhhh Why is this now a wontfix?

I already started looking into running the API locally to develop this (and then create a merge request).

[NicoBijl]

Ah I see, I can use the relational field solution. Who can help me how to set that up?
Do is still need to dev something to use this or is it just a case of configuring the relationship between the two?
If it is just config, what kind of relationship should I use? I just tried one too many and many to many but get errors on both..

Edit:
is this what is called the many-too-any relation? https://docs.directus.io/guides/relationships.html#many-to-any

Edit 2:
I added a one too many relation (on just the revision.item attribute, so it's showing to much info) and now I can get the revisions like this:
http://cms.test.services.quo.md/api/_/items/question?fields=*,revision.id
But I only really need the latest revision, not all of them... and the performance is an issue when I add the revision..

GET items/question?fields=*,revision.id takes ~7300ms
while GET items/question?fields=* takes ~100ms

Any ideas on just retrieving the id of the most recent revision?

[benhaynes]

You can try to get info here, on StackOverflow, or our Slack:

https://directus.chat