Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return the history of actions on a given resource #4788

Open
imsdu opened this issue Mar 7, 2024 · 2 comments
Open

Return the history of actions on a given resource #4788

imsdu opened this issue Mar 7, 2024 · 2 comments

Comments

@imsdu
Copy link
Contributor

imsdu commented Mar 7, 2024

Motivation
For a client, it is currently not possible to have an clear idea of the different actions applied to a resource during its lifetime.

Acceptance criteria

  1. The user must have access to the resource
  2. The events are returned in chronological order
  3. No pagination is applied
  4. For each event, we return the action, the timestamp of the event and the author

Implementation notes
This endpoint must rely on the events metric index so an Elasticsearch query must be written.
The implementation must be in the Elasticsearch plugin as this is where the ES dependency is at the moment
The api endpoint can be:
/resources/org/project/_/[resource_id]/history
(_ being the schema and is not relevant here)
And would be implemented in ElasticSearchQueryRoutes along the listing operation

@ssssarah
Copy link

ssssarah commented Mar 12, 2024

  • Would each event be tied to a revision number?
  • I wonder how much visibility/action we would have on querying based on time. ex: from/to filters with date input or rev input.

I'm thinking of the following use case:
Knowing the differences between the same resource between a version at time x and the version at time y.

The process would be to

Another option would be to extend the proposal of #4787 to add comparison based on time?

@imsdu
Copy link
Contributor Author

imsdu commented Mar 12, 2024

  • Every event is tied to a revision number internally
  • It can be a good idea. However this is only the Delta endpoint in this ticket, I preferred to keep it simple waiting for the Fusion ticket. Depending on this second ticket, we will see if we want filters which would be applied on the frontend side or something to include in the endpoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants