make robust to using Back button rather than cancel

Friday 23 December 2005 10:19:08 am

When you create a new object (could be a user account) in ezPublish you are taken to an edit template to populate the various attributes with values. Normally this has Accept and Cancel buttons. If you click Cancel you are asked if you really do want to Cancel, etc..

In a system that is open to public abuse, whether this be through malicious intent or simple ignorance, there will be frequent occasions when the user, panicked by the perception of some kind of commitment, simply uses the Back button on the browser. This leaves the object creation process in a kind of limbo state.

If the user does succeed in getting back to the edit stage, she will be presented with the opportunity to continue from the previous draft or to create a new one. This could be most confusing.

What measures can be taken to make a public ezPublish system robust to such treatment and behave in a simple way? This could consist of the silent deletion of any limbo state objects.

Saturday 24 December 2005 2:20:04 am

@ gabriel

Well, if all the fields are with the default values and the draft if lying around for a while, I'd say that's a good candidate for limbo state ;)

Checked otherwise, if the date of modification is the date of creation, that's a pretty solid hint, isn't it ?

@ nigel,

In site.ini, if you put

[ContentSettings]
EditDirtyObjectAction=usecurrent

Then you won't have the confusing "informational" message when the user tries to edit the object again.

@ everyone

Merry Xmas,

X+

http://www.sydesy.com

Saturday 24 December 2005 4:23:22 am

Sure, but if you wait long enough, say until the session has timeouted, you're rather safe.

I mean, even the slower user is not going to edit its content more than a couple of hours without saving in the meantime.

On ez, can we distinguish between a draft created by a new edition and one created by the save draft button ?

X+

http://www.sydesy.com

Sunday 25 December 2005 7:52:57 am

This feature is not currently planned for 3.8. Something like it will definitely be implemented for eZ publish 4.0 however with automatic removal of the internal drafts.

Monday 26 December 2005 5:47:59 am

Xavier

Is the script of Kristof you mention a public contribution ? 
Sounds like a nice feature to run.

Not yet, I asked Kristof to post the script ;-)

Out of curiosity, how do you deal without drafts on your system ? 
You never had problems of not finished things going live ?

What you describe with using sections to assign a "state" is actually what we do right now. Kristof made another nice extension which implements a "change section" button. No native workflow events involved here. Roles/policies based on sections do the rest. Can be used for quite a lot of other situations too ... a small swiss knife :-))

Regards

Paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Tuesday 27 December 2005 1:46:21 am

Indeed Xavier, you will have to rush to the "change section" button. In your case, I think it's better to use a seperate folder for your "drafts" (but in fact they are published) to which only the editors have access. When a draft is final, you can move it to the right location. Your solution with a workflow event seems good too. I think it has to be a post publish event then. If I remember well, the publish operation takes the section of the main parent as the section of a new object.

I think eZ should allow section assigning when creating a new object, eg. I want to create a folder in section "under discussion". Policy content/create should have an additional limitation then: NewObjectSection. Default is "section of the parent". I think I knwow how to write a hack that does the job, but the publish operation has to be modified too. Maybe we can get this into the kernel?

If I'm back on my work, next Monday or Tuesday, I will add the status module and the draft deletion script to the contributions and to pubsvn.

You can expect some other nice contributions from us in the near future ;-) In the next days/weeks, I will post some other ideas on my blog.

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Tuesday 27 December 2005 5:56:33 am

I've been thinking about something related: http://www.triligon.org/triligon/blog/acl_datatype

Visit http://triligon.org

Tuesday 27 December 2005 10:26:14 am

Grr it looks like our DNS is still acting up and delivering wrong IPs for that domain. Even though they claimed someone had fixed it this morning. I'll see about it...

It's gonna take a while it seems:
--------------

While the ezpublish permission system is quite flexible from an admin's point of view, it leaves a lot to be desired from an user's point of view. For example, a user can't decide himself (not easily, anyway) who should be able to read the object he just created. Even in the plain old Unix permission model he gets to chose that (obviously root can override that, but administrators are 1:1 the same in ezpublish) up to a certain extent.

Thus my desire to give this flexibility to users on an on off basis (obviously, in some cases you don't want to allow them this power, most likely when you're using approve workflows and things like that). After thinking about it for a while, I've decided that shoehorning a good model into the current permission system (like I did with ParentOwner which is comparably trivial) would be really really ugly and rather inflexible to boot. I then laid this to rest somewhere in the back of my mind until my interest in this got resparked when I read http://ez.no/community/forum/setup_design/make_robust_to_using_back_button_rather_than_cancel#msg90419 (the beginning of the discussion isn't quite related to this, but in the end it quickly converges towards this, in my mind anyway).

When I first thought of this I figured that using sections in a clever way would work (and most likely it would, for simple private/public features) but after some thinking I've decided against that. At some point it dawned upon me that a custom ACL datatype would be perfect for this, the only change in the kernel would then be a hack to recognize this datatype and let it override some of the permissions if it exists in an object!

Since the architecture is very flexible this way, I've been thinking that first I need to get the code stub to interface with the datatype into the kernel, after which the datatype can gradually be extended (obviously starting with a binary private/public option for reading, then writing, then adding something more like ACLs, possibly even groups).

------

Visit http://triligon.org

Tuesday 27 December 2005 11:53:39 am

Kristof,

You HAVE to be back, who else would play with the new gear on your desk?

;-)

--paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Wednesday 28 December 2005 5:12:16 am

I've committed a first version of the CustomCheck hack to the community repository, also read http://blog.coomanskristof.be/2005/12/28/first-version-of-the-customcheck-policy-limitation-hack/

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org