Optionally show the machine names on the permission page

Good idea, but I think it will be better to introduce this feature in more appropriate module. Take a look at Fast Permissions Administration for example.

And yes, it can be easily done with Javascript, without preg_match.

We already have mouse-over hints to display that information. This is enough IMO, and I don't like adding more always-visible stuff to the badly overloaded permissions page:

BTW, there's trailing white space:

+++ b/devel.module
@@ -1954,3 +1954,28 @@ function devel_form_system_modules_alter(&$form, &$form_state) {
+ * ¶

@salvis, I didn't know that we already have something like this. Could you please explain how to turn it on? I don't see any stuff from your screenshot on latest devel 7.x-1.x.

Thanks!

It's the Display machine names of permissions and modules setting.

But you can't copy and the past the machine name to your IDE

True, but that's not enough of a reason to further mess up the permissions list.

It's the Display machine names of permissions and modules setting.

Oh! Sorry, I didn't notice that option. Is this option really helpful or maybe we can make it better? When I need permission machine name I usually go to permissions page, inspect checkbox and copy it's value.

Let's see how Drupal core do:

Isn't it nice and tidy?

We can rename option and do the same:
Permissions (tested with and withoout fpa, admin_menu):

Modules (tested with and withoout admin_menu, module_filter):

Initial patch attached without PHP comments modification. If it is not a mess, we can finish it after @salvis review.

@RoySegall, sorry for my English.
Shortly, I suggested a patch based on your idea and Drupal core styles. Now Devel's option "Display machine names of permissions and modules" allows to print machine names instead of adding title attribute.

Thanks for attaching that screenshot from the content types page. I see no reason why content should get this treatment but not permissions. So, I think this is a valid feature request and that Drupal core should implement it. Moving issue from devel to drupal core.

if core rejects this for some reason, we can move this back to devel.

It's not just the permissions machine names, but also the module machine names. I like seeing those on both the modules and the permissions pages (the screenshots missed the latter), because they can differ quite a bit from the user-facing module names.

The same patch as #8, but for Drupal 8.x core.

The patch #15 still applies correctly.
Any thoughts about that?

#15: drupal-core-show-permission-machine-name-1734534-15.patch queued for re-testing.

#1892872: Add title attribute to modules administration page closed as duplicate.

The same patch again.
New screenshots:

@RoySegall,
#14:

It's not just the permissions machine names, but also the module machine names.

Sounds like a task to me.

I agree w/ task category, tagging as Usability.

I can see the value of doing this on the modules page, esp. since it's hidden by default and only available if you explicitly ask for more details. It's also something useful for site builders to know at various points (e.g. upgrades, troubleshooting searches...). The permissions page OTOH clutters thing up quite a bit, unfortunately. :( Especially since in many cases the human-readable vs. machine-readable will be exactly the same, just lowercase. And I can't really think of a site builder use case for exposing machine names for permissions; this seems much more like a developer-facing feature, so maybe a patch to Devel module instead?

Oh, lol ... it started there. ;) Funny.

Yes, of course, but what's the use case for showing this developer-focused information on a predominantly site builder-oriented screen (the permissions page gets visited every time a module is enabled, every time a new role is created, etc.)?

+1 for all the changes done in #20. And can we accommodate comment from #1848064-50: Allow to filter modules by arbitrary search strings on the Modules page?

Here's a plain reroll of #20

I feel that the machine name besides every permission is quite intrusive if you're actually not interested in that information, it might be confusing, and clicking on hide description doesn't hide this.
For the record, currently Devel shows the machine name on top of the permission in a tooltip.

I like what the modules page does with a fieldset on the description... what about adding a "See description link" that expands the description, machine name and warning for the permission page?

#30: drupal-core-show-permission-machine-name-1734534-30.patch queued for re-testing.

Visually looks good, and tested it on d7 w/ patch -p2 < drupal-core-show-permission-machine-name-1734534-30.patch and works. It defiantly adds more visual clutter though, but defiantly useful for developers.

30: drupal-core-show-permission-machine-name-1734534-30.patch queued for re-testing.

This probably belongs in devel module rather than core.

Renaming this since we already show machine names on the module page now.

Updated patch. This would be a great UX improvement. For translated pages, it's just really really bad UX that you can not search up the string you know should be there (since it is translated).

#47 installs nicely and works perfectly.

Thank you!

Feels like a great improvement to DX to me. Had no idea where to find the permission names I needed to use.

@webchick's question regarding whether this is warranted in core for the permissions page is not yet answered

I'll ping the product managers

Yeah, sorry, I still agree with 6 years ago me (funny that :P) that a) this clutters up the page tremendously and b) there hasn't yet been a defined use case for why a site builder (this is a site builder page) needs to have these machine names in their face all of the time. If you want additional opinions, you could also bring it to a UX team meeting on a Tuesday, but they'll probably have similar feedback.

