There has been a lot of work recently on the historical data of things. (Automations and views activity).
The problem is that this list shows the changes, and you can see details of each change, but it is very difficult to see what the state of the object actually was at any given point in time.
The only place which has this properly is rich text field activity. And this is being merged into the entity activity log, so I hope it will not lose this.
Ideally you can look at any history point for any object and see the full picture of that object in that point in time, as well as an indication of what changed (highlighted) on that change. Then restoring is more clearly restoring that point in time, and not the field changes made in that change.
This is relevant for entities, buttons, automations, validations, views, and anything else which has an “activity” list now.
Another thought:
Maybe even showing the old fields that existed in that point in time, but not 100% sure about that. IE, if a field existed and the schema changed, still show that field in the entity history as it may help tell the story of the history of this entity. Again, not 100% sure, since “restoring” that entity would then in fact not restore the missing field, so it may be confusing or impossible from a tech standpoint.
I think this is very technically challenging unfortunately.
If you imagine the history as a stream of events, then restoring the state of an entity at some point in its history is akin to reverting all events the current time and between that point in time.
But some of how an entity looked is also determined by other related entities, so you need to not only rewind all the changes to this entity’s field values, but also rewind all changes to any other entities whose values could in any way have affected this entity (plus any entities which could have affected those entities in ways which would have affected how they affected the entity, plus any entities which could affect those entities… and so on!!!)
And if the schema has changed, you would also need to unravel all those changes.
Overall, the calculations needed to answer “what was the state of this entity at a given point in time” would be pretty complicated.
Furthermore, you would probably need to deal with the case where the person asking the question does not have rights to see every entity in the workspace (and their histories). It would require backwards-traversing the history with another layer of complexity (“Is this user allowed to see/know this entity?”)
Oof! I completely forgot about how access control would play a role in this. Right now when you get access to an entity, do you get access to all the history or said entity? Or only history since the point you get access?
I would say: show the snapshot of the entity with the user’s current access, not past access. So if it was related to something else and they had access to that in the past and now they don’t, it should show “Private [item]”. This feature is not asking for workspace level snapshots, only single item snapshots.
Indeed the schema changes would complicate things. Not sure how this would be approached.
Even though complex, I do think entity versioning would be nice to have in the future. Whether that’s an engine which calculates changes, or something which snapshots every change made.
It sounds like doing this on the entity would be most difficult, but I think it would be also very valuable to do this on views and automations. This would be a bit simpler I think.
Rich text fields have version controls, so I’m curious how those are implemented.
Personally I have been struggling with the AI generated descriptions of the changes made to elements. It’s not intuitive to understand what changed.
Well, this is what Fibery does - it retains a record every change
But this is not the same thing as snapshotting the workspace after every change, which I guess is what you mean by this:
Given that a workspace export can be 10’s or evern 100’s of GB in size, genuinely snapshotting after each change would be practically impossible.
There may be some clever way of snapshotting once, and then storing only the necessary delta, each time a change is made, in order to save space, but then there is still the challenge of reconstructing the workspace at a point in time (which would mean restoring the most recent complete snapshot, and then re-playing all the delta changes between then and the point in time you wish to restore to).
TLDR, I think it is more likely that individual granular elements of ‘restore’ will be implemented, e.g. restore view settings, restore automation configuration, but I think snapshot restore of entities is unlikely to be delivered any time soon
(but then again, I am always impressed by what our devs can manage, so never say ‘never’)
Just to make it clear for this requirest. This is not asking for workspace snapshots. It is asking for single element snapshots (entity, view, rule, etc.).
If you had one, maybe the other would be easier, but this post is not about “show me the entire workspace as it looked 2 months ago”. It’s “Show this one thing, as it looked 2 months ago”.
There’s overlap, but just want to make that clear.
The reason thats relevant is because it can be impliemented in small parts: automation versioning, view versioning, and only then, once the person in charge of permissions is finished and wants to take on the next big assignment, entity versioning
I did get that, but my point was that in the case where ‘element = entity’ it is not possible to restore the state of a single entity in isolation; it’s difficult to determine what other entities might have affected it at that time (and how) if you haven’t also snapshotted/restored those other entities too.
Most histories only track changes and build up a representation via applying each instruction in sequence. Imagine the bloat if a photo editing suite saved a temp copy after each adjustment.
Arguably, you could build any snapshot of the document on-the-fly by taking the list of changes and applying the reverse of them over the latest version.
I understand the use case here, but the counterargument is it’s quite easy to use immutable entities to track history and date stamp the markdown files.
I might be going on a tangent here, and also it’s not particularly useful to implement something like below against every markdown field, but I think it’s worth my two cents.
Create an exact copy, make changes, publish. Link the new record with the old to see the chain of changes, and write automations to revert to previous versions. This is how many document version control software tools operate.
Interestingly, as a side effect, it may also allow for a more granular access model:
Copies are always “local” drafts attached to the user, so they won’t appear until published, avoiding cases where other users may encounter files as they are being edited in real-time.
You can whitelist users or groups at the document level, while having a completely different whitelist at the containing entity level.
Users won’t be able to delete past versions accidentally (or maliciously).
Simultaneous editing can be removed (sometimes it’s better this way), but multiple distinct drafts can exist concurrently.
The latest published version can rise to the top, and the previous revisions can be hidden or greyed-out, based on access levels.
Custom app wrappers can allow side-by-side comparisons of revisions (if you feel like coding it, or trust the AI agent to get it right…) like how WinMerge does.
The sky is the limit, if you have the time and patience.
Would it be worth it to only include non-relation/lookup fields in order to remove the overhead from far reaching operations? Or would this cut out too much necessary information from the snapshot?
Formulas which result in primitive fields are owned by the entity itself, not by any related entities. Hence it should show the data of the formula at the time on the snapshot, unrelated to related things.
From my understanding of how Fibery formulas work.
But the point is, the value output of the formula may depend on the field values of related items. If you want to show/restore the value at the time of the snapshot, we either need to store every formula field value at every point in an entity’s history, or we need to store the field values of every affecting related entity. Either way, it makes snapshotting a PITA.
Also, what happens if the formula itself has changed?
I believe this is already being done, in the same way as primitive fields. If you look at the activity log of an entity, show all sources, it shows all changes made and the change done by the formula engine.
Then it shows the value of the formula at that time in any case. If it could show the formula itself at the time as well that would be nice too, but I think that’s less needed. That would work the same as Historical reports. If the formula itself changes, the historical report simple shows that as a change of value, nothing about the change in formula, as far as I know.
Well, maybe you’re both right, and it’s not as complicated as I fear, but I can at least say that it’s not something on our short term radar unfortunately
(and I suppose seeing the state of an entity back in time is already partly possible via historical reports; it’s the restoring bit that’s tricky)
I think we are focused on entity in this discussion, but what sparked this idea for me is the work happening in the others, and the “View Details” AI overview which has been quite difficult to work with to properly understand the version I am reverting to.
I think also there needs to be a distinction in the feature request regarding whether the need is to see the state of an ‘item’ (entity, rule, view, etc.) at some point in its lifetime, or to be able to restore the 'item ’ to that state. In some cases, the former might be significantly easier than the latter, and in other cases, less so. Perhaps @RonMakesSystems you want to break out this request into multiple distinct requests (per item and per need) for the cases where it is not already possible
(note: i haven’t searched the forum for existing ‘narrow’ requests)
