make robust to using Back button rather than cancel

Next topic

Author	Message
nigel dodd	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.
Gabriel Ambuehl	Friday 23 December 2005 10:50:11 am How would you know what objects are in limbo state? You could likely try and hijack the back button with Javascript and have it load the cancel URL instead but other than with help from the browser, ezpublish can't really know what it should dispose of and what not.... Visit http://triligon.org
Xavier Dutoit	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
Gabriel Ambuehl	Saturday 24 December 2005 4:14:41 am Well it could obviously be that the user is still editing it and wants to save it later? It would take a lot of guesswork to do this without some feedback from the client which is why I'd do it with some JS calls, likely. The usecurrent thing works, too. Visit http://triligon.org
Xavier Dutoit	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
Paul Borgermans	Sunday 25 December 2005 6:38:52 am Currently, you can not distinguish between a real draft as saved with "save draft" and the draft that is created when you call edit. Kristof Coomans made a script which deletes drafts in a smart way: when a user is not logged in anymore and for a certain age of draft objects, these are deleted. Furthermore, the save draft button is disabled in the user side of our sites (so drafts are all stale drafts in our case). During last years conference, this issue was brought up again with Derick. The idea was to have two draft types (used in the status field of objects) which distinguish between these stale drafts and the real ones. The cleanup script (run from cron mainly) and/or a new action to call could take this into account. Or even better: let the edit action take this also into account (type of draft, logged in or not) and ignore these meaningless stale drafts alltogether. I'll take this issue again in January, hopefully it makes its way into 3.8 Paul eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans
Frederik Holljen	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.
Xavier Dutoit	Monday 26 December 2005 2:30:15 am Hi Paul, Is the script of Kristof you mention a public contribution ? Sounds like a nice feature to run. Out of curiosity, how do you deal without drafts on your system ? You never had problems of not finished things going live ? On my side, I've got a big usability problem with the drafts: other users can't read/modify them. I think that's the main reason because they are more a pain than anything else on my case. I tought about creating a "submited for evaluation" section, with R/W access to the editors. Then, the idea would be to create a event that change the section of the content published to this section and add a new 'send for publishing for real' button that would change again the section to the original "default" one (ie the one of the parent). Would it make sense ? I'm wondering of the impact on the performance, as I've never tried to play with lots of nodes into different sections. X+ http://www.sydesy.com
Paul Borgermans	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
Xavier Dutoit	Monday 26 December 2005 11:31:35 am Hi Paul, Kristof, 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 :-)) Sounds great too. Would it be possible to share this contribution as well ? I still don't get how do you deal with the initial publication. For instance, imagine that I want to post a new article visible on the public website (section default). I create a new article under the proper folder and by default that's going to be section default, isn't it ? Therefore, if I publish it, that's going to be visible by anyone ? If I don't want to publish it, I have to rush to the "Kristof's swiss knife" change section button to put it to the "under discussion" section or do you have a more clever way of doing with that ? X+ http://www.sydesy.com
Kristof Coomans	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
Xavier Dutoit	Tuesday 27 December 2005 5:11:37 am Well, The draft folder is probably simpler, but I like the idea of having the draft content at the right place for several reasons: - when the editor creates it, that's already at the "right place" - the change status+move as a publication process seems rather countrer-intuitive, - I'd like to be able to list all the content in a folder (published and "drafts") to the editors (having the right to see them). Maybe with a different background or something to distinguish them. That might be easier to approve a content in the context. - that's closer to the usual "real draft" solution of ez. Anyway, I'm going to have a look at your contrib and see if I can make an event to change the status. If I'm back on my work... You plan a that difficult new year eve that you're not sure you'll survive ? ;) X+ http://www.sydesy.com
Gabriel Ambuehl	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
Kristof Coomans	Tuesday 27 December 2005 10:13:07 am I meant "When I'm back on my work..." instead of "If I'm back on my work...". But you'll never know... ;-) Gabriel, I get a 404 when trying your link. independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org
Gabriel Ambuehl	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
Paul Borgermans	Tuesday 27 December 2005 11:51:47 am Hello Gabriel I while ago I was thinking along the same lines (using a new datatype-attribute) for a situation which was basically a filemanager (folders and files) part in a portal and where per object permissions (set by the creator) were very desirable. About implementing this: I was thinking about the post-publish hook that exists for any datatype as a way to set "permissions" using the existing role/policy features. In this way, you can avoid tweaking kernel code ... as honestly, creating a dependency in the kernel towards a certain datatype is not a good idea from a design point of view. The post-publish hook in any datatype is by the way a pretty powerful thing to consider as an alternative to ezp workflows ... its way easier to debug. But, look also at Kristof's blog post: http://blog.coomanskristof.be/2005/12/25/planning-a-customcheck-policy-limitation-hack/ because the role/policy system may need some additional possibilities for this to work efficiently. Happy coding! --paul eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans
Paul Borgermans	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
Gabriel Ambuehl	Tuesday 27 December 2005 3:25:49 pm True to the motto of standing on the shoulders of giants, Kristof's approach would likely be an ideal base for my datatype as it is a more abstract hook into the permission system possibly opening the door for other approaches to implementations of the same underlaying concepts or even vastly different ideas. True to the spirit shown in ezpublish ;) I say go for it. Shout if you need help (I have some permission system hackery under my belt, too). Visit http://triligon.org
Kristof Coomans	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
Gabriel Ambuehl	Wednesday 28 December 2005 5:15:49 am Boy you're fast. Visit http://triligon.org