Node permissions are ordered oddly

I like this arrangement and text...

Can we also add an explanation to the Administer Content permission? Given the "bypass node permissions" permission, I for one have no idea what administer content does any more.

[greps through the code]

OK. It looks like Administer Content (aka 'administer nodes') gives you permission to:
- View, revert, delete all revisions
- See edit/delete links on the book admin page [this is probably a bug -- shouldn't it be bypass node access? -- see theme_book_admin_table -- and why is it in a theme function anyway?]
- See the update options drop-down on the node admin page (bulk update options)
- When editing a node, override: creating a revision, author field, publishing options (published, sticky, etc.)
- Edit any poll node [this is likely a bug -- see poll_form() -- shouldn't it be bypass node access?]
- Set up initial poll vote totals

What a mess...

Also, I think the bypass permission gives you permission to create all content, besides view, edit, delete.

Just one other note on the 'administer nodes' permission:
That bulk operations thing -- whatever any module adds in there, someone with 'administer nodes' permission can do, without further permissions checks (unless the module puts a permission check in the function explicitly). So anyone with 'administer nodes' can delete any node (this is defined by the node module), as well as the publication and sticky options. I don't see any other operations defined in core.

EDIT-ADDED:
That's actually interesting, because otherwise I don't think that someone with 'administer nodes' permission has permission to delete a node, such as seeing the delete button on the node edit page.

Subscirbing...

OK. I'm happy with the above patch, and fine with RTBC, but maybe a UI or Usability person should review it?

I'm in huge favour of this beauty...
Always have problems finding the right permissions, this makes everything much easier and cleaner!

Works for me and +1 for the order

+++ modules/node/node.module	10 Mar 2010 17:42:35 -0000
@@ -1420,15 +1424,14 @@ function node_permission() {
+    'access content overview' => array(
+      'title' => t('View the content overview page'),
+    ),

I think if we use 'View' in the description, we should also use 'view' in the permission name. Mingling 'view' and 'access' is a tiny bit confusing.

Hmmm.... We have other permissions that have historically been named "access *" internally, and it was decided by the UI folks that it was less confusing for the site manager/admin if they were called "View *" on the UI. The internal names were not changed because everyone agreed that as few changes in programmer-facing permission names as possible would be a good idea. Such as, from various hook_permission() implementations:

    'access content' => array(
      'title' => t('View published content'),
    ),
    'access user profiles' => array(
      'title' => t('View user profiles'),
    ),
   'access comments' => array(
      'title' => t('View comments'),
    ),

This particular permission is, I believe, new to Drupal 7, so its internal name could be changed with few consequences, but actually, "access" is more consistent for the internal permission names I think...

If we are going to change the admin-facing name, though, and this patch does (it was previously "Access" for the human-readable name), I guess would vote for "Use the content overview page", to be consistent with:

    'access administration pages' => array(
      'title' => t('Use the administration pages and help'),
    ),

But your patch did change the human-readable name from "Access" to "View".

#1: drupal.node-permissions.1.patch queued for re-testing.

agreed. Thanks!

still applies.

Since drupalcon SF we have a rtbc queue problem. This leads to patches being green for ever. This is one of them. Great patch but not critical so no attention for the next months?
When will be the time for these kinda patches?

*** please commit this ***

This patch doesn't get attention because it is less important. We should focus on bug fixes, and critical bug fixes in particular. It is not because a patch is green that it should be committed.

@sun why is this closed - won't fix?

Just because someone is upset doesn't mean we have to mark something as won't fix. Someone else is more than welcome to pick up work on a ticket.

I think this makes sense, and this seems like the right time to make the change.

Committed to HEAD. Thanks!