Usability: Disappearing edit tabs due to input format permissions.
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | node.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | patch (code needs work) |
I've found this to be a problem on several of my sites. Users lose (or don't have) edit access to nodes that they should be able to edit, given their roles and associated access control settings.
The node.module node_access() function denies 'update' access to a user, if a node has an input filter assigned that the user cannot access.
function node_access($op, $node = NULL, $uid = NULL) {
// Convert the node to an object if necessary:
if ($op != 'create') {
$node = (object)$node;
}
// If the node is in a restricted format, disallow editing.
if ($op == 'update' && !filter_access($node->format)) {
return FALSE;
}This can be a problem because a user can create a node, the administrator may alter input filter permissions so that the input filter used to create the node is no longer accessible to the user (or edit the node and assign a restricted input filter to the node) - and the original user can no longer edit a node (the 'edit' tab disappears from the node menu, and if the user tries to access the edit function via /node/x/edit URL, the users receives an access denied message.)
As far as I've seen, no warning is given in the watchdog so it's a complete mystery as to why a user should not be able to edit their own content.
I think at a minimum, node_access() should create a watchdog entry of some kind so that an admin will know why the update permission was blocked for a user attempting to edit content. I'm not sure what else can be done. (Might also be nice to let admins know that changing default input filters, or changing access permissions for input filters, can trigger loss of user edit capability in some circumstances.)
Is this a known issue? (Is there another issue that covers this?) I'd like to submit a node.module patch for consideration if it's not already being dealt with, and people think this is
I've written up a slightly more detailed note about it on this page.
#1
Oops - hit submit too soon. Next to last paragraph should have ended in: ...and people think this is something that should be fixed.
Changing version to 4.7.4 - I've checked and it appears to exist in 4.7.4 CVS code.
#2
Making this a bug report since I've not seen any comment on this. Is this a bug, or a "feature" as-designed?
#3
*bump* - is this as-designed behavior? Can anyone provide some insight into this behavior?
#4
Well, a verbose error message on the filter format based permission situations would be great. I don't see an easy way to solve the permission problem itself. Filter formats not allowed to be used by the user should be clearly forbidden.
#5
(Moving to Drupal 5.x since the problem seems to remain in current Drupal distros)
In order to help the harried Drupal site administrator, all that's really needed is a watchdog entry and some kind of warning (drupal_set_message) informing them of the "unusual" condition - since it's keeping someone from editing what is supposed to be their content, it causes much confusion, and there is absolutely *no* feedback as to why - creating much anguish and hair-pulling. :D
I had to step through the Drupal core code to determine why I (and others using my site) couldn't edit content... and that, IMO, is just not a good way to deal with the problem.
I just received another comment on my website about this issue so people are searching for solutions to this problem, and landing on my web page.
Anyway, I can submit a patch that creates a watchdog entry and a warning to the user experiencing the problem so that the admin can deal with the problem...
#6
I had same problem. I could change blocks,menus but not content. This is what I did and it is working.
Post seting set Preview post to optional
#7
As far as I can tell, the fact that filter formats are limiting edits is correct: I understand that as a security measure, especially if admin uses "php code" or "full HTML" formats to alter untrusted user's post, without realizing the consequences.
We really need the watchdog entry and error message! So, inactivist, please attach your patch here ;-) It may be a good idea to do so for 6.x first, but I guess this may be considered a bugfix, so 5.x might be OK too.
#8
Attached a patch that adds a watchdog entry when this occurs. I'm not really sure where we should put out an error message, so I've left that out.
This issue has bugged be for two days now, not understanding why a user couldn't edit his own pages, so I'd really like this to get in both D5 and D6 (if it's still an issue in D6). I'll provide a patch for D6 when this one is done.
#9
I would like to see this fixed in the current development version and then backported as necessary.
I do not think a watchdog message is the appropriate solution. Ideally, the user could access the edit page, but have the textarea replaced with a notice of why it can not be edited. The other fields would act as usual.
#10
Great suggestion!
I ran into this bug before and it is just one of those things that can make you feel really stupid so some feedback for bugtracking would be a good step forward.
#11
I think this should be marked as critical, reposting what I wrote on
http://drupal.org/node/244390- looks like me and drumm had the same idea with the disabled textarea, I think that'd be an ideal solution for this.--
As stated on #243728, if a user has access to edit x content type, but doesn't have access to the filter format of that post, they lose the edit tab with no explanation. This has the effect of very confused support requests from site users (I've personally had many), and I've probably answered 4-5 #support requests in the past month or so from Drupal admins with the same issue.
The issue manifests itself in a few ways:
1. users have permission to edit any $node_type, but can only edit some
2. admin users/editors edit a node using a different input format, and the user loses access to edit their own node.
In both cases, there's no access denied or warning to inform the user that they no longer have access to edit, they just lose the edit tab.
Additionally, there's nothing to warn editors when changing an input format that the owner of the node doesn't have access to it.
So instead I think we've got a couple of options:
1. leave the edit tab but disable text areas which users don't have permission to edit - this would mean they could still change titles and stuff, and would have an explanation of what exactly the issue was.
2. add a small javascript warning to the input format selection which informs editors that they're choosing a restricted input format - either not available to the node author or not available to auth users or whatever.
Making input formats into a first class permission will help, but I think we can go a step further.
Here's the results of a quick google search for disappearing edit tabs:
http://drupal.org/node/126504
http://drupal.org/node/15283 <<- note the nid.
#12
I like what drumm and catch has proposed, but I don't have time to work on this right now, so unassigning myself.