What is the problem to solve?
During
📌
Drupal Usability Meeting 2024-02-09
Needs work
(while reviewing an unrelated issue) it was noted that the "View the administration theme" permission is increasingly less relevant and more likely to result in confusion.
The description text of this permission reminds one of a time where Drupal sites did not have a separate administration theme by default "This is only used when the site is configured to use a separate administration theme on the Appearance page.".
In modern Drupal, sites almost always have a separate admin theme and increasingly this will be Claro, which ships with Core and is on by default. So when the administrator is setting up additional roles, they likely want those other roles to be able to access some areas of the admin UI (for example content creation). A situation could easily arise where the administrator doesn't realize they need to enable this permission on each new role and so could easily be confused when they discover that those new roles do not see the admin theme when accessing the admin UI.
With work being done on the new Navigation, the initial work on Dashboards, changes to the Field UI, among others; We are increasingly taking a more thoughtful approach with the admin UI, and are designing with the assumption in mind that the site will be using Claro (or Gin).
With the concept of the admin UI becoming increasingly coupled to the admin theme, the idea that a user who has access to admin UI pages would not be using an admin theme, is no longer something that we design for. In other words, we now design with the assumption the user is using Claro, not the other way around.
All this is to say, the out-of-box core experience should enable and showcase, not hinder, the admin UI. The "View the administration theme" permission could be seen as a barrier to that, adding an easily forgotten extra step that the administrator has to go through when creating a new role. The result of which could be confusion and frustration when the administrator does not realize they need to enable this permission on each role. Contributing to the perception that Drupal is not easy to use of the box.
Who is this for?
This is for site builders and administrators.
Result: what will be the outcome?
The proposal is to deprecate this permission, and move it to a contrib module.
As describe earlier, this permission is increasingly becoming an edge case. While there may be use cases for this permission, it is likely that those would be satisfied by moving this permission to a contrib module. The idea being that, because (say) 90% of sites will always have this permission on for (almost) all roles, for the sites who explicitly want to "turn off" the admin UI for a specific role, that would be a known business requirement and so those sites would actively seek out a solution.
An example of a site with a specific business requirement was described in comment #2, where a Drupal Camp website has a "speaker" role and that role has permission to create session nodes, but that creation is done using the front-end theme.
How can we know the desired result is achieved
The problem could be validated by usability testing and user feedback.