Saturday 17 January 2004 11:49:00 pm - 16 replies
Is there a nice way to toggle objects between draft / published and back. Thereby I do not mean toggling between multiple drafts of an object. But it can be compared with turning an object on/off by selecting it as published or draft.
Modified on Saturday 17 January 2004 11:56:37 pm by ruud prein
Sunday 18 January 2004 10:31:58 am
No, that function is essentially missing. Once your object is published, you cannot unpublish it (via the user interface).
In ez2, there was such an option (but ez2 had NO versioning).
You may try these options, when you wand to hide a published article:
- Delete it (will be in trash... but probably not editable)
- Move it to some place, when the "common user" cannot see it
- Assign a section to it, that the "common user" cannot read (you need a "admin section" for this, but i found this very handy).
We are using the second option, which you can use to (re-)move complete folder structures "out of the the visitors view" quickly.
NOTE: When you move an object by changing its main location, it might get a news section id (it will get the section ID of the new parent node). But when you move a complete tree, this only applies to the main object (usually a folder), not the child node (node assignment is not recursive, when you move nodes).
This might be important, when your read permission are only based on sections.
Sunday 18 January 2004 11:39:37 am
I'm also missing this functionality and posted it already in this thread:
I'm starting next week with this improvement and I hope to find a solution during the next two weeks.
Wednesday 21 January 2004 12:23:08 pm
I agree this is a missing feature with eZ publish 3. eZ publish 2 had a form of this feature but it has been ingored in 3.
Admin users need a feature to be able to disable a article (or other class) from the site/search. The article needs to remain in the directory so it remains in context. The admin user can go back and change/enable later. Currently users have to move the article or delete to trash/drafts, you then have the situation where drafts/trash has hundreds of articles and so very confusing to the admin user.
The problem really needs a change from a kernel point of view so that the admin user can have a visual notification that some of the contents in the folder will not be available to the front end site.
Hopefully this will make it into 3.3 updates as this question is asked by virtually every user of the sites we create.
Friday 23 January 2004 5:02:04 pm
Will add my voice to this.
I don't like the current Draft setup at all, versioning is cool but doesn't solve it all. Usually what I need drafts for is for someone to put up an article, in context, for it then to be editable by a second user or admin.
Had some thoughts on this but see that time doesn't allow to elaboratee just now - will do some thinking over the weekend and then try to outline my idea.
Monday 26 January 2004 1:30:55 pm
Thinking on this lightly over the weekend.
I'm thinking that the whole idea that saving the article equals publishing is wrong. Hopefully there is some reason why eZ has done this, but I'm not able to see it just now.
Couldn't the matter if about whether an article is published or not be a field? And then some logic to check so that no two drafts of the same article can be published at the same time? And of course published or not would be something one can set permissions to. Meaning that someone could have permission to create a draft, but not permission to make an article published. Then the admin or editor for that node could be alerted when something awaits publishing approval.
Maybe have "save" and "save new draft" as the buttons?
Also would be great if one upon finishing a draft could send the draft on to another user in the system.
All in all - my issue is to be able to place the drafts in the structure, and that other users (with restrictions) can view and edit drafts of others.
Monday 26 January 2004 1:50:50 pm
Isn't this what the workflow can do? An author writes an article, sends it for publication, then an editor gets a notice, checks and approves the article, only then it gets published.
Well, that's what I understood from the documentation, I have not completely set it up myself yet.
Modified on Monday 26 January 2004 1:51:25 pm by Harry Oosterveen
Monday 26 January 2004 2:11:04 pm
To Harry: Yes you have the workflow system. But since the Moderator currently has no chance to review and edit before approving it will only help you with guestbook submissions and other workflows where you are not really working together.
And once published... there is no unpublish. No easy way to go back to the author, if it's eg. a newspaper, and say "not good enough, please edit this and that".
Monday 26 January 2004 2:44:05 pm
I agree the workflow system works well for publishing and unpublishing. The problem is where to put the removed object. Currently they get stored in the drafts/trash folder which is difficult to manage in a large site.
I am glad other people have this problem and it is not just us.
Monday 26 January 2004 3:05:38 pm
I just had a quick look at the db. I wanted to know if i could manually remove the published article, thus removing it from being seen but keeping it on the system. This would test if inserting a toggle would be trivial.
The table: ezcontentobject_version holds publishing information for each version. The column 'status' contains a value describing the current status of the version, which can either be draft, published, pending, archived or rejected (int values 0-4).
I did a little admin test. I changed the status of an object with a few versions and set each to draft status. Having a look at the object with '/content/versions/(object_id)' confirmed they were all set to draft. Now, I would expect that viewing the object via 'content/view/full/id' would give some kind of error but nothing appeared so the system is still showing something when i believe there shouldn't be anything.
The reason it is still being shown may just be a template not performing a check. This may or may not be the right behaviour. I then checked on the user site and found the object could be still be viewed even if there are no published versions.
Modified on Monday 26 January 2004 3:07:48 pm by Paul Forsyth
Tuesday 27 January 2004 8:35:06 am
thats right. As I can see and understand, the values of the database value of ezcontentobject_version.status has no influence to the content/view. Only the content/versions changes, if I change the status in this table manually.
I think we have to find the table for the content/view.
By the way, can you explain me why the object_id of the /content/versions/y is different than the id of the /content/view/full/x
So, I keep on trying, maybe I have some luck and find something.
Tuesday 27 January 2004 10:31:49 am
Ah, just realised I should have stated that better.
It should be:
Hope that helps.
I think this problems is in two parts.
1) We still need a toggle. This may toggle the status of a version. Some method of choosing which version is to be published needs to be considered though.
2) The templates may or may not show drafts, depending on your setup - admin should, other sites probably not.
3) Perhaps storing an object shouldn't publish by default. Maybe an INI setting could decide this, or a default workflow?
Tuesday 27 January 2004 10:47:23 am
1) We still need a toggle, indeed!
Maybe it shouldn't be connected to versions and drafts, because I want toggle it complete offline and not another version or draft.
I tested the following:
mysql>update ezcontentobject_tree SET contentobject_is_published = 0 where node_id = 55;
This turned an object to unpublish, in my case a folder with the id 55.
But, it is then not listed in the admin interface - of course
Tuesday 27 January 2004 11:02:50 am
The folder view we see in the admin is one view of a tree and if the code only returns nodes with published content objects that explains why the node disappears. I bet if you view the object directly, via the versions view you will still see it.
Interestingly i believe the object relation list exploits this feature. When you add a orl datatype to a class you can specify whether you want any orl created objects to be part of the node tree or not.
Modified on Tuesday 27 January 2004 11:03:09 am by Paul Forsyth
Tuesday 27 January 2004 11:11:42 am
Just have to add something...
I think it worked well in the 2.2.x version where you had a checkbox for the contentobject_is_published field. Because its not possible to have an object in the admin interface that is not published, and thats been bugging me several times. You have to delete it to temporarily and then restore it, or move it away to a "hidden folder", and that is not what I want. There should be a checkbox I believe for this function so you can choose if it should be avaiable on "the outside", and also in the lists in the admin interface it should show the value of this field. When you clicked the checkbox, all versions where "offline" and you should also be able to choose which version should be published as is mentioned. That would solve a lot of problems I believe. Hope to see it
Oh, and also as in "the old days", you should be able to set avaiable from date, and avaiable to date, so one could publish an object only between two dates. That was nice.
Modified on Tuesday 27 January 2004 11:13:41 am by Claus Jensen
Tuesday 27 January 2004 1:10:01 pm
After testing a while, I suppose it could be easy to solve - or not
The fetch statement could be expanded in the admin view with s.th. like:
fetch( content, list, hash( .., publish_filter_type, all) )
default value could be instead of 'all' 'published' for a standard fetch:
fetch( content, list, hash( .., publish_filter_type, published) )
In the kernel/classes/ezcontentobjecttreenode.php this should be implemented:
Instead of the hardcoded query
ezcontentobject_tree.contentobject_is_published = 1";
this should be managed with the new parameter publish_filter_type.
After this is solved, an action should be added for each object to toggle off/on.
Until now I didn't get it
You must be logged in to post messages in this topic!