We got rid of the "internal" draft issue, who's next?

If you are using eZ publish with lots of “editors”, usually when implementing a portal with collaborative features, you probably faced the issue of drafts created by users without storing anything.

It bothers me for a long time.
The reason: eZ publish creates a draft version of an object whenever an edit action is called by a user. Wether that user stores a real draft version or not, the next time someone tries to edit the given object, a “nice” screen is presented that the object is currently being edited by you or someone else.

In highly collaborative situations, this turns users off, confuses them, and in our real life applications make them think it is impossible to do what they intended to. Really annoying or even worse…
The issue was discussed quite some time ago in the forums and during the eZ publish 2005 summer conference by Derick and me, and the best idea to solve it was to create a new status value for objects for the draft created by te edit action when called. In this way, this “internal” draft could be distinguished from real stored drafts … and a cron job could periodically scan the database and remove the internal drafts
I did not have the time to do it, but my collegue Kristof implemented the above idea recently and more: he patched the edit action even more. When there is an “internal draft” and the user who created this is no longer logged in, the internal draft is ignored and a normal edit screen is presented. That even avoids the need for running a cron job.

Go check out the patch at http://pubsvn.ez.no/community/trunk/hacks/untoucheddrafts/ for the 3.6 and 3.7 versions and tell us here or in the forums what you think. If all goes well, it may land in 3.8 with patches from us against the previous versions on pubsvn.

Cheers

About these ads