Rewrite permission titles and descriptions

-      'description' => t('Access the site-wide dashboard. Modifying the dashboard requires the "Administer blocks" permission.'),
+      'description' => t('Note: modifying the dashboard requires the !administer_blocks permission.', array('!administer_blocks' => l('Administer blocks', 'admin/config/people/permissions', array('fragment' => 'module-block')))),

this is a big no-go, ur causing the 'Administer blocks' bit to be untranslatable

forgot status

https://addons.mozilla.org/nl/firefox/addon/1146 for full page screengrabs

I have reviewed this patch. (In order to do so I activated all modules and used the dev version of devel to generate sufficient content).
I have doublechecked for language errors with focus on interpunction.
I have doublechecked for translation issues (see comment #2 by seutje).
I checked the functionality of the links:
- at line 143 (dashboard module).
- at line 636 (user module).
I checked the functionality of the taxonomy label.

The patch serves its purpose.

good work. A lot of the descriptions did not make sense and so it is good they are removed, and many are clarified a lot in the patch.

Committed to CVS HEAD. Thanks!

Award winning patch.

errr.

Committed to CVS HEAD. Thanks. But alas, no award for this patch. Happy to give you an award for other patches though. ;-)

This is a big change that went in without much discussion. The original change, that is - not @sun's award-winning followup :)

It should be discussed more. While there are definitely some great changes in the patch, the overall result is a near-rollback of the permission descriptions, which were introduced in Drupal 7 for an important reason.

In addition, the actual effect of this patch is to make many of the permission titles longer, which seems backwards. The idea is supposed to be that the permission titles are very short because everyone is supposed to read them, whereas the descriptions are intended to be ignored except when the user needs to focus on and carefully understand that particular permission. We already have a "hide descriptions" link on the permissions page and other methods could be explored for themes to make them less prominent, so making the page shorter is not a good reason to remove them.

To take a couple examples from up near the top of the patch of why this is problematic:

     'administer news feeds' => array(
       'title' => t('Administer news feeds'),
-      'description' => t('Add, edit or delete news feeds that are aggregated to your site.'),
     ),

...

     'administer blocks' => array(
       'title' => t('Administer blocks'),
-      'description' => t('Select which blocks are displayed, and arrange them on the page.'),
     ),

These deletions are fine for experienced users, but for someone who is still shaky on what a "news feed" and "block" even are, they absolutely need some kind of extra text to remind them.

***

In addition, there are a few bugs here.

1. -    'title' => t('Administer filters'),
   -    'description' => t('Manage text formats and filters, and use any of them, without restriction, when entering or editing content. %warning', array('%warning' => t('Warning: Give to trusted roles only; this permission has security implications.'))),
   +    'title' => t('Administer and use any text formats and filters'),
   +    'description' => theme('placeholder', array('text' => t('Warning: This permission may have security implications depending on how the text format is configured.'))),
   

   Seems like a copy-paste error: The "warning" text should not have been changed, since the security implications of this permission do not depend on any one particular text format.

2. -      'title' => t('Administer software updates'),
   -      'description' => t('Run the update.php script.'),
   +      'title' => t('Run software updates'),
   

   There was a long discussion at #67234: Update script access rights of why it is appropriate to put "administer" in this permission name.

   Also (not really caused by this patch), we need a new description here since it needs to be updated to reflect the way the update manager uses this permission to allow new modules to be uploaded to the site.

3. The human-readable permission titles are often used in various other places in core (e.g., help text). This patch did not update any of those to reflect the new permission names. I'm not sure how many there are, but, for example, I know that the "Administer software updates" example mentioned above was not updated, because it is still appearing in user-facing text in update.php.

WTF?

If I wouldn't know that I can't, then I would only assign the one without approval. And even knowing the logic behind those labels, I took me a couple of seconds to understand what I want to do.

If the "Administer..." permissions are essentially meta-permissions -- that is, checking "Administer xyz" automatically checks each of "View xyz", "Post xyz", and "Edit xyz", then we really do need to include that fact in the permission descriptions.

To accomplish this,

Option 1 [easier]: Description for meta-permission "Administer xyz" should simply list which permissions it includes, similar to the initial patches here, but preferably with the conjunction "and" instead of "or".
e.g. "Add, edit, and delete news feeds that are aggregated to your site."
Where the Administer permission includes any permissions that subsume each other, list the least restrictive one.
e.g. "View and add comments to content (approval not required)."

Option 2: Just as the module listing page has "depends on" and "required by", add an extra tiny note to each permission that gets automatically checked (or unchecked) by an larger meta-permission. For example:
Administer comments and comment settings [x]
View comments [x] (included in "Administer comments and comment settings")
Ideally, checkboxes would never be disabled, but unchecking "View comments" would also automatically uncheck "Administer comments" while leaving "Post comments" checked.

This is not critical.

All previous patches have been committed, and a rollback is under discussion but no patch yet...therefore setting to "active"

#16: 1 and 2 are changed in CVS HEAD. 3 is probably addressed as well by now, but if anyone feels a compelling need to grep the old permission names through core, please do.

#18: comment permissions are being addressed in #438224: "Post comments without approval" permission name is completely misleading, Administer software updates had gotten back in place already.
#19: hierarchical permissions for D8 are being discussed in #381584: Hierarchical Permissions System.

Therefore, setting this back to fixed. I suggest that a new issue is opened if there are more follow-ups needed.