Revamp the Field Permissions user interface to make it more intuitive

Fixed the image width

Here's an initial patch. It's rough around the edges, but basically working (and the general approach is certainly reviewable now).

This patch is much further along than the previous one, and hopefully ready to go. I don't have time to post a summary now, but I'll post one tomorrow :)

Here's what is hopefully the final patch. Mostly minor changes and bugfixes from the previous one.

The biggest change is that I switched the new admin permission's behavior from "bypass field access" to "access other users' private fields" (i.e., now it only applies to fields with the special "Administrators can view" radio button selected, rather than all fields). The reason is that it doesn't make sense to apply it to fields that already have custom permissions, since that would just create overlap and confusion; e.g., you would be able to take "Edit field X" permission away from a role on the field config screen, but then find out they can still edit the field anyway because of some other permission you forgot about that doesn't even appear on that screen... that's just bad.

A full writeup (with screenshots) is coming up in a second.

Here's a summary of the changes made in this patch.

Screenshots

The module adds three radio buttons to the field configuration page ("Everyone can view", "Administrators can view", and "Custom permissions"). If either of the first two are selected, that's all you see:

If "Custom permissions" is selected, the permissions matrix is revealed beneath it (with options "Add own value for field X", "Edit own value for field X", "Edit any value for field X", "View own value for field X", "View any value for field X"). By default, all the checkboxes for the administrator role are checked, to get you off to a nice start:

Here's the module's section on the permissions page. The only fields that show up on this page are the ones for which "Custom permissions" was chosen above. Beyond that, there's also a new special permission "Access other users' private fields" which is the permission that lets you see the "Administrators can view" fields discussed above. You can also see that if a field is used in more than one place and consequently has more than one label, the permission name and description are modified to show all of them (e.g., title "Add own value for field [machine_name]", description "This field appears as: Label1, Label2"):

Finally, here's the module's reports page. Since this was previously the place where you go to get a summary of things you can't see on the main permissions page, I tried to keep the same purpose here... Basically, what I came up with is that the green checkboxes now indicate permissions that all users on the site have, and the red X's indicate permissions that are restricted. Fields that don't use custom permissions get a sentence describing whether they are public (everyone can view) or private. It's not amazing, but it will do for now:

That's about it for the screenshots.

Deviations from the original design

Not too many, really:

• I took Lars Toomre's suggestion in #5 for "Add own value" rather than "Enter own value". I don't think anyone came up with that in the label test that was previously done, but it makes a lot of sense, and I like how it matches the terminology Drupal uses elsewhere (e.g., "Add content") which is exactly the connection we want people to make.
• For now, I did not wind up implementing the suggestion in the original proposal to suppress the "Add own value" permission in the case of user fields (due to their perceived overlap with the "display on user registration form" checkbox). After further thought, I don't think this will work: For example, what would you do if you want to give a user permission to enter a field on the registration form but not allow them to go back and edit it later (a relatively common use case)? Plus, this setup would get confusing if you ever have a field that appears e.g. on both users and nodes. So let's not try to special-case this after all.

Remaining design/behavior questions

Mostly surrounding the "Administrators can view" (private field) option:

