Add Field Permissions to CCK Core

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
KarenS's picture

I'd like to get field permissions into CCK core in the D6 version. It won't be right away, it will be a phase II activity once the initial release is out the door.

One question is what a simple UI would look like, adding checkboxes for each field to the user permissions page is unwieldy.

I'm opening this page to stimulate some discussion, and hopefully ideas, on how to do this.

Some of the issues to be addressed:

  • What will the UI look like if we don't add checkboxes to the user permissions page for each field?

  • How do we lock down fields in Views so users without permissions don't see them?

  • We have to be aware of the CCK node cache that stores field values. We'll probably need a different cache for each node and each type of permission.

Comments

moshe weitzman's picture

I am now the maintainer of cck_field_perms module and I am on board with moving this functionality to core. I have not thought too much about these UI issues. I did think about Views and field perms a while back and even wrote a patch which I need to refresh. See http://drupal.org/node/105125.

I don't think we need to change the CCK node cache. We just need to add #access elements when we display a field and when we render the widget. Maybe I am missing something.

Great! You can be a lot of

KarenS's picture

Great! You can be a lot of help getting this accomplished.

I'm not sure about the node cache, just raising the issue. If #access will always protect us, we still have to be sure the complete node, with all protected fields, makes it to the cache even if the person editing or viewing it has no rights to some of them.

Protecting Views fields could get very tricky so I'm glad you have some ideas on that :)

awesome!

fago's picture

thanks for that :)

I'd appreciate if contrib modules could even customize the access further - I think there are quite some use cases for that, e.g. state based field permissions.

That's excellent news !

yched's picture

That's excellent news ! Thanks for stepping up, Moshe.

I don't think the node cache is problematic either.
Hiding fields in Views should be OK, since they go through our own display handler anyway.
Not sure about how filters, arguments, sorts, should behave, though. If I see a View page that uses an argument on a field I'm not allowed to see, then I get informations on the content of the field anyway...

The UI for the access checkboxes has been bugging me for long. I don't think we want to enter each field's settings page to set the access rights, so what convenient overview can we provide ?
One line per field, one column per role, 2 checboxes (read / write) in each cell ?

UI thoughts

Crell's picture

The UI for the access checkboxes has been bugging me for long. I don't think we want to enter each field's settings page to set the access rights, so what convenient overview can we provide ?
One line per field, one column per role, 2 checboxes (read / write) in each cell ?

I don't think there's anything wrong with being able to edit the permissions from each field's settings page. In most cases, I'd want to set that up while creating the field. Putting a 3D grid onto the field page (field, role, access type) is going to run into the "sea of checkboxes" problem fairly quickly.

I suppose the two aren't mutually exclusive. On the field settings page, have a roles / access type (view/edit) grid that will only ever be 2 columns by usually not more than 6 rows. Then for mass-changes, offer checkboxes on the field listing page that I don't recall ever using that much. :-)

Even if the field display

KarenS's picture

Even if the field display goes through our handler, the field will get queried and counted in the result total, which could throw totals and pagers off, or at least make things confusing. And even if the field value itself is hidden, I might be able to tell something about the values of that hidden field just by looking at the nodes that are listed in the view.

Arguments and filters are definitely a problem because you could easily query for something you're not supposed to see and deduce information from the results of that query. And if you have a view with arguments using summary totals you may see a list of summary values for a field you're not supposed to see, etc.

One thought is to get a list from views during the validation of the view of all the fields, filters, and arguments in the view, so we could compare the views fields to our restricted fields and produce Views validation messages like 'This view has no access control on it, but it contains the following fields, filters, and arguments that should only be seen by authenticated users: field_foo, field_bar. Are you sure you want to save these settings?'

The patch that I posted will

moshe weitzman's picture

The patch that I posted will throw out fields during while building the $view object. I think this will work fine. It obviously needs some testing.

I don't think we need any additional access control on the Views UI forms. The builder of Views will be able to see all fields/filters/etc. Thats my goin in position.

I wasn't so much worried

KarenS's picture

I wasn't so much worried about whether the builder could see the fields but that there be some way to tell which fields have permissions as you build a view so you don't accidentally create a view with permissions that don't match the permissions of your fields or that will behave oddly for users without permissions. The view builder will be able to see everything and if there are lots of fields with special permissions it may be easy to forget that you've included a protected field in a view that will be public facing.

By 'throwing out fields

KarenS's picture

By 'throwing out fields while building the view object', you mean removing the fields from the query altogether? That sounds like the right way to go.

Right. Look at the unset()

moshe weitzman's picture

Right. Look at the unset() in the patch at http://drupal.org/node/105125. That is happenning before the query and so the fields are gone from table headers, rows, etc. I guess it would wreak havoc on Views like calendar Views which depend on certain dates being present. Oh well.

UI for permission

cabbiepete's picture

Sounds like the discussion is a little of do we allow per permission access for view/edit and/or per role for view/edit.

Having done a couple sites I know that per role will be all that was required at least some of the time. But to cover off more possibliities it would be better to also have per permission based, obviously this is a much larger list and so the UI becomes more difficult.

My idea would be to have a flag that said use either role based or permission based.

