I have a Commons 1.1 installation. Everything is working OK for me as User 1. I can create roles, and assign permissions to them; I can create user accounts, and assign roles to them. But when I login with a new user account (with assigned roles and permissions) that I've created, it seems that I have no more permissions than a regular authenticated user.

Specifically, I'm trying to give certain users the ability to edit Page content types. So I have two roles where I've turned on the permissions, listed under the Features module, to "create page content", "edit any page content", and (for one of the roles) "delete any page content". I've created user accounts where I've assigned these roles. I've created a few Page nodes, which are linked as top-level choices in the Primary Links menu, so they appear on the menu bar.

Now, when I'm logged in as User 1, and I visit these Pages, I have View and Edit tabs at the top of the page, and all the expected choices are available on the Edit tab (including options for contributed modules I've added, such as Page Title and Nodewords). But when I log in as a user with a role that has "create page content" and "edit any page content" permissions, I do not have any tabs at the top of the page. If I try to reach the edit function with a URL such as http://www.mysite.com/node/1/edit?destination=admin%2Fcontent%2Fnode, I get "Access Denied".

Just to make sure, I re-created the roles, permissions, users, and page content described above on a standard Drupal 6.x site. When I login as a user -- other than User 1 -- who has a assigned Role allowing edits of Page content, I can access the pages, and I do have View and Edit tabs on these pages, as expected. So I believe that this problem is specific to Drupal Commons.

Comments

dfylstra’s picture

Issue tags: +community manager

More on this issue:

There's one basic difference between a default Drupal Commons site and my site: DC defines a Community Manager role, which is given many permissions, including "create page content", "delete any page content" and "edit any page content". On my site, I don't want to give these permissions to the person(s) acting as Community Manager, so I turned off these three permissions. Instead, I created another role called MyCompany Marketing, which does have these permissions.

Now, if I give a user only the MyCompany Marketing role (which is what I really want), that user cannot edit or delete page content, even though the role includes these permissions.

To try to understand this, I created another role called Community Manager 2, and I carefully gave it exactly the same permissions, across all modules, as the standard Community Manager role. This new role should behave in exactly the same way as the standard Community Manager role -- right? But it doesn't.

If I turn on the "create page content", "delete any page content" and "edit any page content" in the standard Community Manager role, assign this role to a user, and login as this user, then yes I can create, edit and delete page content.

But if I turn on the "create page content", "delete any page content" and "edit any page content" in the Community Manager 2 role, assign this role to the same user, and login as this user, I cannot create, edit and delete page content.

Now I turn off "create page content", "delete any page content" and "edit any page content" permissions in both the standard Community Manager and Community Manager 2 roles. Remember that these three permissions are turned on in the MyCompany Marketing role.

If I give the user both the MyCompany Marketing role and the standard Community Manager role, then the user can edit or delete page content. This is expected -- the page permissions come from the MyCompany Marketing role. But if I give the same user both the MyCompany Marketing role and the Community Manager 2 role -- i.e. exactly the same permissions -- the user cannot edit or delete page content.

My conclusion is that the standard Community Manager role -- which is entered in the "Community Manager Role" field when configuring the Drupal Commons module -- is somehow "special". But it's a big problem if users who don't have the standard Community Manager role cannot create, edit or delete pages -- and as far as I can tell, that's the case.

I would love to be wrong here -- but I'm worried that I'm right. (1) Am I wrong if so how, (2) Is this a bug, (3) Is this a 'feature' of Drupal Commons? Thanks in advance.

dfylstra’s picture

I finally found the problem. It involves Input formats (admin/settings/filters) which affect access to nodes, but are separate from Roles and Permissions. I was tipped off by the discussion at http://drupal.org/node/237906, which mentions 'Better Formats' at the end.

The Page nodes I had created had their input format set (by default) to Full HTML. As User 1 of course I could edit them.

Drupal Commons includes the Better Formats module, which evidently controls Input formats such as Filtered HTML vs. Full HTML, and gives access by Role to these different Input formats. There are default settings in Drupal Commons (which I had not changed) that give Full HTML access to (you guessed it) the standard Community Manager role.

When I created the Community Manager 2 role, I set all of its permissions to the same settings as the Community Manager role. But since I didn't know about Better Formats, I didn't add the Community Manager 2 role -- or my other roles such as MyCompany Marketing -- to the list of roles permitted to use Full HTML at admin/settings/filters. That explains why the Community Manager 2 role did not behave the same as the standard Community Manager role.

So now that I understand what is going on, I've removed the standard Community Manager role from the list allowed to use Full HTML, and I've added my internal company roles such as MyCompany Marketing to this list. Now everything is behaving as it should - my internal company users can create and edit Page nodes with Full HTML, while my (future) community members can create and edit other node types (blogs, discussions, etc.) but not Page nodes.

Our "use case" is not that unusual, I believe: We are building a new main corporate site to replace an old one, and one of our goals is to add community features. So our site will have hundreds of Page nodes that should be created/edited only by our internal people.

For someone looking at this later, with the Admin Menu that's enabled in DC you can use Site Configuration - Input formats to reach admin/settings/filters.

mstef’s picture

That's very interesting - nice work tracking down the issue. I'm going to look further into this.

gtothab’s picture

Thanks for the post! That helped me out greatly.

mstef’s picture

Status: Active » Closed (fixed)

1.2 will contain the better_formats module but it will be disabled to solve this problem. We'll leave the module in the distribution in case others want to enable it manually.

Thanks for the report!

wheelercreek’s picture

Thanks for posting this - helped me figure out my issue. We wanted authenticated users to be able to edit wiki pages, and could not figure out why they were unable to. All the permissions seemed to give them rights to do it. It was because the wiki page type was set to "Full HTML" and the users didn't have rights to that input format.

mstef’s picture

Update: that change will come in 1.3.