• Is "Administrators can view" descriptive enough? As implemented, it's really more like "Administrators and the user who owns the object can both edit this field and no one else can see it"... The view/edit difference is a bit odd itself (although subtle), but I'm more worried about people not realizing that the owner can view/edit it too. Example: Suppose I, as an administrator, decide to add a "mean gossip about this person" field to users that is for my own private notes about them. Well, from looking at the UI, I might think "Administrators can view" is a good thing to choose for that... Oops. I won't be too happy when I discover later on that all my users can read the mean things I've written about them :)
• To what extent should the "Administrators can view" fields actually be viewable in addition to editable? For the most part they probably shouldn't (since it's disconcerting to have private/personal information display on all sorts of screens just because you're logged in as a user who can see it), but since you can edit it anyway there's no harm in making it viewable some places. Ideally, I would think that if there is a View that is explicitly set to show an "Administrators can view" field, then maybe users with the proper permission should be able to see it there? Not sure how hard that would be to implement; perhaps can be done as part of fixing up the overall Views behavior (#1141330: Views is showing fields that should be hidden?).

Follow-up issues

We still need to modify the README.txt for all these changes. I didn't do that yet because it will conflict with #1114134: Remove dependency for Fields UI (which is RTBC), so better to wait for that one first.

Miscellaneous notes

• I believe I took care of all the relevant issues raised by Rob in #6.
• This patch comes with an upgrade path, and I lightly tested it on a Drupal 6 to Drupal 7 upgrade (following along with the overall CCK upgrade as described at http://drupal.org/node/1144136) and it seemed to work fine. I also tested a Drupal 7 upgrade (from the alpha1 release), which works well too, especially given that it's coming from an alpha :) It may run into some problems if you've used field permissions for things other than nodes, but the D7 module has some bugs anyway that make it hard to effectively use it for things other than nodes at the moment, so it shouldn't be a problem. Perhaps something to note for the release notes is that it's extremely important to do this upgrade with the site in maintenance mode (since in the interim before you run the updates, all field access control will disappear and all your private fields will be temporarily visible!)

For now, I did not wind up implementing the suggestion in the original proposal to suppress the "Add own value" permission in the case of user fields (due to their perceived overlap with the "display on user registration form" checkbox). After further thought, I don't think this will work: For example, what would you do if you want to give a user permission to enter a field on the registration form but not allow them to go back and edit it later (a relatively common use case)?

I may have spoken too soon. I forgot that when a new user is creating their own account to register for a site they are still an anonymous user, and they switch roles after they join the site :) This means you could actually achieve the above goal by allowing anonymous users to edit the field but not allowing authenticated users to edit it.

However, it's still problematic for the other reasons I mentioned above.

Maybe a better way to deal with the user fields issue is simply by displaying its permissions more intelligently on the form (rather than removing the create permission completely)? For example:

• If the "display on user registration form" checkbox is unchecked, we could use JavaScript to hide the "Add own value" row in the table. (It makes very little sense to show that permission if the field won't ever be able to appear on the registration form anyway.)
• We should probably check the anonymous role's checkbox for the "Add new value" permission by default, since they're the ones most likely to need that permission.

Anyway, I don't think any of this should be a commit-blocker, since we could deal with it in a followup pretty easily.

I'm attaching a revised version of the patch with one small tweak (shown in the interdiff file) that allows other modules to modify the permission matrix more easily using hook_form_alter(). I'm likely to have a use case for this soon, so I figured I'd throw it in. There are no actual changes to how the code works though.

Also, one more issue for a followup: We may need to adjust how the "Administrators can view" option works in the case of adding fields while creating an entity. Currently the code only grants access to non-admins if the user owns the entity (just like it does when editing an existing entity), which turns out to work OK for nodes and users, but will be problematic in other cases. For example, if the entity doesn't exist yet it might not have an owner assigned, or for some entities (e.g. taxonomy terms) there is never an owner at all.

It's better to save that for a followup because it will be easier to fix after #876550: The "create" permission does not work for fields that are attached to any entity other than nodes is taken care of.

OK, the permission name changes look good - will make those.

"Everyone can view" vs "Administrators can view" - yes, as discussed above we really need to do something about that. However, I don't think https://skitch.com/jeff.noyes/f9nny/adobe-fireworks-cs5-457 will work. First, it's a pretty huge change technically. Second, it would require defining permissions for every single field on the site (even though on a typical site only a few fields ever use this), which would completely overwhelm the Permissions page. I believe it's a stated fundamental goal of this module (and in fact the reason it was originally written) not to completely overwhelm the permissions page like that :)

For renaming the radio buttons, could we not just use something like I had above for the other page? For example:

• Public (everyone can access)
• Private (only the author and administrators can access)
• Custom permissions

This is not perfect, but it's actually impossible to describe perfectly. (Even the permissions matrix with all those checkboxes doesn't really describe it perfectly; just because you have permissions to edit a field does not mean you have permissions to edit the content that contains the field so practically speaking you might still not be able to edit it, etc.)

I'm pretty sure that (at least for the second radio button) the word "access" implies what we are going for while keeping things simple.

Here's a new patch that implements the permission names and radio button labels from above.

Screenshot:

Any thoughts?

As a last resort, it would of course be possible to just remove the second radio button entirely. At that point there'd only be two choices ("everyone can access" and "custom permissions"), so it could even become a checkbox and then in the end not look so different from https://skitch.com/jeff.noyes/f9nny/adobe-fireworks-cs5-457 after all.

However, that's a bit like giving up. It would mean that anyone actually using this module for any access control at all has to read and figure out the entire matrix of permissions, which is not simple. The idea we originally had here (to expose the most common use case as a separate radio button) still makes sense to me.

Jeff and I discussed this some more and eventually decided to try #16 but with some slight textual tweaks:

• Public (author and administrators can edit, everyone can view)
• Private (only author and administrators can edit and view)

We also discussed that in certain cases (e.g. fields attached to wiki content) the first description will be a bit misleading (because in fact, when you have that option selected, anyone who can edit the content can also edit the field attached to the content, and for wikis that will be a larger group of people). However, it's not 100% inaccurate either (we're deliberately making sure not to say "only authors and administrators..." for this one), and it's probably the best we can do if there are going to be radio buttons here at all.

The attached patch implements that change, as well as the changes to user fields described above in #10.

Note that last Friday we did minor testing of one of the earlier patches in this issue, and both of these usability problems (unclear radio button labels, as well as difficulty figuring out how to make user fields with custom permissions appear on the registration form) were directly observed. So with the changes here we are addressing actual user feedback.

Thanks, Rob.

I filed some followups for issues that came up above:
#1308210: Update the README.txt for the new user interface
#1308218: Field permissions and private fields don't work well for types of entities that don't have an "author"

Otherwise, I think everything else discussed above has already been taken care of.