DataObject Versioned - History tab

General
#1

Hi,
I use DataObject + Versioned.
I want to have History tab, like in Page.
How can i create it?

#2

@DarthVader Can you elaborate your question further?
If you have versioned module (silverstripe/versioned-admin), once you create a page, the history tab will be created by default. Please have a look at this module (GitHub - silverstripe/silverstripe-versioned-admin) for further info.

#3

I have this question too.

I have a need to use the history viewer for a dataobject, not a Page in the admin UI.

The docs aren’t very helpful of how to do this.

The DataObject has the Versioned::class extension and I’ve added a HistoryViewerField field.

What else do I need to do?

1 Like
#4

There are a lot of sub-headings under the ‘Using the history viewer’ heading :wink: it looks very complicated to be honest, which is surprising. There were a couple of modules that made this easy in SS3 but I can’t find an equivalent for SS4.

#5

So I’m understanding… We’re expected to implement all of that for every data object that has a history viewer?!
It looks insanely complicated.

What is the point of versioning data objects if no admin user can see/use the versions.

1 Like
#6

That’s my takeaway :grimacing: and yeah I agree it seems crazy to have to create that much custom code and add a build step just to use the History Viewer. I can’t imagine many devs going to that effort unless it’s totally critical. I added a note about this here.

#7

Thanks for that, I’m following that discussion and saw your post. Good points. This field in particular does seem totally divorced from the general field pattern. It’s not a trivial field…

The idea here was a primary data object and related data objects with versioning over all of them.

I was keen to split them up to keep some kind of normal form/separation but it looks like I’m stuck in the land of flat file cms

They why:
I have a members area of a site where members can manage their data. When doing so it goes in to a modified state and admins get a notification to check it. If it checks out, they flick a switch and publish it to the site and up to HubSpot.

The data currently is never displayed on the site and SiteTree can already be a performance hand brake so didn’t want to muddy that.

I guess making these a sub page of a page hidden from Menu is the best bet here?

#8

Sounds like you probably don’t need to see the full history of changes, but just compare the current draft with the last published. You could look in to compareVersions and produce a summary of the differences to show in your email notification as well as maybe a LiteralField in the CMS.

#9

That may well work for this scenario, cheers.

compareVersions is a bit confusing. It takes strings then uses them in Versioned::get_version as Int’s. Assuming compareVersions is after two version ID’s.

Probably OT but do you have any pointers for how to get the latest version of a versioned record regardless of stage? I could get both and compare their LastEdited values, figured SS might have a cleverer way. I see Versioned::stagesDiffer() but doesn’t say which is ahead.

Edit.
I used a mix of:

if ( ! $Record->latestPublished())
{
    # Current record has been superseded by draft changes. Use Draft data.
    $Record = Versioned::get_by_stage('SomeClass', 'Stage')->byID($Record->ID);
}
#10

do you have any pointers for how to get the latest version of a versioned record regardless of stage

AFAIK the draft stage should always be the latest because when you publish, it just copies whatever is on draft to live. So the published stage is either behind or even with draft. So I think you could just get from the draft stage every time in that scenario.

#11

I found this simple history viewer for dataobjects in modeladmin/gridfields that has done the trick for me GitHub - gorriecoe/silverstripe-dataobjecthistory