Bundle based Field permissions

That's right, imho now this is completly against d7 field terminology. This settings should be as instance settings, not field settings. Now I need to use this in some field, I will do it implement own _field_access. But if I will need more, I will try to fix it, but I think, this is not too simple..

What makes this a bug?

For the primary use case of this module, it actually doesn't seem like a good change to me; if you have a field that you want to control access to because it is collecting private/sensitive content, then you'd usually want to manage that access centrally in one place, not in 10 different places.

I've been looking through the issue queue a bit, and I think this issue may be a duplicate of (or at least closely related to) #1050396: Per node type field permissions, which was marked "won't fix"....

Yeah, this could really make the permissions table unnecessarily huge. I'm inclined to set this to won't fix. It would be best to just create a new field for it.

I just marked #1826348: Changing field permissions in content type with same name of another field in a 2nd content type changes both permissions as duplicate. Since this keeps coming up, perhaps there are use cases for it - basically if you are using Field Permissions to hide things for certain user roles for aesthetic reasons rather than for actually storing truly private data...?

But I'm still thinking it's not a good match for the module's primary use case, and if you need this then in most cases you probably want to create a new field anyway (like Rob Loach said above).

Keep in mind also that this module is in many ways a light user interface wrapper around the field API, and field_access() itself is very much about the field rather than the instance.

pity! I also have more bundles, and the field names in the bundle must be the same :-(
Looking for another solution ...

Would the maintainers be interested in a patch that adds the per-instance permission as additional option - to be checked before the per-field access? If so, I might work on a patch. I can understand if this is seen as unnecessary bloat, and then a separate module would be the solution.

I have implemented a sandbox module that has field permissions per instance. Much of it is directly copied from the Field permissions module.

Is it OK to have two separate bet very similar modules? Or should this be merged into Field permissions? This should be up to the maintainers of Field permissions to decide.

I have the same problem. Re-used a field in profile and in a node. I want to allow any user to edit its own profile; but in nodes only admins should update it.

+1 to be able to an option to set "per field" or "per instance" permission.

In reponse to comment #5 I've added a patch for field_instance_permissions sandbox module that move field instance permissions administration into a separate form page #2415033-1: Administer field instance permissions in a seperate form (instead of the regular permissions matrix).

Couldn't we implement same functionality provided in views like "all displays"(all fields),"except overidden" kind of thing. It is more familiar to dupallers IMO.

I have a project where the body of one content-type is displayed only for subscribers.
If I use the custom permissions for the body field, it is applied to all my content-type's body fields...

There is definitely something wrong on Drupal's field settings page, as we don't know if we are updating the field base or instance... :(

I was so confident that field_permissions was based on field instance, now I have to look for another solution, or maybe patch.

Just for my personal information, is there any reason such performance issues to not include field instance settings?

I'm implementing my own hook_field_access() for my current project.

Thanks!

As stated above, per-bundle config would take up a lot of extra space in the database, and would cause you to have to update each bundle for field settings instead of just one. The module that attempted to fix this never got off the ground, so I'm marking back to "won't fix".

nithinkolekar +1 for your idea @ #12.
Still looking for a solution to this.

Not implementing istance base permission makes this module unusable.
Create other fields equals to others only to define different permissions makes really take up "extra space (meta)data".

This really not OOP making fields not reusable!