Admin changed author, but new author can't edit page

By rbroberts on 2 May 2006 at 15:19 UTC

The subject pretty much says it all. I'm not sure what I need to do to allow the new author to edit the page. Any ideas?

Comments

Maybe you want to take a

Abilnet commented 2 May 2006 at 16:58

Maybe you want to take a look at the group (user roles) the new author belongs... and what permissions does the group (user role) in question have..

administer » access control

What permission is needed?

rbroberts commented 2 May 2006 at 17:56

The role in question is "chief editor" which can do just about everything except a few administration items.

However, I do notices that there is no "can edit all pages" permission. The page module has only "create pages" and "edit own pages" both of which are set for that role. Looking over the permissions again, I notice that all of the modules phrase the issue like "can edit own (whatever)".

I had assumed that by changing the author, I was implicitly changing the owner. Certainly, the uid column in the nodes table shows that everything (literally everything---it is a small test site) is owned by the new author.

same problem....

arise commented 3 May 2006 at 00:28

I am interested to find out if a solution is/has been found

Did you remember to apply

Abilnet commented 3 May 2006 at 11:08

Did you remember to apply the "chief editor" -role for the new author?
> administer > users > edit
...then verify, that the "chief editor" -box is checked (ie. that will add the new author to the "chief editor" -group that has those certain rights to do things...)

I did remember to apply

rbroberts commented 4 May 2006 at 01:20

I double-checked the page to make sure, and it is checked.

The chief editor role also has permission to "administer all nodes" in addition to every available edit permission. But like I noted, most of the modules list "edit own X" as a permission, but never "edit all X".

I tried to dublicate

Abilnet commented 4 May 2006 at 19:23

I tried to dublicate the problem, but everything works just fine on my test site (4.7 Release) ...do you happen to have some contributed modules installed, like Organic Groups, for example? ...if yes, there's maybe a need for some additional fine tuning on permission settings.

Sorry I don't have any clear solution in my mind... does someone else have an idea where to look next?

Works for me now....

rbroberts commented 24 May 2006 at 18:10

At some point, this began to work for me. I think it was after I updated to Drupal 4.7 release, but I'm not clear since I've been kind of scattered lately.

having same problem

amuzulo commented 8 May 2006 at 10:46

I am having the exact same problem. Did you find a solution to this? Thanks!

I had this problem -- here's what worked for me

colorambler@astronexus.com commented 11 May 2006 at 22:41

I recently set up a personal Web site with Drupal and had the same problem. I originally used "admin" to compose about half the content, but I ultimately wanted everything to appear under a non-administrative user's name. I went into the database and manually changed all the node user IDs to a specific non-administrative user ID. Presto, a bunch of files the non-admin user couldn't edit, no matter what privileges I set up.

It turns out I'd used full HTML or PHP for most of my content. My non-admin user had only filtered HTML as an input option. When I gave this user PHP and full-HTML formatting as input options, everything became editable.

In retrospect, Drupal's approach ("this stuff has a format you're not allowed to use, so I'm not going to grant you access to an 'edit' page...") seems basically valid. Still, encountering an access-control limitation outside the usual contexts for access control is very confusing.

Be wary, if you give a user

sepeck commented 12 May 2006 at 01:13

Be wary, if you give a user rights to use php, they can effectively own your site. You can grant input filters to different roles as well.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

Well, I do like to own my own site...

colorambler@astronexus.com commented 15 May 2006 at 21:50

...this account is for my use only. Ordinary registered users only get filtered HTML as an option.

thank you

amuzulo commented 15 May 2006 at 10:07

I changed that and now everything works great. Thanks!

should be in troubleshooting section of handbook

kvarnelis commented 16 June 2006 at 17:20

This problem was really hard for me to solve. This information should be in the troubleshooting section of the handbook.

http://www.varnelis.net

I had exactly this same

rediguana commented 18 February 2007 at 22:43

I had exactly this same problem as well. Enabling the correct input type fixed the problem. I believe that a more explicit error message should be created in this circumstance. It is important for troubleshooting that the reason for 'access denied' is outlined to save troubleshooting time.

