module does not work with OG 5.7.2

Ohhh ... just my luck. I just implemented OG 5.x-7.2, and now I realize OG User Roles is going to solve an issue I have. Obviously this was just posted today, but curious if any thoughts on the timeline for releasing an update? Is this fairly high priority on your list of things to do? :)

Actually, OGR does work with 5.7.2 *if* you have already been using it in previous versions of OGR that used the og_node_types. The variable is still there, although not used by OG.

However, if you've never used either, or began using OG after it lost the variable, then you run into this problem.

A global search and replace won't do because the arrays returned are different.

I should have at least a patch ready in a day or so.

Thanks, LouBabe for finding this.

Also, the uninstall does not work on at least two levels. One, it doesn't delete the multinode_access table it creates, and it attempts to delete the og_user_test table even when it does not exist.

Not quite sure what to do about the mutinode_access table. This was developed for use by multiple modules, so I decided NOT to remove it. Yes, this is devel stuff, but this functionality is tested and works.

With respect to the og_user_test table, I've never quite done that correctly. I wrote the module to create it if you used it, but try to delete it in any case if you uninstall. I should just go ahead and make it part of the default install. Or, write the code to delete it if it exists. We will see.

Thanks for the update. Unfortunately we're new to using OG, which means we're new to OGR too. I'll be on the lookout for the patch.

Apply the attached patch to a clean download of 3.1 release. It should resolve this issue:

OG User Roles is using the variable og_node_types to determine whether a node is a group node throughout the code. The new version of OG uses a function, og_get_types('group') instead.

Could not duplicate this problem:

However, when I assign a user to a given role in a group, it has no effect on that users permissions.

I am not getting any errors with the patch, but it is not working as I would expect. Let me explain the situation and you can let me know if this is a patch issue or not.

We have a content type called "article" which can be written by "authors" and edited / published by "editors". The only way to allow editors to revise, edit and publish an article is to give them "administer nodes" access control.

However, we don't want editors administering all nodes for the site. Editors should *only* have publish authority for articles, not for any other node type. After reading several examples it seemed like this could be accomplished by doing the following:

1. Create an OG for authors and editors. They are the only roles who can create and edit articles.
2. Make article a content type which can only be created in an OG.
3. Create a new role called "Group Admin", which has "administer nodes" access control.
4. Apply "Group Admin" as a role for editors in the Organic Group.

I would have expected by doing this, editors could create/edit articles (overall website 'Editor' role) and have publishing authority within the OG (group-specific 'Group Admin' role), basically Editor role + Group Admin role within the group. However, the Group Admin role doesn't seem to be applied at all. An editor can create and edit an article, but has no publishing authority.

Thanks for the detailed explanation. This is how it should work and does work. I tested the exact same situation recently. Just retested with patched OGR and OG 5.7.2.

