[drupal-devel] [bug] Failure to respect node status upon editing
(reverts to default)
killes
drupal-devel at drupal.org
Thu Apr 14 14:45:18 UTC 2005
Issue status update for http://drupal.org/node/7940
Project: Drupal
Version: cvs
Component: node system
Category: bug reports
Priority: normal
Assigned to: mathias
Reported by: mathias
Updated by: killes at www.drop.org
Status: patch
Some people think, that the node settings _should_ be reset after
editing. There are good reasons for some of the settings to be reset,
for exampel in case of the "promote" bit. I cannot see such reasons in
case of the "comment" bit and would like to see that part of the patch
included.
killes at www.drop.org
Previous comments:
------------------------------------------------------------------------
May 21, 2004 - 04:00 : mathias
How to recreate:
1. As admin, navigate to: administer » content » settings, and
uncheck 'publish' for stories.
2. As admin, create a story and assign it to a user that can create and
maintain their own stories, say this user's name is Mark.
3. Login as Mark and edit that story.
4. Instead of staying published, it reverts back to it's unpublished
state.
I think this behavior is a bug as these content settings are default
settings and should only be applied during node creation (not editing).
I know Drupal-contrib project owners get bitten with this everytime they
edit their project pages.
I'll work on a patch within the next day.
------------------------------------------------------------------------
May 21, 2004 - 16:59 : mathias
Attachment: http://drupal.org/files/issues/node_defaults.patch (1.05 KB)
Proposed solution:
If a node is being updated: respect the following existing settings:
1. node status (published/unpublished)
2. node promotion (promoted on front page)
3. node static (static on front page)
For any node, force the defaults for:
1. moderation
2. revisions
With our current situation, say the admin makes 'promote to front page'
and 'static on front page' the default settings for stories. Another
user posts a story and bam! it's of course immediately visible. The
admin decides he/she doesn't like that story and demotes it. Well as
soon as that user edits his story, the default settings are re-assigned
and his post is right back on the front page.
------------------------------------------------------------------------
August 3, 2004 - 20:38 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_0.patch (1.19 KB)
When editing nodes, the following node properties should not be
overwritten
- node status (published/unpublished)
- node promotion (promoted on front page)
- node sticky (top of the list)
Currently, if the author of a node doesn't have 'administer node'
privileges, than the above settings will always revert to the default
behavior of their node type group. This makes nodes disappear and node
authors very very confused.
------------------------------------------------------------------------
August 3, 2004 - 20:56 : ccourtne
Don't forget to take moderation into account. If a node is edited
should it go back through moderation? Some sites may want the behavior
of going back some sites may not. This is probably best as a toggle
option on workflow default config screen.
------------------------------------------------------------------------
August 3, 2004 - 22:21 : mathias
I don't think my patch interferes with the moderation features. If the
default workflow for a type of nodes is set to 'moderate', than the
moderation flag will always reset itself to 'moderation' upon editing.
I did not alter this functionality.
------------------------------------------------------------------------
September 29, 2004 - 23:00 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_1.patch (1.64 KB)
I was recently bitten by this bug again, so I'll try to describe the
exact nature of the problem.
If an user of a node doesn't have 'administer nodes' permission, than
whenever they edit their own node the status, promotion, static,
moderation and revision settings revert to their default state. This
can cause:
- A demoted post to once again be promoted.
- A promoted post to be demoted.
- A static post to disappear from the front page.
All of these scenarios have happened to me simply by authors editing
their own content. This patch allows all options except moderation and
revision to stay with a node once it's created. Note: along a very
similar line, the one-line 'node_validate does not respect group
editing patch [1]' has been rolled into this as well. I'll take it out
if need be.
[1] http://drupal.org/node/11071
------------------------------------------------------------------------
September 29, 2004 - 23:00 : mathias
I was recently bitten by this bug again, so I'll try to describe the
exact nature of the problem.
If an user of a node doesn't have 'administer nodes' permission, than
whenever they edit their own node the status, promotion, static,
moderation and revision settings revert to their default state. This
can cause:
- A demoted post to once again be promoted.
- A promoted post to be demoted.
- A static post to disappear from the front page.
All of these scenarios have happened to me simply by authors editing
their own content. This patch allows all options except moderation and
revision to stay with a node once it's created. Note: along a very
similar line, the one-line 'node_validate does not respect group
editing patch [2]' has been rolled into this as well. I'll take it out
if need be.
[2] http://drupal.org/node/11071
------------------------------------------------------------------------
September 30, 2004 - 20:08 : Dries
When someone edits a node that has been promoted, I do want to demote it
from the main page. If not, the system is open for abuse. IMO, this is
'by design'.
------------------------------------------------------------------------
September 30, 2004 - 21:00 : Bèr Kessels
Both Dries and Mathias have valid points here.
If I add a post with loads of ugly stuff inside it, but an adminstrator
decides not to delete it (because the post is still not too bad, or
because of policy), but demote it, I can promote my spam next minute
again by simply editing my content. This is bad.
If I add a post with lots of good information, so that an administratr
promotes it, next thing i can do is open it up and add loads of ugly
spam to it.
Buth are unwanted scenarios. The first is what we have now. The second
is when this patch is committed.
I think we need to seriously rething the workflow logic, maybe
splitting workflow up into "add" and "edit".
But maybe there are even better options?
------------------------------------------------------------------------
September 30, 2004 - 21:01 : Bèr Kessels
Both Dries and Mathias have valid points here.
If I add a post with loads of ugly stuff inside it, but an adminstrator
decides not to delete it (because the post is still not too bad, or
because of policy), but demote it, I can promote my spam next minute
again by simply editing my content. This is bad.
If I add a post with lots of good information, so that an administrator
promotes it, next thing i can do is open it up and add loads of ugly
spam to it. and then i have a promoted post with spam on that site.
Both are unwanted scenarios. The first is what we have now. The second
is when this patch is committed.
I think we need to seriously rething the workflow logic, maybe
splitting workflow up into "add" and "edit".
But maybe there are even better options?
------------------------------------------------------------------------
September 30, 2004 - 21:02 : Bèr Kessels
Both Dries and Mathias have valid points here.
If I add a post with loads of ugly stuff inside it, but an adminstrator
decides not to delete it (because the post is still not too bad, or
because of policy), but demote it, I can promote my spam next minute
again by simply editing my content. This is bad.
If I add a post with lots of good information, so that an administrator
promotes it, next thing i can do is open it up and add loads of ugly
spam to it. and then i have a promoted post with spam on that site.
Both are unwanted scenarios. The first is what we have now. The second
is when this patch is committed.
I think we need to seriously rething the workflow logic, maybe
splitting workflow up into "add" and "edit".
But maybe there are even better options?
------------------------------------------------------------------------
September 30, 2004 - 21:11 : Dries
The first problem can be solved by blocking the user account, or by
revoking the user's permissions.
The second problem can probably be solved using the node-level
permissions. Whenever I promote a post to the front page, I could
revoke the user's edit rights. It would only work, if the modules
don't by-pass the access rights, of course (I believe some do).
------------------------------------------------------------------------
October 3, 2004 - 22:28 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_2.patch (4.22 KB)
Dries is right about using the power of node-level permissions for
community editing. I think this patch would assist that goal. As it
stands, node-level permissions don't work with community editing, at
least in the sense we're used to. For one node_validate transfers
ownership of the node to the current editing user which may not always
be the author. This causes many problems since original authorship
usually implies special privileges (e.g. 'edit own foo', delete).
Second, sites have different trust levels for users. On some sites
there's just a handful of trusted users that edit and maintain all the
content. The current approach for community editing is to create a new
role and give it the 'administer nodes' permission, which in my opinion
makes the node form interface much more cluttered and gives users in
that role full access to node properties. Full access is not always
desired. Using a combination of node-level permissions and allowing a
node to retain some or all of its options makes a clean, easy to use
approach to maintainance.
This new patch lets the admin control how node_validate handles node
options during editing. It splits the default workflow screen into two
parts: Creation settings, and Editing options. The creation settings
is the default workflow we're all used to. The editing options allow
the admin to say what happens to those node options when they are
edited.
I've created a node-level permissions module [3] based on JonBob's work
that allows a user to choose which roles can view and/or edit their
post. Unfortunately it needs this patch to allow node_validate to be a
little less controlling. I'd like to contribute this module if it
didn't need a patch.
[3] http://www.asitis.org/tmp/
------------------------------------------------------------------------
October 3, 2004 - 22:30 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_admin_content.png (22.39 KB)
Screenshot of the new default 'node editing options' interface.
------------------------------------------------------------------------
October 4, 2004 - 16:16 : Bèr Kessels
Mathias,
First: using radio's for a Boolean is bad UI design IMO. It would be
much better if you use checkboxes.
Second: If you use radio's you can make the same matrix as above, for
each node-type a reset foo flag.
This will not only make the UI more consistent, but also improve
usability by allowing per-node-type reset flag.
Ber
------------------------------------------------------------------------
October 4, 2004 - 19:08 : Dries
The settings GUI's help text is rather hard-core and will scare many
user away. It will even frighten most Drupal developers. Also, I'm
not sure I understood the screenshot correctly.
The functionality introduced is much needed but the GUI and
configuration parts needs work IMO. Keep working on it.
------------------------------------------------------------------------
October 14, 2004 - 22:55 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_3.patch (4.74 KB)
As per Ber's feedback, I changed the interface to use checkboxes and
allowed the reset flags to be set for each node-type. The result is a
much more familiar and consistent experience.
Dries: I revamped the help text, removing the scary bits and sticking
to the bare essentials.
The dialog concerning this patch has been excellent, and the result of
which I feel is a sweet slice of code ready for core :)
------------------------------------------------------------------------
October 14, 2004 - 22:56 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_admin_content_0.png (18.68 KB)
Latest screenshot of patch.
------------------------------------------------------------------------
October 28, 2004 - 21:08 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_4.patch (4.81 KB)
Updated the help text to be slightly more descriptive, informing the
reader that: Users with "administer nodes" permission can override the
editing options.
------------------------------------------------------------------------
October 29, 2004 - 00:51 : Steven
I'm not sure I like that admin interface. My brain tries to correlate
the two tables, but the meanings are different (what is the value, keep
the value?). Maybe it would be better just to have one checkbox per node
type to allow you to either revert the
published/frontpage/moderate/sticky fields on editing, or not. This
should cover 99% of all use cases with an admin interface that is much
easier to understand.
------------------------------------------------------------------------
October 30, 2004 - 20:29 : mathias
Attachment: http://drupal.org/files/issues/node_defaults_5.patch (5.06 KB)
It provides a consistant look and feel if the creation settings are the
same as the editing settings since they both manipulate the same
components of a node and you're just toggling states based on different
actions.
I think it is a bad idea to only give site admins an 'all or none'
approach to override node options upon editing. Here are some examples
why:
- You want nodes to remember their 'sticky' setting, but unpublish
themselves after editing. Once the node is approved, it goes right back
to where it was.
- You want nodes to remember their 'promote to front page' setting, but
unpublish themselves after editing. Once the node is approved, it goes
right back to where it was.
- You want nodes to remember all their settings except moderation. The
node is still published, but it goes into the queue to be rated again
since the content has changed.
- By default nodes are unpublished. Once it's been tagged as published
it stays that way. Perhaps the moderation tag is reset.
I've updated the code to hopefully make things even more clearer.
Here's the latest screenshot [4].
[4] http://asitis.org/tmp/node_defaults_admin_content_1.png
------------------------------------------------------------------------
January 24, 2005 - 17:41 : moshe weitzman
this patch fixes a fairly undesirable problem with our workflow. lets
consider it along with other proposed changes to default workflow.
------------------------------------------------------------------------
March 13, 2005 - 23:04 : killes at www.drop.org
Does not apply anymore.
------------------------------------------------------------------------
April 12, 2005 - 20:07 : r11r
I'm still experiencing this problem with latest CVS (head and
drupal-4-6) and in addition to the publishing options (Published,
Promoted to front page, etc), it also affects the settings for
comments.
When a user edits the page, the settings revert to the default value
for that content type, instead of what is currently set for the
specific node.
Example of this problem with respect to Comments:
( Create a user with permissions to edit own pages, but not administer
comments. )
1. user creates page (comments default to read/write)
2. admin edits page and turns off comments
3. user edits page and saves
4. comments are reset to read/write
Help :)
(Am willing to assist in fixing this if necessary)
------------------------------------------------------------------------
April 12, 2005 - 20:31 : killes at www.drop.org
Ok, just some remarks from irc:
21:23 < killes> r11r: After looking a bit more at the code I think it
is more of a feature request than a bug.
21:23 < killes> Not that I would mind some more flexibility, of course.
21:24 < r11r> killes: well, node settings magically resetting
themselves could be considered a bug.. hehe
21:25 < killes> Well, it is not magically, it is "by design". ;)
21:25 < killes> i don't think we will get that into 4.6. But I woul
dwork with you to get it into 4.7.
21:27 < killes> This needs to be part of a more general improved
workflow thingie.
21:27 < killes> Did you try clousseau's workflow module? it is amazing.
------------------------------------------------------------------------
April 13, 2005 - 14:59 : r11r
Haven't yet looked at workflow, but this issue can be fixed by simply
unsetting the node properties for which the user doing the edit does
not have permissions.
i.e. in node.module (around line 1255)
if (!$node->nid):
-- load defaults from database settings
else:
-- unset node->status, moderate, promote, sticky, revision, created
also in comment.module (around line 247, the nodeapi hooks)
if (!user_access('administer nodes')):
-- unset node->comment
Because any properties that are not set in the node object do not get
passed into the update sql statement, the node will retain its previous
values after being edited by a user instead of reverting to the default
values for the content-type.
Can anyone think of problems with this approach for the time being?
------------------------------------------------------------------------
April 13, 2005 - 17:52 : r11r
Change in comment.module, line 257 for head and 4.6, line 254 for 4.5.
case 'validate':
if (!user_access('administer nodes')) {
if (!$node->nid) {
// Force default for normal users:
$node->comment =
variable_get("comment_$node->type", 2);
}
else {
// If the node is being updated, respect its
previous settings
unset($node->comment);
}
}
break;
------------------------------------------------------------------------
April 13, 2005 - 18:02 : r11r
Didn't really mean to change the title!
------------------------------------------------------------------------
April 13, 2005 - 18:05 : r11r
Change in node.module, for head and 4.6, around line 1258
$node_options = variable_get('node_options_'. $node->type,
array('status', 'promote'));
if (!$node->nid) {
// Force defaults in case people modify the form:
$node->status = in_array('status', $node_options);
$node->moderate = in_array('moderate', $node_options);
$node->promote = in_array('promote', $node_options);
$node->sticky = in_array('sticky', $node_options);
}
else {
// If the node is being updated, respect is previous
settings
unset($node->status);
unset($node->moderate);
unset($node->promote);
unset($node->sticky);
}
$node->revision = in_array('revision', $node_options);
unset($node->created);
For 4.5, the code is slightly different in node.module, around line
1095...
if (!$node->nid) {
// Force defaults in case people modify the form:
$node->status = variable_get("node_status_$node->type", 1);
$node->promote = variable_get("node_promote_$node->type",
1);
$node->moderate = variable_get("node_moderate_$node->type",
0);
$node->sticky = variable_get("node_sticky_$node->type", 0);
}
else {
// If the node is being updated, respect is previous
settings
unset($node->status);
unset($node->moderate);
unset($node->promote);
unset($node->sticky);
}
------------------------------------------------------------------------
April 13, 2005 - 18:06 : r11r
Attachment: http://drupal.org/files/issues/node.module_head.patch (1.38 KB)
Patch for node.module in HEAD
------------------------------------------------------------------------
April 13, 2005 - 18:06 : r11r
Attachment: http://drupal.org/files/issues/comment_head.module (76.29 KB)
Patch for comment.module in HEAD
------------------------------------------------------------------------
April 13, 2005 - 18:07 : r11r
Attachment: http://drupal.org/files/issues/comment.module_head.patch (976 bytes)
Err, sorry too many files to pick from in the directory . :)
Here's the patch again. (for comment.module, in HEAD)
------------------------------------------------------------------------
April 13, 2005 - 18:09 : r11r
Attachment: http://drupal.org/files/issues/node.module_drupal-4-6.patch (1.39 KB)
Patch for node.module in DRUPAL-4-6
------------------------------------------------------------------------
April 13, 2005 - 18:09 : r11r
Attachment: http://drupal.org/files/issues/comment.module_drupal-4-6.patch (988 bytes)
Patch for comment.module in DRUPAL-4-6
------------------------------------------------------------------------
April 13, 2005 - 18:10 : r11r
Attachment: http://drupal.org/files/issues/node.module_drupal-4-5.patch (1.38 KB)
Patch for node.module in DRUPAL-4-5
------------------------------------------------------------------------
April 13, 2005 - 18:10 : r11r
Attachment: http://drupal.org/files/issues/comment.module_drupal-4-5.patch (1010 bytes)
Patch for comment.module in DRUPAL-4-5
More information about the drupal-devel
mailing list