Thanks, this solution worked

Jhary commented 1 May 2007 at 17:00

Thanks, this solution worked for me. I think it was the input format trick. I appreciate it.

Jhary
http://litmuse.net/

Thanks!

harryma commented 19 October 2007 at 00:40

This worked for me. I originally had tinyMCE enabled and it had changed the input types for whatever reason, and I couldn't pin point why a select few pages didn't allow me to edit them under certain accounts.

bump. Glad I found this

andrewbenkard commented 3 April 2008 at 19:36

bump.

Glad I found this solution, to a very vexing problem.
I concur that the frustration on this easily-encountered error could be diminished with better documentation or some kind of alert built into the product.

Thanks

evoltech commented 6 May 2008 at 23:19

I was really racking my brain on this. Thanks for the solution.

hackbloc.org : exploit code not people

Re: I had this problem -- here's what worked for me

gjd commented 1 October 2010 at 17:25

Thanks! That worked for me too...

i hard core solution

nsyll commented 3 December 2006 at 22:20

open the page.module and edit

/**
* Implementation of hook_perm().
*/
function page_perm() {
return array('create pages', 'edit own pages', 'edit all pages' );
}

and at

/**
* Implementation of hook_access().
*/
function page_access($op, $node) {
global $user;

if ($op == 'create') {
return user_access('create pages');
}

if ($op == 'update') {
return user_access('edit all pages');
}

if ($op == 'update' || $op == 'delete') {
if (user_access('edit own pages') && ($user->uid == $node->uid)) {
return TRUE;
}
}
}

i think that work

then ..

nsyll commented 3 December 2006 at 22:38

then go to administer » access control
and give permission to the user role that you want

--node module
administer nodes

--page module
edit all pages

Indeed "administer filters" solved it.

rseiser commented 7 December 2006 at 17:50

I had the same problem and virtually gave all access permissions and also category permissions except a few. One of these was "administer filters". Once I checked this one, the user could edit all pages.

evil and wrong!

dww

we/he/they

commented 16 January 2007 at 17:49

this is an evil security hole on your site. do *NOT* give out "adminster filters" permission to anyone who you do not want to have complete and total access to all data on your site. once you have admin filters, you can do anything.

the correct solution to this problem is to either change the input filter on the specific node so that it's using a filter that the other user has permission to use, or to (as little as possible) expand the available filters to the other user so that they have permission to edit the node.

giving out admin filters permission to all users on your site is like putting your DB's password and URL into the welcome email when users regsiter. ;)

this whole thread is another example of the confusion caused by the fact that input filters are basically like permissions in every way, but aren't treated as such by the admin UI. see http://drupal.org/node/11218#comment-172217

good luck,
-derek

___________________
3281d Consulting

The solution to this problem should be obvious

math0ne commented 18 May 2007 at 17:21

This took me a while to figure out... it should be in the manual somewhere...

RE: The solution to this problem should be obvious

jtjones23 commented 18 May 2007 at 21:47

I agree. I've been try to figure for months why my moderators could edit 90% of our pages but not every page. Once I gave the moderators permission to edit "Full HTML" they could suddenly edit all the pages. Very frustrating that this solution is not mentioned. At least I could not find it.

Same here

Countzero commented 31 May 2008 at 15:17

Stumbled on the same problem, solved it the same way. Very confusing indeed, yet quiet logical.

Thanks for the info.
---------
New to drupal, testing the Thing

It works!

harrow commented 1 June 2008 at 05:15

Thanks a lot - was going to get a custom module designed to fix this, but enabling 'Full HTML' does the trick perfectly.

Thanks alot, still effective.

macrodesign commented 7 March 2010 at 06:52

Thanks alot, still effective. Spent almost 2 hours last night trying to find why my friend was unable to edit some pages that I created as admin using HTML filter. Just opened Input Filters / HTML filter, gave his role the permissions to use this filter, and thats it.

Same

Akrotiri commented 9 March 2010 at 16:49

Many thanks for the solution as this problem was driving me up the wall.

Ditto that this needs to be documented somewhere more appropriate.