A compromise could be a tooltip approach that is screenshotted in #3. Then the developer use case we're trying to solve of "I need to quickly know the machine name of this particular permission because it might be different from what's printed here" could be solved, without making the most visually heavy page in Drupal even heavier.

I agree that those use cases are just small convenience things, and might not warrent what may seem like cluttering. But there is one other use case that I tried to shortly describe earlier, but I will be very elaborate here :)

Imagine Robin, a developer. They just got a ticket saying administrators can not access a certain path. Now Robin is a seasoned Drupal developer, and suspects this might be a permission problem. They quickly find the permission in question:

Now, with this patch applied, all they have to do is copy that text, CTRL-F on the permissions page, and immediately see the role was missing the permission. Bug solved in under 2 minutes :)

Now let's look at the debug session without the patch applied:

Robin goes to the permissions page, but the page is in Norwegian. So even if they suspect the string might be something like "Administer taxonomy" they have no idea what is going to be displayed here:

As I said, they are a pretty seasoned Drupal developer. They suspect this permission might come from the taxonomy module. So they open the file taxonomy.permissions.yml:

administer taxonomy:
  title: 'Administer vocabularies and terms'

Now I actually wanted to make another point by using this permission. And that is the fact that knowing the "machine name" of a permission does not equal knowing what will be listed in the permissions page. So even if the site was in English I would probably have to open this file to find out what the actual permission was. So it is not just an issue with multilingual sites. But I digress from our story of the developer with the ticket. Robin now knows the English string for the permission. They go to "Translate interface", search up the string, and finds out the Norwegian translation is "Administrer vokabular og termer". They can now check the permission page. And surely enough, the role was missing the permission.

Bug solved for Robin, but not so easy. The steps needed was:

• Look for a string they know exists, but not find it
• Find the file containing this string
• Find the English human readable version of the string
• Find the Norwegian translation of the string
• Now go back to step 1 and find the representation of the string they knew existed all along

Robin ponder the complexities, and either use that new found frustration to create cat memes of the Drupal permission system, or create a patch :)

I also want to point out: This is when you are a seasoned Drupal developer. I can only speculate how one would struggle if they did not have the knowledge required to end up with the correct string. I am assuming people would just add permissions until it worked. Which is not something we want to encourage.

Hope that can justify adding more things to a very, very long page, and that it would solve things more than clutter, hopefully.

I mean, as a seasoned developer myself, I would just view source on the permissions page and cmd+F for "administer taxonomy" and tada.

But as said, I don't have a problem with this being added to Devel module as a feature, as I can see its use for the developer audience. If you want it in core though, we need to always prioritize the least technical users' needs, and in this case it's the site builder vs. the developer.

Would a tooltip help Robin in this case? He (or she ;)) could probably narrow it down to something in the "Taxonomy" group and then it's another 3-5 seconds to hover over a few of the possible options there.

Devel rarely mucks with the HTML/forms of Drupal pages. It just adds pages/blocks/menus. I'm not inclined to start doing that as HTML/forms are not APIs and can change at any time.

How about an advanced setting you can turn on somewhere in core to opt in to seeing the machine names?
(e.g. Add a "Development" field group at /config/people/accounts with a checkbox for seeing this?)

