I already started the port of Field Permissions to D7.

Pending issues:

- Figure out how we can hook into the field settings form.
- Do we want to separate permissions per object type?
- Do we need to provide upgrade paths from D6 for Field Permissions and/or Content Permissions (part of CCK)?

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


EvanDonovan’s picture

Subscribe. I would certainly like to see an upgrade path from Content Permissions, but I can understand if the architecture is too different to upgrade.

markus_petrux’s picture

For the record.

Here's how we can extend field settings in CCK for D6: #417122: Allow drupal_alter() on Field and Widget Settings

Here's how we can extend field settings in Fields for D7: #502522: Allow drupal_alter() on the various Field API declarative hooks

One important difference between the methods, is that in D6 you can alter the field settings form and tell CCK which form values to store with the field information. On the other hand, this is not so clear in D7. It seems we need to implement hook_field_info_alter(), but also hook_form_alter() to extend the field settings form.

It would be nice if someone could confirm the method to do this in D7. Otherwise, I'll try to explore the new beast when I have the time.

matt2000’s picture

#618422: Port CCK content_permissions module to core is a direct port, hence it should upgrade just fine for anyone needing an intermediate solution.

markus_petrux’s picture

@matt2000: However, I'm trying to go a bit further from current features in Content Permissions for D6, that are and will be extended a bit more in Field Permissions module (FP), and then that will be ported to D7.

Content Permissions for D6 is problematic when you have a lot of fields, but just need permissions for a few of them. And it does not support "view own field", "edit own field" permissions, ... and it does not support "create field" permission, which is something I'm adding here behind the scenes, and that I expect to commit soon.

