We are considering adding the Field Permissions module to Drupal Gardens. As part of this effort, we'd like to spend some time making the module easier to use.
Here is a mockup showing a proposal for how the new field permissions UI could look. This design was put together by Jeff Noyes (@Noyz), Stellina McKinney, Gábor Hojtsy, and myself:
The basic idea is the current UI has a couple areas in which it could improve:
- It puts all advanced options on the screen at once, making it harder to figure out how to do simpler tasks.
- It requires a two-step process of first "enabling" certain permissions and then assigning them on a totally different screen. This is a complex workflow; plus, it's difficult to understand how the module behaves when certain permissions are enabled and others aren't (I can say from personal experience that the only way I understand what it will do myself is by reading the code :)
The proposed design attempts to simplify things in a couple of ways.
When configuring field permissions, users get a simple radio selector with three options:
- Everyone can view: This is the default (no field access control).
- Administrators can view: This will be a new, hardcoded, "non-permissions-based" setting that exposes a very common use case (i.e., "private fields") that people will often want to configure. For example, the core Profile module, as well as Profile 2, both have this concept for user profile fields, so it makes sense to provide it here too.
- Custom permissions: Only if the user clicks on this radio buttons are the more complicated options shown. In this case (as can be seen in the mockup), we allow the permissions to be assigned to user roles directly here, via a similar UI as on the permissions page, rather than forcing the administrator to go to the permissions page and do it there.
Note that with this UI, the ability to only "expose" certain permissions on the permissions page goes away - it's now either all or nothing. This is a change in the module's feature set, so I wanted to highlight it, but it removes a huge amount of confusion over how the module behaves when e.g. the "edit own" permission is defined but the "edit any" isn't, and I don't see any big downsides to doing it this way offhand.
Another change visible in the screenshot is that we tried to reword the permission names in order to be as clear as possible without using too many words. A couple points around this:
- The hardest one to rename was the "create" permission; we eventually decided to suggest "Enter own value for field X" for this (which was based on some label testing Jeff did with several potential users).
- Not shown in the mockup, but in the case of fields attached to users we actually are suggesting that this "create" permission be hidden entirely. (This idea actually came from Dave Reid; he pointed out that the "edit own" permission, combined with the "display on user registration form" checkbox that Drupal core provides for user fields, is actually enough to completely handle this case.)
Finally, a couple miscellenaous points to note:
- To make some of the functionality implied by the mockups make sense, I think it might be a good idea to introduce a "bypass field access" permission (similar to the "bypass node access" permission provided by Drupal core for nodes). This is probably a small change in behavior of the module, but it seems like it might be a good idea because it makes it more clear how to grant a site administrator access to e.g. private fields. Possible related issue:
- We have to think a bit about what the above changes mean for the reports page provided by the module (admin/reports/fields/permissions).... haven't spent much time thinking about that yet.
Anyway, I'm looking to spend some time writing code for this pretty soon, and am wondering if anyone has any feedback on this design. Does it generally seem like a good UI that would be committable to the module? Any possible problems to watch out for, or any other feedback?