Per field permissions

As I understand it, this feature is planned, but not until the core CCK functionality stabilizes somewhat. Also, since CCK is for inclusion in core, it is important that whatever access control features CCK eventually supports, they be implemented in the most generic possible way.

As an interim solution, it sounds like might achieve your goals using views:

Since you only to limit the ability to _view_ fields (not edit), just disable the node view perm for regular users, and then provide views which expose only the fields you need. Then theme the view as documented elsewhere.

just so that I recieve followups in my inbox.

I am wondering, should these granular permissions live on the field, or on the widget? What do you think?

Bèr

Keeping you all updated.

I decided to go for per-field-instance permissions.

Here is the database/.install patch.

Here is a screenshot of how I envision the UI. This show up on all "edit field" links.

.. here is that screenshot.

yes, that does the job.

And what about displaying a table with Permissions on top row and Roles on first column (similarly to 'access control' but inverted)? That would save some scrolling, and with a table it's easier to figure out the whole situation at a glance.

...or is just me too picky? ;)

would be a really cool feature *subscribing*

Note: After working on this more and more, I can safely conclude that the current model of caching/loading in both node.module and cck.module does not allow per-field permissions in any way.

Hence we need to rethink several things:
* Do we really want such advanced (commercial) features in CCK/core
* How modular do we want to make the field system (as opposed to: how well should it perform)
* Should we, instead aim our arrows at an advanced CCK, e,g, flexinode2?

I've been playing around with this a bit and am thinking about a slightly different tack. What I am looking at is creating field groups to help organize content on forms and output, then allowing an option to set user role permissions by fieldgroup. So you would assign fields to a group, then alter the $form and $view arrays into sub-arrays for each group before sending them to the theme. This way you could create an 'admin' group of fields that should not be viewed or edited by anyone but an admin, and theme it appropriately to display or hide it.

This might or might not be more workable that per field permissions, I haven't gotten far enough along to tell yet. It would make the field screens less cluttered than giving each field all the permission options while still allowing for more fine-grained permissions than the current system.

I don't have anything usable yet, and I'm headed out of town for a couple weeks so I won't get back to it right away, but I was interested in any thoughts about the concept and any possible problems/issues with that idea.

@ Bèr re #11:

Would the changes to the node api change that at all? I've not looked at it much, but if it was using more or less the same system as the forms api then a per-field permission system *could* be done with form_alter or whatever the one for nodes will be called (I'm not sure if the plan is to just use the forms api for everything, or if it's to extend it in to a new node api)

Just a thought :)