If you want to add an ideas queue issue for putting a Devel module "lite" in core, be my guest. :) But we're not adding all of that here for this particular screen/feature, IMO.

@webchick re: #58: I'm not proposing an entire "devel lite in core", I'm proposing a single checkbox on an existing settings page to enable this functionality to aid developers. But that's clearly "won't fix" already, so I won't spend the effort.

I'm leaning toward "won't fix" for this issue, since it seems neither core nor devel will accept this feature. I don't want anyone else to waste any more time on it if it's doomed. @webchick: would you be willing to do that if that's your assessment as a product manager?

I still seem to not be getting an answer to the "compromise" question, which is whether we can do a tool tip on hover instead. I feel like that would solve everyone's problem. The permissions page is no less cluttered for site builders, but developers have an easy way to determine the machine name of a permission without resorting to digging around in source code.

That approach may have accessibility concerns, however, so tagging.

@webchick re: #60 and the "compromise" solution, I don't think that really helps. If I'm "Robin" from #53, and I know the machine name I care about is "administer taxonomy", I definitely do not want to hover over 300+ different rows searching for a tool tip that shows the text I'm looking for. I want to search for it, but I can't search if it's hidden in a tooltip.

If I'm Robin, I'd much rather enable a checkbox on the appropriate config form (*cough*) ;) that reveals all the "clutter" on the permissions page so that I can do a simple cmd+f, paste "administer taxonomy" and immediately go to the row I need to mess with.

Another idea: what if it's a JS toggle thingy along the lines of "show row weights" vs. table drag? By default the machine names are hidden via CSS, but if you click the "show machine names" link at the top of the page, voila! Happy Robin! Happy webchick? ;)

Cheers,
-Derek

The toggle link could be next to the existing "Hide descriptions" link...

> I still seem to not be getting an answer to the "compromise" question, which is whether we can do a tool tip on hover instead.

Another reason the tool tip is no good is that you can't copy-paste the tool tip text.

re: #65: Agreed.

Even though this is technically NW to make "optional" a viable patch, I'd still like product manager review before anyone actually spends more time working on this. Let's agree on a plan before any more coding. Back to NR.

Thanks,
-Derek

Cool, I appreciate the brainstorming.

Yep, good points for why a tool tip doesn't work for Robin. This JS toggle option still adds more stuff (YET ANOTHER CHECKBOX LOL :)) to the permissions page which we'd really rather not do, though. :\

Not necessarily ruling that suggestion out, but just to counter-brainstorm a bit. ;) You know how we have a "Field list" page in the admin/reports section, which provides an overview of field usages? Would a similar "permission overview" page with the machine names exposed on it work for that? That would clearly be targeted at the developer/more technical site architect vs. the "day to day maintenance of site" audience.

We could also take this brainstorming to the weekly Drupal UX team call, which happens Tuesdays at 12:30pm Pacific time in #ux on Slack.

Counter-counter-brainstorming... ;)

This JS toggle option still adds more stuff (YET ANOTHER CHECKBOX LOL :)) to the permissions page which we'd really rather not do, though. :\

#64 proposes: Adding 3 more words ("Show machine names"), right next to 2 existing words ("Hide descriptions") that provide very similar functionality, and then make this form a lot easier to use for developers.

To avoid the 3 new words (IMHO, an extremely small price to pay), #68 proposes an entirely separate report, new route (requiring entirely new tests, tons of sign-off, etc). The result of the separate report is a "translation" page that converts a string you know you're looking for into the string(s) that will be visible on the form you actually have to navigate to set the right permissions. Robin now has to have 2 windows open, and switch back and forth, copy machine name, paste into the search box (browser or native) on the translate report, copy the resulting display name, toggle back to the form they have to use, search + paste display name, lather, rinse, repeat. Meanwhile, non-developer site admins have to wonder WTF this "report" is telling them. We get to bikeshed all the usability WTF of a "report" that doesn't report anything, but is simply a translation tool for developers.

If we're going to do all that (ugh), let's add devel-lite to core. ;)

