Improper use of "administer nodes" permission in code & documentation causes confusion

I've been wrestling with configuring the Content access module settings for certain roles in a site I'm building and it seems to me that the Content access module is misinterpreting the meaning of the Drupal 7 permission "Administer content" (in code called "administer nodes"). To explain what I mean, I'll compare the behavior of a particular setup with and without Content access enabled.

Scenario 1: Standard Drupal

• In an out-of-the-box Drupal 7 install, add a role called "Article manager".
• Go to the Admin permissions page (/admin/people/permissions).
• Ensure Authenticated users have the "View published content" permissions.
• Give "Article manager" the following:
• Use contextual links
• Administer content
• Access the content overview page
• View own unpublished content
• Article: Create new content
• Article: Edit own content
• Article: Edit any content
• Article: Delete own content
• Article: Delete any content
• Access the administrative overlay
• View the administration theme
• Use the administration toolbar
• Create and log in as a user with only this "Article manager" role.
• This new user can add and edit any Articles, whether they created the node or not.
• This new user cannot add or edit any Basic page content, but they can view all published Basic page content.

Scenario 2: With Content Access

• Continuing with the example above, install and enable the Content access module.
• Rebuild permissions
• Now visit the Article Access Control form (admin/structure/types/manage/article/access).
• You will notice that the Article manager role shows all permissions checked, but check boxes are disabled. In this case, those check marks reflect the permissions we've given the role, so there is nothing obviously wrong here.
• Now visit the Basic Page Access Control form (/admin/structure/types/manage/page/access).
• This form also shows all permissions enabled for the Article manager role. The only check box that should be checked is the one for "View any page content". Because these are disabled, you cannot change them to remove the unwanted permissions.
• Things get a little more complicated now. At this point in my test, despite the fact that this form implies the Article manager has full access to all Basic Page nodes, I am still not able to create, edit or delete basic page content.
• However, once I click the Submit button on the Basic Page Access Control form, the Article manager does get the implied permissions and I am able to create, edit and delete Basic page content.
• One of the reasons this is so confusing is that by disabling and checking all permission for this content type, Content access isn't truly displaying the internal permission for this role. It is implying permission that may or may not be set and are difficult to understand without actually trying to edit content.
• Note: if you remove the "Administer content" permission from the role, Content access no longer disables the check boxes and you can see and edit the actual permissions for this user. Unfortunately, if you want the role to be able to publish the content or change the owner then that role needs to have "Administer content".

After spending some time playing around with permissions and digging through the code, I realize that the interaction between Content Access and standard Drupal 7 permissions is complex and for some cases there may not be an obvious correct behavior. However, I do think that Content access is doing the wrong thing in this case. In general an admin should be able to create a role that has administrative access to one content type but not others; it is possible in out-of-the-box Drupal 7. Finer-grained controls of that access is what makes Content access so valuable, but in this case it thwarts rather than enables.

I think the key problem is that Content access is misinterpreting the "Administer content" permission to mean that the user has global content access. That is why all content Access Control pages show all permissions enabled but un-editable for roles with "Administer content" permissions. "Administer content" does not mean that the user has global access to all content (as demonstrated in out-of-the-box Scenario #1 above).

I suggest that instead of assuming "Administer content" means global content access, this module should instead check the "Bypass content access control" permission, which really does provide global access to all content. I'll post a patch with this change in the comments.