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: #704180: admin unable to edit fields
  • 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?


Members fund testing for the Drupal project. Drupal Association Learn more


David_Rothstein’s picture

Issue summary: View changes

Fixed the image width

Noyz’s picture


Gábor Hojtsy’s picture


RobLoach’s picture

Another thing to note is that Views integration with this is somewhat of debate as we don't want to hurt performance. You can see details about that here: #1141330: Views is showing fields that should be hidden? .

I added a bunch of documentation and helpful links when fixing up the module. Someone had some other docs suggestions here: http://drupal.org/node/1084688#comment-4284504 .

David_Rothstein’s picture

Status: Active » Needs work
19.01 KB

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

Lars Toomre’s picture

A bit of UX feedback... First review of image above confused me at first.

I would suggest changing the first selection of custom permission to something other than "Enter own value ...". It is so similar to "Edit own value ..." on next line. I would pick a different verb that does not begin with E, perhaps something like "Create own value ..." or "Add own value ..."

RobLoach’s picture

Overall, I like it a lot! Here are a few thoughts I had on the code review. Haven't committed and tested it yet, but I'd love to soon...

+++ b/field_permissions.moduleundefined
@@ -115,21 +131,34 @@ function field_permissions_form_field_ui_field_edit_form_alter(&$form, $form_sta
+  elseif ($field['field_permissions']['type'] == FIELD_PERMISSIONS_PRIVATE) {
+    if ($op == 'view') {
+      return FALSE;
+    }
+    elseif ($op == 'edit') {
+      // @todo: Consolidate with other code that determines the object UID.
+      return (isset($object->uid) && $object->uid == $account->uid) || user_access('bypass field access', $account);

There was a patch at #1230284: Fatal error upon field settings form submit that helped this. Might be good to take a look at how they got around it. I really should commit that patch over in that issue as it fixes the OMGWEDONTKNOWWHATIDWEAREUSING problem.

+++ b/includes/admin.incundefined
@@ -46,20 +87,21 @@ function _field_permissions_permission() {
+  foreach (field_info_fields() as $field) {
+    if (isset($field['field_permissions']['type']) && $field['field_permissions']['type'] == FIELD_PERMISSIONS_CUSTOM) {
+      $perms += field_permissions_list_field_permissions($field);

I like that you move this out of the function itself.

+++ b/includes/admin.incundefined
@@ -67,56 +109,140 @@ function _field_permissions_permission() {
+  // @todo: Do not actually save any permissions if they weren't edited (since

I see lots of @TODO's around... Should we fix those in this issue? Think we should open up a new branch for this and commit things there?

+++ b/includes/admin.incundefined
@@ -67,56 +109,140 @@ function _field_permissions_permission() {
+function theme_field_permissions_permissions_matrix($variables) {
+  // Use the default theming from the user permissions page, but do not display
+  // the hide/show descriptions link, and indent the table (so that it appears
+  // inline with the corresponding radio button).
+  // @todo: The table indentation (at least) should not be inline CSS, and it
+  //   should use LTR/RTL styling.
+  drupal_add_css('.compact-link {display: none;} table#permissions {margin-left: 1.5em; width: 98%}', array('type' => 'inline'));
+  return theme('user_admin_permissions', $variables);

Instead of a theme function and drupal_add_css, could we use a render array with #theme => 'user_admin_permissions' and #attached? Might save us a few lines of code.

+++ b/includes/admin.incundefined
@@ -67,56 +109,140 @@ function _field_permissions_permission() {
 function field_permissions_overview() {
+// @todo: This needs to change somehow!
   drupal_add_css(drupal_get_path('module', 'field_permissions') .'/css/field_permissions.admin.css');


David_Rothstein’s picture

Status: Needs work » Needs review
33.87 KB

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 :)

David_Rothstein’s picture

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.

David_Rothstein’s picture

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


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!)
David_Rothstein’s picture

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.

David_Rothstein’s picture

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.

cbrookins’s picture

Looks great. My issues:
- I think the text 'for field X' is really repetitive, unnecessary and awk.
- I think Add own value is strange since it makes it seems you could add multiple values. Compound that issue with the phrase "Edit any value" and I think that one allows me to add multiple items to a field and the other allows me to edit multiple values in the field. Create I think is a much better verb because it doesn't imply multiple.
- Also given a field CAN have multiple values (checkboxes?) it seems it is pretty darn confusing to have text like "Edit any value" - sure it makes sense for content, but fields?

My solution for these would be to deviate slightly from the Drupal pattern and go with:
- Create own value
- Edit own value
- Edit anyone's value
- View own valuw
- View anyone's value

Lastly I think it is very vague to say "Everyone can view" and "Administrators can view"
That doesn't inform me if I can create, or edit my own values. If both of these radio buttons do allow me to do that then lets say so in some help text under each radio button. Also does Administrators can view allow administrators to edit too?

Noyz’s picture

I agree with a lot of #12...

- 'for field x' IS repetitive, but it's drupal's pattern, so If we're to solve, I think we should look at the pattern holistically. For now, I'd leave it as is.
- 'add own value' is strange. Adding, is 'in addition to' which is not what's going on here. You are entering, or creating values. I think enter is the winner here, and would rather rely on actual usage data to tell whether it's wrong, but for the sake of expediency, 'create' is also acceptable
- 'edit any value' is confusing. I agree that 'edit anyone's value' would be better.
- 'Everyone can view'... I had the exact same reaction. The radio options are not accurate. THey say who can view, but not who can create. I tried playing with some text options to try to make the radio more clear, but each attempt became too long and remained unclear. That said, I'm now thinking we should kill these radio options. Instead, lets put the permissions table in a fieldset, set up good defaults, and collapse the table. Like this: https://skitch.com/jeff.noyes/f9nny/adobe-fireworks-cs5-457

David_Rothstein’s picture

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.

David_Rothstein’s picture

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



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.

Noyz’s picture

I kind of feel like this has the same problems. Previously, I thought it was pretty clear who could see it, the problem was that it wasn't clear who could enter it.

I don't believe that "Everyone can access" is correct. I *think* what happens here is.. "I, the current user filling out this field, can enter a value, but everyone can see that value." But I read this as, "I, the current user filling out this field, can enter a value, as can anyone else.

Likewise, "only author and admin can access" has a similar problem.

Maybe this could work....
- Public (author and administrator can access, everyone can see)
- Private (author and administrator can access and see)

David_Rothstein’s picture

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.

RobLoach’s picture

Status: Needs review » Fixed

Thank you guys so much! This is a huge boon on usability and definitely helps people when they are trying to figure out how to maintain their permissions. The administration of this is so much easier.

Going to let this thaw out a bit before alpha2 comes out: http://drupalcode.org/project/field_permissions.git/commit/83da13a

Great job, all!!!

David_Rothstein’s picture

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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Fixed the image width again