Or let's not. Let's just add "Show machine names" to the permission page. :) Most people won't even notice (I nearly missed "Hide descriptions"), the ones who care will be grateful that it's a simple toggle to easily and elegantly solve a known DX-wtf that's pissed them off for (at least) 7 years...

Cheers,
-Derek

Haha, fair. Yeah, it's possible a toggle link in the same style as "hide descriptions" could work. I'll raise it on the UX call tomorrow if there is time.

Ok, reports back from the UX meeting! https://youtu.be/EwnuMzqE9mw?t=1979 is approximately when this discussion starts. (Sorry, it's slow to get going because I can't run a meeting and prep a presentation at the same time ;))

Sounds like there was agreement that the extra toggle should work! Suggestion was though rather than putting it to the side, put it down below the title so as to make it more scannable, so like:

Hide descriptions | Show machine names [should be off by default]

---

Administer blocks
administer blocks

...

Administer comment types and settings
administer comments
Warning: Give to trusted roles only; this permission has security implications.

...and so on.

Also crediting @AaronMcHale and @dww for their work on the compromise! (Others I'm sure need credit as well; just handling the UX credit for now.)

Re: #71: Fantastic! That looks exactly like what I was trying to propose in #64, what I had added to the summary as option A. Sorry if that wasn't clear, already.

Yay, so I'm crossing off "Decide on an approach" from the remaining tasks. Progress! I think we've rescued this issue from the jaws of "won't fix". Huzzah. :)

@webchick: I'm assuming you're not planning to do any of the rest of those steps, and I don't think it requires any further product manager review (at least not at this time), so I'm unassigning you for now. If anyone plans to work on the patch and convert #47 into the proposed toggle, please assign yourself so no one duplicates effort.

Thanks, all!
-Derek

Fantastic!

I think I can speak for Robin (very glad my gender neutral name got recognition through a he (or she) comment btw) and say that they are very happy with this. Whipping up an initial patch.

Initial patch. My javascript is probably not modern enough to do things correctly, but this certainly works :p

Animation of the result also attached. Was it something like this you had in mind?

Great, thanks! Almost there.

1. The toggle should be inline with the existing one, as in #64 and #71, etc.
2. I don't think we need the "Machine name:" label. Again, see #71.
3. My JS also isn't very modern or slick, but I wonder about doing this with something else. What about #states? I guess it doesn't have a notion of "I've clicked a link" in the same way. Or this?
   

    $form['system_compact_link'] = [
      '#type' => 'system_compact_link',
    ];
   

4. Tests.

Thanks!
-Derek

Might be a good idea to store the user's choice for this in the same magical way that 'show row weights' is stored, so it persists between page loads.

Great to see progress on this, very exciting!

Some more notes on the patch itself:

1. +++ b/core/modules/user/src/Form/UserPermissionsForm.php
   @@ -108,6 +108,10 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   +      '#template' => '<div class="toggle-machine-names"><a href="javascript:;"> {{"Show machine names"|t}}</a></div>',
   

   Since this link only works if the client has JavaScript, it should have the "js-show" class.

2. +++ b/core/modules/user/user.permissions.es6.js
   @@ -68,6 +75,23 @@
   +      $machineNames.hide();
   

   Because the permissions page can get very (!!!) large, we should try to avoid any JavaScript that reacts to each permission on page load as that will lead to suboptimal performance and browser repaint with a few thousand permissions. Instead I think the machine names should just be hidden by default via CSS, i.e. the "hidden" class.

Awesome suggestions and feedback. Unassigning for now, if someone wants to keep this going in the next days :)

I had created this duplicate issue https://www.drupal.org/project/drupal/issues/3413413, completely missed this one.

Tried to patches submitted above but were failing therefore created a new patch and a MR for the same by using mostly the changes from https://www.drupal.org/project/drupal/issues/1734534#comment-13222756

Assigning for review.

Thank you.

Forgot to attach the patch file in the previous comment, attaching now.

Previously tagged for tests which are still needed.

Please take a look at the tags before moving to Needs Review thanks!

MR has a failure too, no need to attach a patch with MRs a patch file can be generated from the MR. Now we have patches and MRs which slows reviews.