Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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)?
Comment | File | Size | Author |
---|---|---|---|
#19 | field_permissions_module.patch | 829 bytes | berenddeboer |
#10 | field_permissions_overview_d7.png | 9.12 KB | markus_petrux |
Comments
Comment #1
EvanDonovan CreditAttribution: EvanDonovan commentedSubscribe. I would certainly like to see an upgrade path from Content Permissions, but I can understand if the architecture is too different to upgrade.
Comment #2
markus_petrux CreditAttribution: markus_petrux commentedFor 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.
Comment #3
matt2000 CreditAttribution: matt2000 commented#618422: Port CCK content_permissions module to core is a direct port, hence it should upgrade just fine for anyone needing an intermediate solution.
Comment #4
markus_petrux CreditAttribution: markus_petrux commented@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.
Comment #5
EvanDonovan CreditAttribution: EvanDonovan commented"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!
Comment #6
matt2000 CreditAttribution: matt2000 commented@markus_petrux,
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.
Comment #7
markus_petrux CreditAttribution: markus_petrux commentedI 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.
Comment #8
markus_petrux CreditAttribution: markus_petrux commentedI'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. :(
Comment #9
markus_petrux CreditAttribution: markus_petrux commentedI have just committed a full module overhaul in the D7 branch, based on the current D6 branch and features.
http://drupal.org/cvs?commit=289330
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.
Comment #10
markus_petrux CreditAttribution: markus_petrux commentedHere's a screenshot of the Field permissions overview page.
Comment #11
markus_petrux CreditAttribution: markus_petrux commentedNotes for next steps:
Comment #12
Dave ReidAdding tag...
Comment #13
fago#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.
Comment #14
luisfeng CreditAttribution: luisfeng commentedtagging!
Comment #15
BenK CreditAttribution: BenK commentedSubscribing...
Comment #16
BenK CreditAttribution: BenK commentedJust wanted to check in to see if any more progress had been made on this...
Comment #17
davepoon CreditAttribution: davepoon commentedSubscribe.
Comment #18
berenddeboer CreditAttribution: berenddeboer commentedI can tell that it appears to work.
I'm currently trying to figure out how to get fields to display on the registration form.
Comment #19
berenddeboer CreditAttribution: berenddeboer commentedAttached 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.
Comment #20
berenddeboer CreditAttribution: berenddeboer commentedComment #21
hagen CreditAttribution: hagen commented@berenddeboer patch #19 worked perfect for me
Comment #22
markus_petrux CreditAttribution: markus_petrux commented@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.
Comment #23
berenddeboer CreditAttribution: berenddeboer commentedClearly 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.
Comment #24
PieterDCCross-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.
Comment #25
rlmumfordSubscribe
Comment #26
smls CreditAttribution: smls commentedSubscribe
Comment #27
steinmb CreditAttribution: steinmb commentedSubscribe
Comment #28
EvanDonovan CreditAttribution: EvanDonovan commented@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?
Comment #29
villageeater CreditAttribution: villageeater commentedHello
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.
Comment #30
EvanDonovan CreditAttribution: EvanDonovan commented@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.
Comment #31
Danic CreditAttribution: Danic commentedI 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.
Comment #33
altrugon CreditAttribution: altrugon commentedHello,
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.
Thanks.
Comment #34
altrugon CreditAttribution: altrugon commentedComment #35
EvanDonovan CreditAttribution: EvanDonovan commented@altrugon: Field Permissions never was about making user profiles. Profile2 is.
Comment #36
altrugon CreditAttribution: altrugon commentedThank you, I will use Profile2 then.