Is there a call that could be made to the API to retrieve a list of changes made from a given date?
When changes are made to Aristotle, are these deltas sent to a queue of some sort that can be accessed?
I really would like a simple way of integrating Aristotle with other tools making use of metadata definitions. When something of interest is updated, I’d like a way of finding out without needing to interrogate the entire content of Aristotle and sorting out the wheat from the chaff.
So it takes an extra query to know that it was a distribution that was modified. Now that I know the UUID and the entity type (distribution), I can follow up with an additional query to find out what it looks like now and refresh any mirrors I might have set up. Actually, I can probably just widen the graphQL query above and hopefully get the information I need anyway in one go.
I’ll run with this and see what I can get out of it, thanks again.
Looking at the name of the queue, I guess it’s obvious, but I hadn’t realised that this queue only displays the latest change to a record.
So what if I have a case when a record changed radically a couple days ago by User A (let’s say someone wiped out a few hundred permissible values, when they should not have). Today, someone different, User B, makes a minor innocent change. Now I notice all those missing permissible values… I consult the log at metadata_info/latest_action/… and think the problem occurred when User B made a change, since the older log of User A’s change has been removed.
Is this how it currently works?
If so, then I suppose what I can gather from this list is that from a given date of interest, the metadata UUID I see listed has changed at least once, and an unknown number of times before that.
Yup - exactly! In essence, this endpoint is broadly designed to answer the question “What metadata has changed since I last checked the registry?”
The reason it doesn’t return a list of changes is that there are different permissions that can be applied to each individual change to an item, which a user may not be able to see. So a user may be able to see an item, but may not have permission to see who changed it and how - in fact, this is the default behaviour, and when items are published users by default cannot see any version histories that show how the item was changed.
This endpoint is designed to assist with federation between systems, and lets a system interrogate an Aristotle Metadata Registry to determine that changes have occurred to metadata they need to be aware of, but won’t return exact what changes have been made, so that it can update its own content.
In an upcoming release, we are also going to be including deletion policies, to allow administrators to set permissions around the deletion of content.
The approach described above means that the /latest_action/ endpoint can also be used to inform users that content has been deleted within the specified time frame as well, so that the other system can remove the content as required.