Ivan,
Thanks for the reply. I'm not sure what you are referring to as the "alert" in your message. I need to be able to modify the way sitefinity processes a rollback. My client cannot allow revisions of content to be completely deleted, as is done in the current rollback process.
It seems like it should be fairly straight-forward to create a new version of the content, copying the version that the user want's to roll-back to. Based on the (very limited) API documentation for the VersionManager, I tried this:
| VersionManager versionManager = new VersionManager(); |
| IVersionItem rollbackVersionItem = versionManager.GetItem(ContentItem.ID, null, version); |
| IVersionItem newVersionItem = versionManager.CreateItem(ContentID, rollbackVersionItem.Culture, rollbackVersionItem.Data); |
| |
| versionManager.SaveItem(newVersionItem); |
| versionManager.CommitChanges(ContentItem.ID, null); |
| |
I could see a new version being created in the database (in the sf_VersionItem and sf_VrsTxtData tables), but when I call CommitChanges, the new records disappear. If I do *not* call CommitChanges, then the records remain, but they are in a locked state.
What I thought would be a simple override of the current versioning provider is proving to be frustrating. The advantage to exposing APIs and using providers is that they can be used to extend functionality, but I am finding that the documentation for how to use the API a bit lacking (or worse, incorrect). I admit that I may trying to use the API incorrectly, but that's the point of my frustration - there is no help that I can find that describes how to use it.
Thanks for any help!
Regards,
John