This project is read-only.

What is the right mechanism for keeping history on a field?

Topics: Customizing Orchard, Writing modules
Aug 1, 2011 at 4:38 PM

I am working on a module which would allow users to choose another user to review their content before it gets published - sort of workflow-y, but really simplistic and specialized.

I have a part that holds a user id. I'd like to be able to keep a history on that field, within the same draft of content. Consider the following flow.

  1. User A creates page. Chooses "User B" from my part and saves the page. A new draft is created for the page, as well as my part, with "User B" as the value.
  2. User B edits page, and chooses "User C" from my part, and saves the page. The same draft exists for the page, and the value for my part becomes "User C".

What I would like to happen in step 2, is that instead of the original record for my part being changed from User B to User C, a new record would be created, so that I could view history of that field, to see the chain of approvals.

What is the best mechanism to do something like this? My initial thought was "oh just make your part draftable", but that maintains only one record per draft, like I described above.

  • Do I want to hook into the "updating" event of a handler, and make that create a new record for my part instead of just updating?
  • Do I need to go so far as to create myself a new controller to deal with all of this?
  • Is there some other mechanism that already exists for this type of use that I am missing?


Aug 1, 2011 at 8:28 PM

There is a versioning module that may be a good starting point:

Aug 1, 2011 at 10:29 PM
Edited Aug 1, 2011 at 10:30 PM

Unless I am missing something, that module just displays previous published versions, and the current draft. I am looking to be able to keep multiple versions of a part within one draft. And I am not expecting the framework to do it for me, I fully expect to have to build it myself...I am just trying to figure out where the right hook is to say "when the user hits save, and they are updating this part, really just create a new version of it, even if the previous is unpublished."

I am right now leaning toward bypassing the driver/handler framework and using a controller. I was hoping to be able to tie into the "Save" button when the user is editing a content item...but I noticed that DefaultContentManager.Get, with VersionOptions.DraftRequired passed in, only creates a new version if the current version is I suspect I am veering far enough from the framework to warrant my own controller. 

But thank you for your help, as always!

Aug 1, 2011 at 11:57 PM

Well, it should be a good starting point in that it shows how to use the existing versioning infrastructure. Multiple versions within one draft seems to me like it could be multiple versions, period, and then how you manage those is where you differentiate. Then again I'may not have understood what you were trying to do.

Aug 2, 2011 at 3:45 PM

Oh, absolutely. And that is my intention, to just create a new version. But it is actually creating a new version for a content item that is already in draft mode that I am unable to figure out. Like I said, it looks to me like the versioning infrastructure only wants to add a new draft if the content item is currently published, and that is where I am stuck. 

Aug 2, 2011 at 10:09 PM

Yes, well, I'm afraid I don't really what the best path would be, sorry. Let me know what you end up doing, it should be useful to others.