First, I would like to complete the features in FP for D6 (which is why I haven't packed a stable release yet), then I'll finish the port to D7, offering upgrade paths from FP for D6 to D7, as well as from Content Permissions for D6 to FP for D7.

EvanDonovan’s picture

"Content Permissions for D6 is problematic when you have a lot of fields, but just need permissions for a few of them." Amen to that - it's very frustrating on my site, where I have at least 10 CCK types. Best wishes on the new version!

matt2000’s picture


Awesome! I wasn't trying to dissuade you or anything. I just wanted something for D7 that worked _right now_, as I am prototyping a new site with D7, that's all. I'll be very interested in upgrading to your module when it's ready.

markus_petrux’s picture

I have just released beta1 for D6. The D7 branch has been updated as well, but it does not work yet, mostly due to lack of time to play with D7. Once the version for D6 is considered stable, then I'll get back to this as soon as I have the time. In the meantime, if someone else has the time and wish to help, patches are welcome.

markus_petrux’s picture

I'm planning to finish #627218: Add report to help troubleshoot the execution of content_access() during next weekend. If no other issues are reported, then my plan is to pack the first stable release for D6.

Once that happens, I'll try to find some time to port all features in the D6 version to D7. That means I'll have to install D7 on my dev environment, and honestly, it will be the first time I install D7 (*), lol, so I think I'll need to breath a couple of times, because it looks like D7 comes rocking. :)

(*) due to lack of time. :(

markus_petrux’s picture

Status: Active » Postponed

I have just committed a full module overhaul in the D7 branch, based on the current D6 branch and features.


It basically works, I think, at least it doesn't seem to break anything.

Only node related fields are covered. Settings form for taxonomy fields are giving me Page not found, I'm unable to find where fields can be attached to comments, or users. So, I'm postponing this issue until Fields in core are a bit more mature...

Also, the troubleshooting report has been disabled, mostly because I have no idea on how to manage non-node fields, yet.

markus_petrux’s picture

Here's a screenshot of the Field permissions overview page.

markus_petrux’s picture

Notes for next steps:

  1. I was not sure where to place the "Field permissions overview" page. In the meantime, I opted for admin/structure/field_permissions.
  2. The troubleshooting page as in D6 has been commented in the code, it is not ready due to doubts on how to deal with non-node entities.
  3. It seems to me that we need a method to generate a different set of permission types depending on the target entity type. For example, taxonomy terms do not have uid, so it makes no sense to enable permissions to 'View own' or 'Edit own'. Also, I need to investigate a bit more where field_access() is invoked. Does it cover all kind of fieldable entities?
  4. AFAICT, we need to offer support for the following entity types: nodes, taxonomy terms, comments, users. Am I missing something? What if a contrib module implements a different fieldable entity? ...or what do we need to integrate new entities with Field Permissions?
  5. Doubt: can a field be shared between different entity types? I guess not, because how the Fields report is coded, and because fields seem to have different prefixes depending on entity type (field for node fields, taxonomy for taxonomy term fields, what about the fields for comments or users, or contrib entities?). I cannot see the whole picture, yet, so it's hard to tell...
  6. Problems I've seen to date (I guess there are issues about them in the Drupal queue):
    • The link to settings form for taxonomy related fields reported Page not found.
    • I was unable to find the place to define fields for comments.
    • Profile module does not seem to work with fields, yet.
    • Node reference was not usable because issues about Field API, and Database API.
Dave Reid’s picture

Issue tags: +D7 porting

Adding tag...

fago’s picture

#4: Yep, you should support all fieldable entities. Use hook_entity_info() and entity_get_info() if you need to know which entities are there. Contribs will define new entity, e.g. profile2 defines a profile entity.

#3: Indeed. You could annotate hook_entity_info() with further properties you need, but you would have to define the property for core. Or instead - try to get in d7 now! ;) There is already something like 'object keys' in hook entity info, you could use that for defining the key for "uid".
I'm already annotating more metadata, see this. Well now I think about annotating per-property access, but I wonder if that makes much sense for fields if the $object isn't available... Well field_access() says the object is optional, so I guess a module implementing field_access() needing the $object to determine would just need to go sure and deny access in the general case?

Also from a short look at the code, you should use entity_extract_ids() for getting the identifier. So you aren't hard-coded to nodes any more.

luisfeng’s picture


BenK’s picture


BenK’s picture

Just wanted to check in to see if any more progress had been made on this...

davepoon’s picture


berenddeboer’s picture

I can tell that it appears to work.

I'm currently trying to figure out how to get fields to display on the registration form.

berenddeboer’s picture

829 bytes

Attached a patch that will show fields marked with the "Create X" permission for anonymous users on the user registration form. So this is another way of getting extra fields to show on the user registration form.

Probably needs to be generalised more, but this is the most minimum that does that. Probably you want to have fields with anonymous create to be always visible on forms.

berenddeboer’s picture

Status: Postponed » Needs review
hagen’s picture

@berenddeboer patch #19 worked perfect for me

markus_petrux’s picture

Status: Needs review » Postponed

@berenddeboer/hagen: shouldn't that patch be better implemented as a separate module? It seems to me that feature is not related to Field Permissions module itself.

berenddeboer’s picture

Clearly I see giving permission to a field for anonymous users as subsequently showing up on the registration form as quite a natural fit. And we don't have a better solution right now.

I agree that a simple checkbox would have been better as having to install the field permission module just to get a field on the user registration form isn't intuitive or user friendly.

PieterDC’s picture

Cross-posting, but it relates: http://drupal.org/node/501408#comment-3454206

Let's not hack the Field Permissions module for this single purpose.
If we can't get it - see link - committed to core, a small contributed module will do, I hope.

Please try my (User module) patch in combination with an unpatched Field Permissions module.
It works for me.

rlmumford’s picture


smls’s picture


steinmb’s picture


EvanDonovan’s picture

@PieterDC: Agreed that Field Permissions module is not the best place for this functionality. I have subscribed to your other issue, though I'm not sure whether I will be able to help, apart from possibly testing patches.

@markus_petrux: The last commit on Field Permissions' D7 branch was in July - is it still working with the current Field API, or are you going to resume development after D7-rc1? Does the most recent dev of Field Permissions for D7 work with entities besides nodes?

If the reason this issue is postponed is because of a patch that broadened the scope of the port to something unrelated, then wouldn't it make more sense to simply mark this issue fixed, since the initial port is done?

villageeater’s picture

Title: Port of Field Permissions to D7 » Field Permissions view only does not work
Category: task » bug
Priority: Normal » Critical
Status: Postponed » Active


I was trying to create a read only field in the profile and since the functionality is not integrated in the Field UI I tried to add module user read only which is not ported yet and later found this module.

But here we have a bug. I choose
View own field_ on content created by the user.

but when I log in a a user and go to my account the field is not visible in the view tab
and in the edit tab the field is editable and not just viewable either.

EvanDonovan’s picture

Title: Field Permissions view only does not work » Port of Field Permissions to D7
Category: bug » task
Priority: Critical » Normal
Status: Active » Fixed

@villageeater: Can you open a new issue on the 7.x-1.x-dev branch for this issue? Please don't re-purpose existing issues for new bug reports.

@markus_petrux, et al.: Since the module is ported, can we mark this issue fixed? I'm just going to do so, and you can re-open if you think necessary. But I really think it would be better to continue discussion in more specific, focused issues since the 7.x branch is open, and apparently now being used.

Danic’s picture

I think the permissions are broken. I opened an issue and you problem sounds like the same #965126: Better documentation on how to use Field Permissions.

Status: Fixed » Closed (fixed)

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

altrugon’s picture


Can anybody tell me what is the situation of this module for D7?

I thought this would be the way to go (since it was expected to be integrated in core) in order to create different users profiles, but the last recommended release is from July and apparently is not working properly.

I also have seen that Profile2 has more activity and I would like to know if I should use this other option instead.


altrugon’s picture

Status: Closed (fixed) » Active
EvanDonovan’s picture

Status: Active » Fixed

@altrugon: Field Permissions never was about making user profiles. Profile2 is.

altrugon’s picture

Thank you, I will use Profile2 then.

Status: Fixed » Closed (fixed)
Issue tags: -D7 porting

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