Phonograph has the “getObjectTypeEvents” endpoint (“storage/edits/events/objecttypes/”) that allows you to see all actions on the specific object type. This includes creations, edits and deletions for all objects of that object type.
Is there an equivalent endpoint for the Object Storage v2?
There is a way to enable edits history tracking for OSv2, see https://www.palantir.com/docs/foundry/object-edits/user-edit-history. Due to architectural optimizations, OSv2 doesn’t always track history which means history will only be tracked after the setting is enabled (and any prior history is not captured).
The history log can then be viewed via the Edits History widget in Workshop (https://www.palantir.com/docs/foundry/workshop/widgets-edits-history).
While we don’t have a publicly documented API at the moment to read the history, you can look at the requests made by the workshop widget for OSv2 object types to use the respective new endpoints.
I’m not 100% certain I’m thinking of the same thing - but are you talking about having a datasets/table where you can see a history of all the edits on a particular object type? e.g. a collection of what you see in the ‘Edit History’ widget in an object view?
If that’s what you’re asking, then yes, that’s something I’d also like to see.
At the moment we don’t have support for a global edit log for an entire object type in OSv2 (it’s limited to the query pattern of loading edits for individual objects), but we would like to expose the global history as a dataset to users in the future (I have added this thread to our internally tracked feature request).
We omitted this feature from the initial implementation because of the complexity of the permission system, especially for object types involving restricted views and for multi-datasource object types.
Hoping to provide further updates on this throughout next year!
The Action Log objects are ok, but only record what went into an action, and not what actually changed on an object, and if you have an edit via a function that’s not a direct input to an Action (or derived from multiple inputs), that change isn’t visible in the Action Log.
(Oh, and that of course the schemas for the Action logs are Action dependent, so unioning them isn’t trivial.)
But in understand it’s tricky with the permissons.