Ber,
I have use for this functionality. However, I know Jonbob thinks cck is pretty big already. Can you ask him if he would accept this in cck or does he think it should be a separate module? (I'm thinking contrib for cck.)

Ber,
I have use for this functionality. However, I know Jonbob thinks cck is pretty big already. Can you ask him if he would accept this in cck or does he think it should be a separate module? (I'm thinking contrib for cck.)

Should be straightforward to add View permission in HEAD. We just have to set a corresponding #access parameter when building node_view() array. drupal_render() will then strip inaccessible fields as needed. I think cache happens before drupal_render() so it does not need any changing.

Edit permission should be doable today since CCK controls its own forms.

I mean, per field edit permission should be doable in 4.7

perhaps cck can be be patched, to use db_rewrite_sql for its queries. Then another module - the field_access.module could come and rewrite the queries, so that cck only loads the fields for the current role.

further the cck internal cache has to be changed to be per user (or better per "every possible role combination").

with this it would be possible to enable/disable fields per role in 4.7

Another very simple idea for viewing fields.
It would be nice, if CCK would allow other module to unset() some fields in nodeapi 'load', without rendering those fields, which are unset.

See: in nodeapi 'load': http://drupal.org/node/87774

See http://drupal.org/node/91030 for an idea of how to get this working in 5.0 using the content array.

Has there been any further discussion on this? I asked the same question yesterday http://drupal.org/node/99397 before I found this.

I am also interested if this is still being considered. After my question in the forum (http://drupal.org/node/102640) I was directed to this page.

Jos

I'm re-categorizing this to a feature request for HEAD, since it appears it can't easily be done in 4.7 but should be doable in 5.x. The patch Ber attached will not work (at least that's what he reported), so it is really no longer a patch and is back to being an active feature request.

This should be doable, just needs someone to create a patch against the current HEAD.

on a whim, i started working on this today. it looks like arthuregg did too (http://cvs.drupal.org/viewcvs/drupal/contributions/modules/cck_field_per...). so one way or another, a patch should be coming.

arthuregg's module, at this early stage, only does control on the edit form. we're gonna have to do access control when viewing cck nodes too. i have a good plan for that for drupal5 version.

i actually started withthe Views.module part of this. We don't want Views to be exposing our access controlled fields, do we. I'll be posting that patch soon. Then I'll move over to CCK.

if any knows arthuregg, please have him contact me or post here. There is no README in his module, and his CVS name does not correspond to any on drupal.org.

Thanks for taking this over, Moshe.
I've been looking your Views patch at http://drupal.org/node/105125.
I was thinking that for the cck-field-perms thing, patching Views was maybe not required : couldn't this all happen strictly in CCK, using hook_query_alter and / or content_views_field_query_handler ?

Except, of course, your views patch might have other targets ?

@yched - that would be ideal, but we need to do more than just alter the query. we need to alter the table fields (header and body) and exposed filters. i don't think thats possible with query altering.

CCK Field Permissions v.1.2 is ready to use for 5RC1 and 4.7
now it allows to restrict all permissions, including VIEW

http://drupal.org/project/cck_field_perms

HTH,
Adam

This is not yet fixed. That module does not take into account many of the concerns and issues that have been raised here and it needs work and review. Among other things, that module's method of unsetting fields on node load will destroy that data in the database if it is used on a form and the form is submitted by someone who has edit permission for the content type but doesn't have permission to edit or view all the fields on the form.

Plus it think a proper solution is going to need to be more integrated into CCK core, and probably be a CCK core module, since I expect it will require some patching of the way that field data is cached. If nothing else, I imagine we're going to need to provide separate caches by role if field permissions are going to work right.

The reason this issue has been open as long as it has is because this is a very complex problem with lots of ramifications. If it was that easily solved, it would have been done long ago.

I agree with leaving this open.

VIEW
In 4.7 this module is pretty lousy as it removes fields during load. This is fundamentally flawed because of the cache, as Karen says. But in 5.0 it removes fields from the $content array during view operation which is much better. It should actually not remove them but rather set #access element.

EDIT
Yes, CCK should be smart enough not to do edits on fields that don't appear in the form. Thats really a CCK bug, as all forms can be altered.

CACHE
I am not too familar with CCK caching (yet). But my hope is that we cache one structure and this module acts above that layer, just setting #access parameters as needed. Cache by role is OK, but a single cache is even better. We should focus on D5, and leave 4.7 behind for now.

yep a single cache with #access paramters sounds like a good idea.
role based caching might not be enough, as users with different combination of roles will be able to access different fields - so there needs to be a cache per user or at least per each possible role combination..

Here is a small new module, content_access, that implements role based field permissions.

For the UI, I played for a while with some ugly fapi forms that get themes into tables (this is the most annoying part of drupal fapi IMO). In the end, I ditched a full day's work and just re-used the permission system for this. The code is much much cleaner, and I think it is understandable and expected by the site admin. Note Gabor's patch for D7 to move filter role assignments out of a specialized UI/storage and into the permissions system. Lets just cut to the chase here.

A small change to fieldgroup module was needed in order to that we avoid emitting empty fieldgroups which can happen when the user can't view the group's fields.

This module is just one implementation of field perms. Other modules are welcome to show/hide field based on workflow state and so on. Those should be independant modules which an admin would use instead of this one. This module serves as a nice example for those module authors.

The one pimple so far is that there is a check for content_access module in the standard views field handler: views_handler_field_content. For he moment, a field implementing its own Views handling must apply own access control logic. I can't think of a cleaner way to handle this. Basically, the Views field handler has to have an 'access' method that does user_access($perm_name). The only alternative I can think is to subclass every views field handler and add our own access method. We'd have to dynamically create these classes (how?), and alter the views definition to use them. Sounds pretty invasive to me. Any other thoughts?

the comment uploader was replacing my file instead of adding. here is the .info

Thanks Moshe! I'm looking forward to trying this out. I had been hoping we could get field permissions into this version :)

Haven't looked at your code yet, but as to the question of subclassing the Views handlers, it looks like we're going to end up doing that already -- not *every* Views handler, but the ones we use for CCK fields -- we do that to add the CCK field info to the class and we can jump in there and add anything else we want to add.

it's great see you working on this, but please avoid a name collision with http://drupal.org/project/content_access

OK, we'll use content_permissions instead. I'm re-working views_handler_field_content to be a basic field handler that adds content fields and formatters, then moving the more complex grouping code to another handler that extends views_handler_field_content so other fields can extend either one, depending on whether they want the grouping options. Then I'm putting the access control check in the first one, so it will be available everywhere.

Then I think we need to change this to a hook instead of module_exists() so other modules can do things with access control at that point, but I'm not sure exactly what that ought to look like.

I will do the rename in the next patch, after Karen has restructured. Another option for name is field_permissions.

While I like the name field_permissions, our tentative plan for core is to create a new 'field' module with the core functionality and keep non-core stuff in the content module in contrib, so I'm not sure we want to contaminate the 'field' namespace any more than it already is.

I decided to do this in reverse order to avoid confusion, so I did some testing that it works and committed this patch, with a couple small changes -- I changed the name of the module to content_permissions and I implemented the Views access control using a hook instead of using module_exists() so any other module can jump in there.

I am going back now to work on re-structuring the code which is held up by the fact that recent changes to Views (the relationships patch, maybe) have broken the multiple field handling that used to work, so I need to dig into that more.

Anyway, we now have field permissions. Thanks moshe!!

Hi everyone,

I've read a lot about per field permissions in this and in other topics, but still didn't get the point.

Could you please advise me if it is possible to implement simple permission rules (ability to restrict "view" for some field only for authenticated users with CCK & Views, that's all) in drupal 5.7?

If yes, which combination of modules should I use?
And if it is not possible, what is the situation in Drupal 6 (I've read that "CCK field permissions" module is now a part of CCK) ? Can I use CKK with Views in Drupal 6 now?

Many thanks!

i forgot to upload my tiny .install for this module. It gives an important warning message. See attached.

I'm also working on a patch that we *might* want use which takes advantage of a new Views access control callback. Will let you know.

Here is a patch which uses yesterday's new 'access callback' feature in our default views integration. I think this is cleaner than before since we removed the 'access' method in our views field handler class in favor of a simple field property. Now a field access module just has to implement content_views_access_callback() in order to deny access to fields.

This implementation does not allow one to run multiple field access modules but I don't think we need to support that until a use case comes along. even if we do, most of this patch remains desireable.

Sorry to mix up this issue a little. This patch is independant of the .install file i proposed above.

I'm a little concerned about using a function that can only be used by one module (how do you keep people from installing others and running into conflicts) but I don't have a better idea and it would probably be good to get this into our alpha release so we can have more eyes looking at it since this is a new and important feature.

Anyway, thanks! This is committed.