I suggest you turn on OGR Test and then have the Group Admin create an article node. Then, turn off OGR Test (so it doesn't become too unwieldly) and report back the role(s) the the user actually has when creating an article.

I have noted in the past that sometimes patched modules don't work as expected, and this could be one of those cases. Then again, there could be some configuration issue we haven't thought about.

I'm attaching the full, patched, OGR module (appended with ".txt"). Download the file, remove the ".txt" extension, and copy to your OGR module directory (overwriting the existing module). This way we can be sure it's not a patch application problem.

I did a comparison on the og_user_roles.module I had patched and the one you provided above. Strange, but the only line not added to my version was include_once(drupal_get_path('module', 'date_api') .'/date.inc'); in the og_user_roles_cron() function. Really makes no sense since you added the entire function, and only the first line was missing.

I ran the test using our editor test account, "test_edit". As you see on the attached file called "og_member_roles.png", test_edit in the OG has "Group Admin" and "Group Member" roles. This is in addition to the test account's baseline 'authenticated user' and 'editor' roles.

When creating the article, I receive multiple rows in the og_user_test table with the following:

testDate = 2008-05-17 03:23:39 pm
testUser = 16
testUserName = test_edit
testGroup = 234
testFunction = og_user_roles_all_roles
testSubFunction = 1 (is '0' on following rows)
testString = group context: (is 'group context: 234' on following rows)
testURI = /article/this-test-og-roles-functionality/237 (http://localhost/node/add/article)
testAArg0 = node
testAArg1 = 237
testPerm = Roles Returned: (authenticated user,Editor,Group Member,Group Admin)

So seems like the right roles are returned, but test_edit can only create and edit articles, and does not have the ability to publish articles or use Drupal's revision process. See the other attached file for a listing of the current Access Control layout.

Then, there's something else going on. OGR is doing what it's supposed to do: Give you the role within the group context. *Something else* is preventing the "Publishing options" tab from appearing in the node. So, at this point, I'm at a complete loss as to what your problem might be.

So, we take it a step at a time.

1. If you give the user the GroupAdmin role sitewide, do the "Publishing options" come up?
2. Is there any evidence that any group member has the permissions of any group role assigned to him within the group?

I am curious about this line:

testURI = /article/this-test-og-roles-functionality/237 (http://localhost/node/add/article)

OGR only adds content using "ognodeadd" and "gids[]=", neither of which I see here. This is what I expect to see on a /node/add (BoardMember role assigns group member the "administer nodes" permission here):

Date: 2008-05-17 03:13:27 pm
UID: 2 
Username: test 
Group: 43 
Function: og_user_roles_all_roles 
Location: 10 
group context: 43  
URI: node/ognodeadd?type=page&gids[]=43 (http://www.mysite.com/node/44/edit)
arg0: node 
arg1: ognodeadd
Roles Returned: (authenticated user,BoardMember) 

And, on a node edit:

Date: 2008-05-17 03:19:49 pm 
UID: 2 
Username: test 
Group: 43 
Function: og_user_roles_all_roles 
Location: 0 
group context: 43  
URI: /node/44/edit (http://www.mysite.com/node/44/edit) 
arg0: node 
arg1: 44 
arg2: edit  
Roles Returned: (authenticated user,BoardMember) 

In both cases, user "test" sees the "Publishing options" fieldset.

So, we also need to determine why you aren't seeing the above in your og_user_test output.

To answer your questions:

1. If you give the user the GroupAdmin role sitewide, do the "Publishing options" come up?
Yes. If I give "Group Admin" to the "test_edit" user through User Management (for the entire site), "test_edit" then has Publishing options.

2. Is there any evidence that any group member has the permissions of any group role assigned to him within the group?
Yes, but only if the given permission is directly applied to the group role. If you look at the "access_control_for_nodes.png" file I attached to response #7, you'll see Writers can create article and teaser content. I removed the check for "create teaser content" for Writers and set it to Group Member. I then logged in as "test_writer", viewed the OG, and saw the writer had the option to create teaser content.

To go back to the original question, am I understanding correctly how the module works? Can I have the permissions as I have set in PNG file, where an editor receives authority to create an article, but can only publish that article as a Group Admin within the OG?

As for the testURI line you mentioned, the reason you didn't see "ognodeadd" and "gids[]=" is because I realized I created the article using Drupal Navigation rather than from within the OG. Because the user is both a Group Admin *and* has authority to create articles (with the Editor role), I was able to create it from the nav instead.

Just to make sure I wasn't seeing anything different, I re-ran the test from before and selected "Create Article" from within the OG rather than the "Create content > Article" option in navigation. This is what I got:

Date: 2008-05-17 06:20:19 pm
UID: 16
Username: test_edit
Group: 234
Function: og_user_roles_all_roles
Location: 132 (then switched to 0)
group context: 234
URI: /node/ognodeadd?type=article&gids[]=234 (http://localhost/node/ognodeadd?type=article&gids[]=234)
arg(0): node
arg(1): ogaddnode
Roles Returned: (authenticated user,Editor,Group Member,Group Admin)

If I'm asking a lot of what might seem to be dumb questions it's because I'm haven't a clue as to what is causing your problem. Usually, people just install it and it works -- no one ever has a problem with the basic functionality which is failing you here. Why it's not working in your environment is a complete mystery to me. Just trying to eliminate all the possibilities.

To go back to the original question, am I understanding correctly how the module works? Can I have the permissions as I have set in PNG file, where an editor receives authority to create an article, but can only publish that article as a Group Admin within the OG?

Yes.

Yes, but only if the given permission is directly applied to the group role. If you look at the "access_control_for_nodes.png" file I attached to response #7, you'll see Writers can create article and teaser content. I removed the check for "create teaser content" for Writers and set it to Group Member. I then logged in as "test_writer", viewed the OG, and saw the writer had the option to create teaser content.

Do not understand this response. OGR does not remove site-wide roles. Permissions are cumulative. If a user has Writers role and Group Member role and Group Admin role in a group or site-wide, the user will have all the permissions of all the roles within the group. This is what you see in Roles Returned:.

If the permissions of a role aren't being recognized, this problem is outside of OGR. There is possibly some conflict with some other module which is causing the permission not to be respected. What that could possibly be, I don't know. The last similar such problem we had was with Buddy List, but that was resolved. Part of this trouble-shooting would involve temporarily de-activating other non-essential contrib modules to see if the behavior persists.

Can the Group Admin user who can not see the "Publish options" also NOT create calendar_event content or group_post content, or NOT seem to have any other permission granted by the Group Admin role? Put another way, are ANY permissions given by the Group Admin role respected within the group? Or, is "administer nodes" the only permission not working?

Oh, wait, one more thing: You should weight the OGR module heavier than your other modules so that it does it's magic last. It would, logically, need to be higher than whatever module it is that hook_alters that "Publishing options" fieldset. Try this before de-activating other modules. You can use the module weights module to do this: http://drupal.org/project/moduleweight

Do not understand this response. OGR does not remove site-wide roles. Permissions are cumulative. If a user has Writers role and Group Member role and Group Admin role in a group or site-wide, the user will have all the permissions of all the roles within the group. This is what you see in Roles Returned:.

I think there's some misunderstanding about what I meant. I wasn't suggesting OGR removes site-wide roles. I was just saying by moving "create teaser content" access from Writers to Group Members, it was then displayed as an option in the "Group Detail" block in the sidebar (listed as "Create teaser"). I think this works as I would expect it to do so.

Rather than getting too deep into trying to determine which module might be impacting the situation, I decided to take an approach of the most simple example possible. I had a clean installation of Drupal 5.7 and installed only OG, Views and OGR. Nothing else exists.

You asked the following:

Put another way, are ANY permissions given by the Group Admin role respected within the group? Or, is "administer nodes" the only permission not working?

After running the simple test above, I can absolutely say no roles are being respected within the group. I gave Group Admin 'administer nodes' and 'Create story' options, and neither are available as options. I also tried a scenario where Group Admin has 'administer nodes' and Group Member has 'Create story'. Neither one were available to users with those group roles.

I've created a series of pictures which shows the OG/OGR setup I used for the simple example above; they are numbered 1 through 7. It seems rather straightforward, so I'm not sure what the problem might be.

• 1_article_content_type: Article content type created, and set as a standard group post.
• 2_og_config: Content types set up for OGs.
• 3_access_control: Access control set up in Drupal.
• 4_og_user_roles: Assignable roles set for new OG members.
• 5_user_list: Shows test_edit user has been set to have an editor role.
• 6_configure_group_member_roles: Shows test_edit user has been given Group Admin in the OG.
• 7_create_article: No publisher options for test_edit when creating an article.

Thank you very much for your very excellent and detailed descriptions. I took the information and created the same environment as much as I could. And, was finally able to duplicate your problem.

The resolution is explained here: http://drupal.org/node/170524

You need to install the og_user_roles.user.module.5.3.patch included in latest OGR download. This patch is now part of Drupal 6 core: http://drupal.org/node/176342

A little bit more explanation of what's going on here: http://drupal.org/node/177948

So, in summary:

1. Apply the patch.
2. Go into OGR settings and place check in "Clear the cache?" checkbox.

This should resolve the problem.

Please let me know.

Thanks for the quick response. My latter point is the same user_access issue.

I don't recall what your latter point was.

Does applying the patch cause a performance hit on a larger site since the roles are no longer cached?

The patch itself doesn't. Using "Clear the cache" OGR setting theoretically should. Fairly easy to test: Turn it on and check out the response.

Looking into a way to cache og roles: http://drupal.org/node/250720

But, this particular approach creates new problems: http://drupal.org/node/252663

I patched OGR with og_user_roles.module.5.x-3.2.patch and i have some troubles with default basic group. The option "Default Non-Group Role for new users" works but the followings don't work :
- Default Basic Group Role for new group subscribers,
- Default Founder Role for users who create groups,
- Default Group Role for new group administrator.

so, i use OGR, OG subgroups and OG content type admin.

Well, I applied og_user_roles.user.module.5.3.patch and there has been some progress, but not entirely what I expected. I have another example for your review. I went back to the simple example from before, just with Drupal 5.7, OG 5.x-7.2, Views and OGR 5.x-3.1 (with patches) installed, no other modules. There are two key problems I see:

(1) OG/OGR (not sure which) allows for "Create content" options even when they are not accessible.
(2) There's a discrepancy between how OG handles the "audience" option and how OGR manages what the end user sees.

I've attached more pictures to walk through the example:

• 1_og_configuration: Created a simple content type called "Group post", available to users with the group admin and group member roles. The picture also highlights the "audience" settings and issues.
• 2_access_control: Shows additions to access control for "Group post" and "writer".
• 3_create_article_auth_user: Logged in as an authenticated user who is a group member and group admin for "A Second Public Group". "Create Article" is shown when it should not be.
• 4_create_article_access_denied: After clicking on "Create Article", I get an "Access denied" message.
• 5_auth_user_no_audience: Audience checkboxes are not shown, which is a conflict with the OG config. In OG configuration I chose not to have the checkboxes, yet it says in OG config that group admins will have them anyway? Doesn't make sense.
• 6_auth_user_edit_post: Created a new post called "Test Group post", saved it, and now in the picture I am editing the saved post. All types of issues with the Audience box. Why can a group admin automatically publish to other groups? Why does a group admin have the ability to see private groups?
• 7_private_group_has_new_post: In Step 6, I published the "Test Group post" to the private "Website Writers Group". In Step 7, I am now logged in as an admin and viewing the group home page. test_auth, who is only a basic authenticated user, is able to post to a *private* group because of his group admin role.

I really see these issues as very big problems. I believe group admins should have administrative authority over their group. They should not have the ability to see private groups, to see content types for which they have no authority, or to post to groups where they have no authority.

(1) OG/OGR (not sure which) allows for "Create content" options even when they are not accessible.

On edit form for group see:

Control group menu content links.

  Display the Create content link?
  Do you wish to display the OGR Create content link on this group's menu?

  Remove the default Create links?
  Do you wish to remove the default OG Create content links on this group's menu?

(2) There's a discrepancy between how OG handles the "audience" option and how OGR manages what the end user sees.

Your issue is with OG:
http://drupal.org/node/130601
http://drupal.org/node/164070
http://drupal.org/node/203103

OGR doesn't control anything the end user sees. It simply adds the role(s) the user is assigned in the group to the $user->roles function while in that group.

# 3_create_article_auth_user: Logged in as an authenticated user who is a group member and group admin for "A Second Public Group". "Create Article" is shown when it should not be.

Neither OG nor OGR are capable of creating roles that haven't been otherwise assigned.

I really see these issues as very big problems. I believe group admins should have administrative authority over their group. They should not have the ability to see private groups, to see content types for which they have no authority, or to post to groups where they have no authority.

The ideal situation is for site maintainers to be able to optionally not allow audience checkboxes period. To be fair, OGR is providing permissions for roles in a situation not directly supported by Drupal core or OG. If it were possible to work with the OG maintainer, then I could assure that only groups a user could post in would appear. You can read his opinion of OGR here: http://drupal.org/node/233042#comment-766034 So, the last thing I want to try is an OG patch.

I have no way to control the audience checkbox (that I am aware of) outside of patching the code. So, the best I could do, if possible in nodeapi, is prevent someone from posting outside of their group.

@sylvain@drupal.org

The option "Default Non-Group Role for new users" works but the followings don't work :
- Default Basic Group Role for new group subscribers,

I didn't test all three, but I did test this one, and it works in my implementation (OGR 3.1 with 3.2 patch - OG 5.7.2).

OGR doesn't use any OG functions other than hook_og to provide this functionality, and that hook hasn't changed.

Please describe your OGR settings, your OG settings and how users join the group(s) in question.

I made a mistake in my last post, the assignement roles are checked but they don't work.

I install drupal with only OGR 3.1 patch 3.2 and OG. I create 2 roles : admin and author. Admin role has all permissions. When I give the admin role to an user, i can see "create content" but i couldn't see "Create page" or "Create story". I give this role by using the configure use role tabs in my group with super-admin user.

I have story and page as post group and a type as group node. I can't create content in the group whereas the role admin is checked in the user role tabs.

@sylvain@drupal.org

Please see #12 here: http://drupal.org/node/258976#comment-848585

OK, the attached patch attempts to solve the latter problem described here at #16: http://drupal.org/node/258976#comment-849481

I believe group admins should have administrative authority over their group. They should not have the ability to see private groups, to see content types for which they have no authority, or to post to groups where they have no authority.

With respect to the first two issues, OGR has no authority over whether private groups or other content types are seen. In the past, OGR has dealt with the third issue by not dealing with it -- you did not allow group admins to post outside of their groups by disabling the "Audience" checkbox. This is no longer possible in OG, so the attached patch adds a new function to validate new posts against groups they are to be posted to.

It was a long road to get here, but I must thank ron_s for forcing the issue.

Apply this patch to a clean download of 3.1 release.

Addendum
=======
OOps. Guess I spoke too soon. Updating patch with previous version. Still need to work on this problem.

Addendum to Addendum
==================
Fixed.

Sorry it has taken me a bit to respond. I've reviewed your patch and it does not work. Before I get into the reason why, let me respond to a couple of your earlier comments. First, on post #17 you said the following:

On edit form for group see:

Control group menu content links.

  Display the Create content link?
  Do you wish to display the OGR Create content link on this group's menu?

  Remove the default Create links?
  Do you wish to remove the default OG Create content links on this group's menu?

This is not a viable option. "Create Article" should be available for only one group. This approach suggests every group admin would edit their group to remove all links, when in reality only "Create Article" needs to be removed. As well, a general group admin would have no clue why they even have a "Create Article" option. Asking them to do this is confusing ... it should just not be there if they don't have authority in Drupal Access Control.

Second, I reviewed the links you added about OG audience. I think at this point I've come to the conclusion that OG/OGR is not going to meet my needs. If I set access control to only allow a particular OG role to have "Create Article", only that role should have it. If a user is defined as an admin for a particular group, they should not all of a sudden have authority to edit the post and put it into a private group. What's the point of access control and privacy control if certain users can find a way around it?

My impression is OG/OGR work well if wanting to organize content into public groups, but have not yet matured when it comes to private groups/content. Also OG/OGR suffers from the same limitation that I see with Drupal in general -- there is no notion of users who can serve as admin for just one type of content or one group. If someone is an admin, they automatically can do far too much and see things they should not be able to see.

As for the patch, it does validate new posts against groups they are to be posted to, but it doesn't stop the user from posting. After I click "submit" I receive a screen that says:

Access denied

* Your Group post has been created.

I can't see the new post because it's in a group for which the user does not have access, however the content was posted into it.

This is not a viable option.

The options OGR now provide are quite viable for those who want to take advantage of the functionality they provide. The purpose was to give the end user the abilit through settings to show either "Create content" link or the invididual create links on the group navigation menu. Not to individually add or remove specific links.

"Create Article" should be available for only one group.

You mean only users in one group should be able to see it, or as a content type, it should be available only to one group?

This approach suggests every group admin would edit their group to remove all links, when in reality only "Create Article" needs to be removed. As well, a general group admin would have no clue why they even have a "Create Article" option. Asking them to do this is confusing ... it should just not be there if they don't have authority in Drupal Access Control.

I'm confused also. I must be missing the point here. "Create Article" will only appear if the user has permission to "Create Article". OGR may have it's share of problems, but creating links to create content a user does not have access to within a group isn't one of them. Have you looked into Content Type Admin?

Second, I reviewed the links you added about OG audience. I think at this point I've come to the conclusion that OG/OGR is not going to meet my needs.

Fair enough.

My impression is OG/OGR work well if wanting to organize content into public groups, but have not yet matured when it comes to private groups/content.

I can't speak for OG contributor, but OGR was written specifically to organize content into private groups. And it currently does just that on several sites. With TAC/OG integration, and modifications to remove the group audience checkbox, it was written to fine tune access to specific content by specific users. While I apologize that it has not worked for you, I can testify that it does work in this context, and very well.

If someone is an admin, they automatically can do far too much and see things they should not be able to see.

Depends upon your configuration. By assigning admins group roles which are viable only within the group context, we are able to limit what they are able to do and see. You brought up the one weakness that existed, and that is because neither OG nor Drupal was designed to support assignment of roles by group. I think it was a mistake for OG to allow group admins to always see the audience checkboxes, but that's just me.

If a user is defined as an admin for a particular group, they should not all of a sudden have authority to edit the post and put it into a private group. What's the point of access control and privacy control if certain users can find a way around it?

Agreed. I've lobbied against it in the OG group, and have done what I can to prevent it in OGR.

As for the patch, it does validate new posts against groups they are to be posted to, but it doesn't stop the user from posting. After I click "submit" I receive a screen that says:

Access denied

* Your Group post has been created.

You'll have to explain how you arrive at this. Where OGR returns "access denied" it does not continue on to add a node. Here is the line OGR returns if you don't have access to post into a particular group:

                  form_set_error('og_groups', t('You do not have permission to post this content type (' . $type . ') into Group: <strong>' . $group_name . '</strong> (' . $gid . ')'));

No matter how many times I hit the submit button, I cannot post the content if I'm trying to post to a group that I do not have permission to post to.

There is no doubt that Drupal, OG and OGR suffer from many of the issues you point out. But, they also work very well for a good number of the people who utilize them. I'm sorry I've not been able to unravel the issues in your case.

@ron_s, your configuration, and other modules installed, have a great deal to do with expected and unexpected behavior.

I tried to duplicate the scenario you mentioned regarding "Create Articles". The only way I could get close to what you described was by giving a user the role "administer nodes" within a group. Suddenly, "Create" links that he should not have access to appeared in the group navigation menu. Clicking on one, he got the "Access denied" message. But, did not receive a node edit form and was therefore not able to click on "submit". This should not happen, agreed, but some combination of Drupal core, OG and OGR makes it possible.

The point being that Drupal is an open source project, consisting of applications provided by people from all around the world designed to solve a variety of problems in a multitude of situations. Everything doesn't always work as expected. We attempt to overcome this by working together, as you've done here, to identify and rectify issues, one at a time.

Thank you for your time and effort in pointing out the issues here. I would encourage you to continue doing so. This is how we will make the application fit your needs.

The original issue, OGR not working with OG 5.7.2, is fixed. http://drupal.org/node/258976#comment-846045

The first subsequent issue, basic OGR functionality not available, was resolved by "Clear the Cache" setting. http://drupal.org/node/258976#comment-848585

The next subsequent issue, ability to post into groups one does not have permission to post into, as also been fixed from the standpoint of OGR. http://drupal.org/node/258976#comment-850935

Any remaining problems should be posted in a new issue. Releasing OGR 3.2 shortly with the modifications to date. If there are continuing issues, we can sort them out from there with a solid code base to work from.

@ron_s, your configuration, and other modules installed, have a great deal to do with expected and unexpected behavior.

Of course modules and configuration have to do with unexpected behavior, but if you remember I'm doing all of this on a stripped-down implementation. The only modules installed are OG, OGR and Views. The whole goal in doing so was to troubleshoot without conflict.

I tried to duplicate the scenario you mentioned regarding "Create Articles". The only way I could get close to what you described was by giving a user the role "administer nodes" within a group.

I think all of this boils down to "administer nodes". In posts #6 and #10, you validated that giving "administer nodes" to a group admin would allow for publishing rights in the group (I know it was a while ago, but the whole reason for this discussion was the need to give publishing rights to Editors.). However giving "administer nodes" also provides an unintended consequence. Administer nodes allows a Group Admin to edit an existing post and save it into a group for which he or she has no access. The resulting message says "Access denied", but the post gets moved.

Clicking on one, he got the "Access denied" message. But, did not receive a node edit form and was therefore not able to click on "submit".

What you need to do is save a post into a group for which you have access, *then* edit the saved post and change the Audience settings to a group where you don't have access. This has to be done with the "administer nodes" access control given to the Group Admin. The Group Admin will then get an "Access denied" message, but the post is still moved to a group where the user has no access.

This should not happen, agreed, but some combination of Drupal core, OG and OGR makes it possible.

I looked into OG/OGR because I wanted a solution to allow Editors to have all the authority of the "administer nodes" access control but ONLY for Article content types. We can get this to work, but not without the side-effect of Group Admins being able to edit posts and move them to groups with no access.

The root of the problem is "administer nodes" and how it works in Drupal core. It is too powerful of an access control to assign to anyone other than those who can see everything, including private groups. What I strongly need is administer nodes at a more granular level. I need publishing authority for those within a specific role (Editors) who author/review a particular content type (Articles) ... without the ability to reassign content to audiences where there is no authority. Unless you're aware of something, I'm not sure there is a solution that currently exists to meet this need.

Thanks for reminding me of the root issue here. I might just have a solution for you. Check out this issue: http://drupal.org/node/262127

What I did was to create some hook_nodeapi code for an internal, custom module to work with the save_as_draft.module (http://drupal.org/project/save_as_draft) to allow a user to save real drafts (i.e., unpublished nodes). The actual code I'm using also includes the OG code to send notification when the node is published:

/**
 * Implementation of hook_nodeapi().
 */
function lesspaper_nodeapi(&$node, $op, $teaser = NULL, $page = NULL) {
  switch ($op) {
    case 'submit':
	  if (module_exists('save_as_draft')) {
	    if ($node->save_as_draft == 1) {
	      $node->status = 0;
		}
	    // If save_as_draft is clicked off and the publish status is 0
		// and this user does not have the 'administer nodes' permission,
		// then change publish status to 1
	    if ($node->save_as_draft == 0 && $node->status == 0 && (!user_access('administer nodes'))) {

	      $node->status = 1;

			// Perform the following to send og notifications (for now)
            $skip_notification = FALSE; 
            // Any module that returns TRUE from its hook_og_notify($node) will prevent sending notifications.
            // og2list and og_subscriptions use this to send own notifications.
            foreach(module_implements('og_notify') as $module) {
              if (module_invoke($module,'og_notify',$node)) {
                $skip_notification = TRUE;
                break;
              }
            }
          if (!$skip_notification && $node->status && og_is_mail_type($node->type) && $node->og_groups) {
            if (module_exists('job_queue')) {
              $description = t('OG: notify group members about node %nid - !link', array('%nid' => $node->nid, '!link' => l($node->title, "node/$node->nid")));
              job_queue_add('og_mail', $description, array('node', $node->nid));
            }
            else {
              og_mail('node', $node);
            }
          } // end og notification stuff

		}
	  }
      break;

    case 'update':
      if (isset($node->original_node)) {
        // Update node table's vid to the original value.
		// But, do not update the $node->status to original value.  Use the new status instead.
        db_query("UPDATE {node} SET vid = %d, title = '%s', status = %d, moderate = %d WHERE nid = %d", $node->original_node->vid, $node->original_node->title, $node->status, $node->original_node->moderate, $node->nid);
        }
      break;
  }
}

I'm not sure about what else you wanted your editors to be able to do, but the above code (working in conjunction with the save_as_draft.module) will allow them to publish/unpublish nodes *without* requiring the "administer nodes" permission.

Thanks for sharing, I will check this out. Maybe this is addressed in the code or module, but there's one other aspect of "administer nodes" besides publishing: revisions. Any user with "administer nodes" can:

• view a list of revisions under the node "revisions" tab,
• revert to older revisions, and
• create new revisions.

This is based on whether or not a user has "view / revert revisions" authority in the Access Control (in addition to administer nodes). It says on the main page of the Save As Draft module that it creates future revisions. Does this mean the user can see the full list of them?

Oh one other question ... the need is only for Editors and the Article content type. Seems like "Save As Draft" applies to all content types on a site?

the need is only for Editors and the Article content type. Seems like "Save As Draft" applies to all content types on a site?

Not true. I might need to change *my* code somewhat (I assume all content types will use the feature), but you actually configure save_as_draft for each of the content types you want.

It says on the main page of the Save As Draft module that it creates future revisions. Does this mean the user can see the full list of them?

That I don't know. I only use the module for the one single purpose of allowing users to publish/unpublish content. You'll have to pow-wow with the save_as_draft folks to figure out the revision stuff.