The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.
By sclough on
I have recently created two drupal sites. On both I need to have an account that can edit any content on the site, but does not need any admin rights. Basically, they do not need to fool with anything about the site setup, but they are responsible for any content, (pages, stories, etc). One one site I created a user and gave them all the rights I thought they should have and it seems to work fine. On the other site, I gave them the rights and they cannot edit any of the original content I put out there using the default admin account. I have even given them administer nodes and they cannot edit any content that they did not create. What have I done wrong? Most permissions seem to have the right to edit your own content, but how do I setup a user that can edit any content, just not also have admin rights?
Comments
Normally, 'administer nodes'
Normally, 'administer nodes' should be enough for editing all content. If it doesn't work it must be a bug.
Do you have any additional access modules installed, such as taxonomy access, simple access, node privacy byrole, organic groups, or path access?
I created a role for contact
I created a role for contact management and assigned it to the user. That role has administer node permissions. Is there maybe a bug where Drupal is getting confused between the authenticated user role permission and the Content Manager role permission? If I login as the user I only get the track option for previously created content, not the edit option. I can't really see any way of enabling this account to edit these nodes without just giving the user the root account.
I have the following modules enabled:
block, comment, contact, fckeditor, filter, help, menu, node, page, simplenews, statistics, story, system, taxonomy, upload, user, vocabulary_list, and watchdog. I can disable the comment module as this site doesn't use comments anyway.
The role the user is in has the following permissions:
Comments Module:
access comments, administer comments, administer moderation, moderate comments, post comments, post comments without approval
FCKeditor module:
use fckeditor
node module:
access content, administer nodes
page module:
create pages, edit own pages,
simplenews module:
administer newsletters, create newsletter, edit own newsletter, send newsletter, view links in block
statistics module:
access statistics
story module:
create stories, edit own stories
system module:
access administration pages, administer site configuration
upload module:
upload files, view uploaded files
user module:
access user profiles, administer users
Keep in mind that the user has far more permission than I want them to have, I've just been adding permissions trying to get it working and then I was going to start removing them.
Too hard to pin down where
Too hard to pin down where the problem is. The only sure thing is that this is not how it is supposed to work.
Anything unusual? Is it a multi-site configuration with some of the tables shared?
No. I haven't changed any
No. I haven't changed any code, only modified a theme and I know that's not the problem because if I go to list content and choose edit, I get "access denied." the site's pretty much a normal Drupal install. the site's not public yet so I'll do a quick check and make sure I'm on the correct minor version number and make sure I'm on the latest 4.6 release.
At this point I'm thinking I
At this point I'm thinking I should just go into the database and change the creator of the nodes to the user id that is going to be the content manager. Any reason not to do this?
In case anyone else is
In case anyone else is having this problem, I seemed to have solved it by setting the group permissions, deleting the user from the group, and then re-adding the user to the group. I haven't look yet at how Drupal stores user permissions, but maybe it assigns group permissions to a user and I just needed that flushed and rebuilt?
When you say "group", do you
When you say "group", do you mean "role"? Or is "group" something from a contributed module?
I am not being pedantic. I am asking because we could file an issue to have this fixed if others can verify it.
access denied - Flexinode
I was getting the 'Access Denied' message when trying to edit a flexinode. Some flexinodes could be edited (all of the same type) others I could not edit.
The only difference in the content was in the flexinode_data table:
numeric_data for the one item was 4 (cannot edit)
numeric_data for the other was 1 (can edit)
The field was a text field so the actual information was stored in textual_data.
Changing the 4 to a 1 fixed the problem. No idea why that would be a problem?
www.jws.com/we_install_modify_and_maintain_drupal_web_sites
Me too!
ALL,
I've just set up our first Drupal web site. Frankly, I'm really pleased with the ease of deployment and perceived administration. However, as can be expected, as the primary web developer I created content using the Administrative account, now NO ONE aside from myself can edit these pages. I've attempted to follow the same suggestions mentioned above. In detail:
I've created a role "Content Administrators", granted rights to edit content and assigned the role to those users who would frequently update the site. However, when logged in as a Content Administrator, they can not EDIT any pages created by the Administrative Account. Does anyone have thoughts on this one?
Scott Baetz
Web Developer
sbaetz@admininternet.net
Scott Baetz
Web Developer
sbaetz@admininternet.net
AdminInternet
http://www.admininternet.net
RESOLVED
Thump!
So, I was searching through the FAQ's, reading the handbooks and read the 'HOLY GRAIL' solution to this problem. The pages I had created used FULL HTML - and the role that I had created was not yet ASSIGNED the ability to use FULL HTML.
I didn't have to do ANY of the actions listed above, I simply assigned to the role the ability to use 'FULL HTML' and then BANG all the pages created before were fully editable. I suspect, that if I had two user roles, with limited access, yet one had the ability to create the FULL HTML and the other did not, the same problem would've occurred.
Thus, remember, that in order to edit a page, you must have the rights that the page uses when published.
Have FUN!
Scott Baetz
Web Developer
sbaetz@admininternet.net
Scott Baetz
Web Developer
sbaetz@admininternet.net
AdminInternet
http://www.admininternet.net
HURRAH!
Spent three hours trying to find answer to this. Thanks at last!
Just for those really stuck, you change this in the 'input format' general settings.
My users couldn't edit book pages, despite them having permission, but I saw Scott's post and realised that all book pages were set to 'Full HTML'. To allow users to edit pages with 'Full Html' you have to go to:
admin/settings/filters
or go to admin/settings and click on the Input Formats' link. There you can add user permissions to edit various input format types.
YOU'RE THE MAN
I was searching everywhere for the solution to this problem, and was about to abondon the drupal altogether thinking it was some strange voodoo in the code, you have truly have made my day
I created my own PHP
I created my own PHP template for a node-type that I call "gallery", which is basically just a page that contains a slideshow along with a short description. I assigned my client the role of Contributor so they can create and edit all content but not touch the admin. I've checked and the Contributor can edit any type of node, just the way I've specified (Full HTML ability and all that) but for some reason, they cannot edit the "gallery" pages.
And yup, I've also granted "Edit gallery content" and "Edit own gallery content" permissions to Contributor. To make it more interesting, the other options, such as "View" and "Outline" that are available in the tabs can be accessed by Contributors.
Someone mentioned a possible conflict with other modules earlier - these are the non-core ones I've got installed:
I thought there might be something wrong with my PHP, but it works fine when I'm logged in as Admin.
Bizarro!
"Half Iago, half Fu Man Chu - all bastard!"
(no title)
Using only core drupal, a user can't edit content posted by someone else. Besides the "edit galleries" permission, you need to install an access control module for that.
The one more suitable in your case is http://drupal.org/project/content_access, with which you can allow a user role to edit any content of some type.
Install it and then go to /admin/content/types, "edit" your gallery content type, go to the "Access control" tab, and give the user role you want permission to edit any content of that type.
Thanks Rusty,
Thanks Rusty,
However I'm inclined to believe now that there is a bug, because even after doing what you said, I logged in as "Contributor" and only got the "View" and "Outline" options.
You can preview the site here: http://www.context2.argentofchange.com/drupal/
Sign in at http://www.context2.argentofchange.com/drupal/user
as "user-tester", password "drupal"
"Half Iago, half Fu Man Chu - all bastard!"
(no title)
I saw it. If "test-user" is a "contributor" then it is as you describe it.
Besides a bug, there is only one explanation I can think. Perhaps those nodes have been posted with an input format (e.g. Full HTML) which is not available to contributors?
By the way don't forget to remove that account or change password if it is not a testing site.
Thanks Rusty - I had to
Thanks Rusty - I had to enable PHP code input for contributors - now it works!
"Half Iago, half Fu Man Chu - all bastard!"
(no title)
Just remember that any contributor can change your admin user name and password with 1 line of php code. And from there, there are many possibilities.
Also, now that you have the content access module installed, consider *not* giving the contributors "administer nodes" permission because it is too strong. It allows them to edit or delete all content of all types.
!?!
Full PHP for contributors? With full PHP rights, any user can effectively own your server as they can direct query and write to the database now.
-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
Using only core drupal, a
Are you sure about that-- i thought that was what the "edit [page-type] content" permissions were for....
(no title)
You are right. I have been carrying this misconception about the core access settings for a long time, which shows how addicted I have been to access control modules.
The only thing the "content access" module does for whole content types in Drupal 5 is to provide a separate permission for "delete". (In core the "delete" permission is granted automatically with the "update" permission). The rest of the functionality of the "content access" module is about individual nodes.
Although the initial post was about Drupal 4.6 where "edit [type]" was not available I did have this misconception.
except for book pages
Except on book pages from what I'm finding out now... though I can't seem so figure out exactly who can delete book pages. So far, it seems as if you need "administer nodes" to delete books pages, but i can't find a specific reference to this in the documentation anywhere-- it's just the only thing i could find that gave the delete button to my users for book pages. However, I really don't want my content editors to have "administer nodes" just to be able to delete their own book pages. I just haven't had the time to actually read through the code for book.module to understand how this is supposed to work.
Seems like a core issue / bug that should be addressed.
I ran into this same problem of the 'administer nodes' access not working properly because the role in question had not been given access to the input format being used on the pages. Seems to me that if people have been running into this issue for this long, a note or something should be added to the 'input formats' page in drupal core or somewhere..... this is a highly un-intuitive little bug, and if I hadn't found this forum topic it may have taken me several hours to figure out how simple it is to fix.
For the record, my pages were created using the 'full html' format and once I granted the role in question the 'administer nodes' permission AND properly configured the 'full html' input format to be accessible by that role, it worked just fine.
veg
...
It's not a bug. It's they way it's designed to work.
That said, it's not an intuitive way for it to work and there are some historical reasons for why this is so. Most of them ultimately come down to , 'no one has supplied a patch' that resolved the different use cases in a better manner. See the dev list archives and the issue queue for some periodic discussions in the past on this.
Some things have been tweaked a bit in D6, but I don't expect to see a real solution until maybe D7. It is something that active contributors are aware of.
-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