Save as draft
Chris Messina brought up an interesting point here: http://drupal.org/node/15506 where he suggests through the mockups the idea of allowing a user to save a post as draft (or saving as 'private' and viewable to the author only). I searched around but did not see any talk about this elsewhere, besides conversations related to using node_privacy_byrole (NPBR) as an alternative. Using node_privacy_byrole to do this, then theming posts which are not viewable to all to alert the author accordingly, seems a little too much or complicated, since the author will be presented with a bunch of checkboxes as opposed to just one checkbox to make the post viewable to themselves and not to anyone else (essentially save as draft).
What do people think about the ability to allow users to save a post as draft, and implement this via the core? Or should it be done via a variant to a module like NPBR?
Ian
Easy with two things
All this needs is:
1. a way for non-privileged users to check/uncheck the "published" field for their own content
2. a central place (like workspace) where users can see their own content
Actually, thinking about this some more, it could mean exposing Admin > Content to users for #2.
So, let's see some code and a core patch to get us started.
--
Please turn on the "story" type, so we can use it to have an archive of best practices, how tos, and configuration recipes.
working around the default settings
Looking at the node.module in 4.6, those with 'administer nodes' privileges are given access to the Publishing options, Authoring information, and comment options around this line in the node_form function:
<?php
if (user_access('administer nodes')) {
$output .= '<div class="admin">';
$author = form_textfield(t('Authored by'), 'name', $edit->name, 20, 60);
$aut...
?>
Following this statement with an additional permission which says authenticated users can access the Published/unpublished option gives the properly privileged user access to the checkbox, but somewhere else the default setting at admin/node/configure/types overrides this setting that the authenticated user sets, once the user saves the node.
1) I'm not sure where this is getting overriden. It looks like the node_nodeapi checks for the default settings and uses those settings.
2) I think it should be an additional privilege for users to be allowed to save drafts.
3) Either using workspace or tracker, and styling slightly different titles for draft posts in a user's own tracker could help with managing drafts.
In the current CVS of node.module, things are arranged a bit different, but the default settings are checked in the same way. Is there a good way to go around these default settings for publishing options, and maybe even comment options?
Ian
I went back and took a
I went back and took a second look. I did not see the check in node_validate. See this comment in the node_validate function:
"// Validate for normal users:"
Now, my approach is to add a 'publish as draft' permission, and then to allow the publish/unpublished field to show in the 'publishing options' in the node_form for users who have this permission and not the administer nodes permission.
I'm going to look at tracker to see if I can use it as an entry point for the user to access their own unpublished nodes.
A couple of issues appear to me:
1) the user must now be granted access to their own unpublished nodes (not just see them in a list like on tracker). Will need to look into this in the node module.
2) publish as draft should probably not be all or none, meaning maybe it should be set for each node type, so you can say users from roll A can publish drafts for the blog but not for stories, while roll B can do the opposite, or other. So, for each node type, you turn on the publish as draft capability in admin/node/configure/types/X and then instead of 'publish as draft' permission, you have 'publish %type as draft' permission. Is this overkill? What is the harm in letter a user post content as draft on a site? Perhaps it could mess up the admin's workflow, if blogs are allowed to be published as draft, but then so are content-type-x, but, the admin relies on the fact that content-type-x gets submitted to the site as unpublished anyways, so they go ahead and publish it, while the user was still working (drafting) their submission. This then makes me think distinguishing an unpublished post as declared by the 'publish as draft' permission as opposed to the default workflow is very important for more complicated sites.
Does anyone have any ideas how to make this work?
Ian
Use node_revisions table
Hello,
I am very keen to see a draft publication type functionality, but I am not a programmer, so I can only discuss theory and hope someone sees an easy way to implement.
I have had a play with the database directly to see wether what I want can be done, and I think it can.
Theory:
Someone with appropriate permission creates an edit of the node. When node_revisions is created, the node.vid does not update to reflect the new revision number, it remains the same. Visitors to the site still see the original content. To idicate a draft is available, there could be an entry in the document:
Submitted by userID (in draft) on dd/mm/yyyy - hh:mm
This draft document would also be visible on the revisions screen and shows up as a future revision, maybe the revision module can determine higher vid numbers and tag these entries as draft (ideally there would only be one draft).
To edit the draft document, it should be the same as editing the current node. The only difference is that vid will be the draft number, not the current vid number listed in node.vid
The mechanics behind this module would be another publishing option called drafts. To make a draft document you would select the publishing options:
Published
Create New Revision
Create Draft
The new option to create draft has the following effects. If Published is selected then the draft is viewable by suitably permissioned users immediately, otherwise the draft is placed in the publishing queue waiting approval. The draft can be viewed in the Revisions screen just like any other revision.
By selecting Create Draft, the Create New Revision would also be automatically selected as drafts rely on the revision module.
When the user edits the document they are now editing the draft, but the node.vid is not updated until the revision is promoted to current. The revision system already allows this to happen by selecting the Revert option (set active in pre 4.7.0b5).
The revisions let you track differences between multiple versions of a post.Revision Operations
04/03/2006 - 11:27 by admin revert delete
04/03/2006 - 11:24 by admin current revision
02/03/2006 - 11:08 by admin revert delete
02/03/2006 - 09:34 by admin revert delete
02/03/2006 - 09:31 by admin revert delete
Within the context of what Drupal can already do, I think it should be possible to create a drafts system very easily if it is built on the revision system. Basically, just create a future revision but do not update the node.vid. Make sure when the node is edited it edits on the node_revisions.vid of the draft and not the node.vid version (easily identified because the vid of the draft is greater than the current node.vid). When the draft is ready to publish, just revert the draft to current and the system is now displaying the drafted document as the current document. If the draft is not right, just delete it and start again.
The option of using the publish option to place the draft as unpublished is probably more than is required at this stage, but could be a nice touch later.
Also, if this all fit in with the workflow module, then anu user could create a draft and have notifications send to relevent users so they know the draft is available for updating.
I hope this gives interest to people and something can be developed around this.
Thanks.
I've been wanting this in
I've been wanting this in drupal for a while. I was just thinking, and I think we should do away with drupal's "published" option right now, in a sense, and rather, have a draft functionality, and then move the "published" option to access control rather than the node options.
I'm thinking about a site that I want to do with some users (who aren't necessarily technical) being able to add published content, but also have some others who can add content, but where their content has to be approved. It's really tough to do that right now, unless your users are technical.
--
Bradlis7.com | Churchofchristnet
Save node as Draft
Hello Bradlis7,
Check out this link http://drupal.org/node/48731
If you follow this all the way through you should end up with a patched node.module that adds the option to Save Revision as Draft.
Using this, you can permission a person to be able to edit a revision, you can permission a person to be able to publish a revision and you can permission a person to be able to delete a revision.
If you default this flag on, then effectively you can make it so that all edits to the document will create a new revision, but that revision will not be active, the original document is still active (published). Then the admin can check the revision and publish it when they are happy with it.
The revisions appear in the revision screen and they can also be operated on using the diff.module so you can compare the original to the proposed changes (I do not know if diff and revision work with flexinode, they did not work properly last time I tried it).
From what you are looking for, I think this mod to the node.module would allow that.
Thanks.
Awesome. I think I've seen
Awesome. I think I've seen that, but I don't want to mess w/ patching and stuff. It's too much trouble to keep it update when drupal releases updates every 3 weeks. But I hope to have something like this in core soon, or released as a module.
--
Bradlis7.com | Churchofchristnet
Hello, Well I guess that is
Hello,
Well I guess that is your decision.
Personally, I needed the functionality and this is the only thing I have come across that actually does it.
If you use it and then put pressure on the maintainer or core developers, then it has a better chance of making it into core. So far the main comments I have seen are that lots of people are asking for this feature, but the core developers do not think it is significant.
I think they are incorrect and that it is something that, once introduced, people will say "Hey, great feature why wasn't it there before?".
The patch takes a few minutes to update and the main issue is if the core changes too much the patch will be broken, but again, there is good support for this feature in the past so I think that would continue.
Bye.