For role based it should be ok to have a table with role/View/edit columns and a row per role with checkboxes in each column. But for permission based I propose that we have 2 levels of UI one basic html forms and for this we have View and Edit text area's where you can enter one permission on each line. For the more advanced UI we use jquery to convert those text areas into a display listing similar to the role based one but only show the selected permissions and have a add button that shows a small search/filter permission listing thing that allows you to select permission(s) to add to the list. Then on submit the advanced ui converts the data back into the basic text area format.

I would love to help out making the UI also if people agree its a good idea.

a bit complicated

moshe weitzman's picture

I can't really work out what you mean by permissions based, but it sounds complicated :(. If you could make a picture that might help communicate the idea. In any case, I think we should implement roles based field permissions in cck core and leave more complex schemes to contrib modules. i'll be sure that the door is open for them to override what we are doing.

I am thinking that we add a comma delimited list of allowed roles as a new column on admin/content/types/fields. This is a read only list, and provides a nice overview. In order to make changes, you have to edit the field directly. This is analogous to the admin/user/user page which lists the roles of a given user and expects admin to edit that user to change roles.

There's permissions based,

catch's picture

There's permissions based, er, permissions in Views - maybe something like that? (Although I'd be more than happy with role based permissions personally).

That's what I was thinking

KarenS's picture

That's what I was thinking too, to have the permission match the new Views permissions that are either role- or permission- based, just to have one consistent concept of 'permissions'. But that makes it much more complex and I agree it's enough to start with role-based permissions.

if we can do just roles that is fine by me

cabbiepete's picture

Yes I agree permissions based would be more complicated, its why I was trying to think of a nice way to have the UI so that the UI was simple.

The idea could be applied to roles based permissions also but I figured there was less need, as there are a lot less roles than there are permissions.

Also I wasn't concerning myself with how to implement the restrictions at all just the UI.

What I could do is create a demo of my UI idea but what I might do is wait for when this discussion gets everything behind the UI a bit firmer and then see if a) it needs simplifying or b) what can be done. Essentially I will keep tabs and try to pitch in ideas. Anyone thinking about the logic behind the UI could worry less about it until that is sorted and then we can tackle the UI issues at the time.

Hope that makes sense.

What would be helpful at

KarenS's picture

What would be helpful at this point would be some screenshots or wireframes of possible UIs. They don't need to be working demos, just some sort of visualization of what it would look like. For any solution, keep in mind that we have implementations with dozens of fields on a single content type, and that the permission needs to be based not just on the field, but also the content type, multiplied times all the possible roles.

not field instance

moshe weitzman's picture

If we want field permissions to work in Views, I think we have to let go of the hope that we set permissions based on field instance (i.e. content type+field) and just content ourselves with field based perms. when you add a field to a View, you do not specify an instance. comments welcome.

It'd be stupidly complex to

catch's picture

It'd be stupidly complex to do per field permissions per content type, so +1 from me to 'per field' only.

User interface suggestions

zirvap's picture

I agree with not having field instance granularity for field perms. For one thing, it's much easier to make mistakes if the same field can be visible/editable in some content types and hidden in others. I might think that a field is safely hidden for most users, and then later make a new content type which uses that field, and forget to check if the field is still hidden for the new content type.

I think the user interface for this should be as similar as possible to that for admin/user/access. It may not be the world's greatest interface, but consistency is a good thing, usability-wise. I'd rather have an allright interface that's familiar than a fantastic one that's different from the main access control interface.

So, my suggestion for interface is simply:

  evil overlord faceless minion anonymous user authenticated user
View first_against_the_wall_when_the_revolution_comes x x    
Edit first_against_the_wall_when_the_revolution_comes x      
View gaping_flaws_in_plans     x x
Edit gaping_flaws_in_plans       x

I suggest that this page is available from admin/user/access, preferably as a tab.

I also suggest a summary of permissions in admin/content/types/fields (ie. info only, not editable, but an "edit" link pointing to admin/user/access is probably a good thing). Something like

Field name Field type Used in View permissions Edit permissions
first_against_the_wall_when_the_revolution_comes userreference To do list evil overlord, faceless minion evil overlord
gaping_flaws_in_plans text Guest book entry anonymous user, authenticated user authenticated user

--
Hilde Austlid, Drupalchick

Interesting, this looks like

KarenS's picture

Interesting, this looks like a good option.

I agree that permissions per

catch's picture

I agree that permissions per field instance is crazy talk and prone to errorss so +1 on that.

The admin interface looks pretty sane as well. As a tab on admin/user/permissions seems fine as well as long as it's available from fields/content types admin at the same time (via a link or another tab using the same callback).

I posted a patch to Views

moshe weitzman's picture

I posted a patch to Views that we'll need here. It adds access control for fields/arguments/sorts/filters. See http://drupal.org/node/105125#comment-765622

I submitted a patch for this

moshe weitzman's picture

I submitted a patch for this to the CCK project. Please review and discuss there.

I forgot to post here that

moshe weitzman's picture

I forgot to post here that KarenS quickly committed my patch so we now have field level access control in CCK and it is honored by Views as well. D6 only.