Posted by bensemmel on December 24, 2008 at 3:35pm
8 followers
| Project: | CCK Field Privacy |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | obsidiandesign |
| Status: | needs work |
Issue Summary
Hi Bryan,
I'm using cckfp together with the content profile module. I splitted my profile in different fieldgroups, like "contact details", "general info"...
All cck items which I moved in such fieldgroups loose the padlocks. In the cckfp admin page, the fields are still checked.
Regards
Ben
Comments
#1
In a way, this would be expected (albeit unintentional) behavior; if the user has selected privacy for the fieldgroup, it should take precedence over the individual fields. I'll look into getting the padlock icons to display, but there is going to be inevitable issues with displaying the fields later.
For example, if the fieldgroup is set to private, should the individual fields matter? By the same token, having the group set to 'everyone' should mean that the child fields are everyone. Maybe the only way to fix the situation would be fieldgroups have an ignore/child setting? Or should the group take precedence, and if nothing is set, the individual items are used? Of course, defaults could cause issues here too.
Like I said, I'll try and get them to display, but I'd like some input into how to address the conflict between the fieldgroup privacy and the child fields, as a longer term solution.
Bryan O'Shea
Obsidian Design
#2
Hi Bryan,
thank you for the answer. I understand the dilemma. That's not to easy to solve.
But my issue is a little bit different. I didn't check the filedgroups for privacy settings at all,but checked the fields within the groups in the cckfp settings. And in this case the padlocks for the individual fields don't show up, but the should.
For the general question. Do individual fields matter, if a fieldgroup is set to private or buddy access? In my opinion, the field access settings should only apply if the are stricter than the fieldgroup settings, e.g. if fieldsgroup is set to everyone and the field is set "buddies", the field setting should apply.
Regards,
ben
#3
Okay, I've been looking into the fieldgroup issue some more - one big hurdle is that fields that are inside a fieldgroup are actually enclosed inside the fieldgroup element. So, if the fieldgroup is not actively set for privacy, the CCK Field Privacy module skips over the fieldgroup AND anything inside of it.
I've come up with one possible solution - store the fieldgroup name along with the field name, for any fields that are inside a fieldgroup. This would require a database change, as well as some work for the field selection & assigning the padlocks. It wouldn't address what bensemmel outlined above about stricter settings for individual fields beyond the fieldgroup; it would simply create the ability to set the privacy level for fields inside a fieldgroup. I see the issue of field privacy priority as secondary to getting things to WORK. Does anyone have a better idea of how to get around the fieldgroup issue? If not, I'll probably code it this way and see where it gets us.
Bryan O'Shea
Obsidian Design
#4
Hi Bryan,
coming back to this after a long time. I think your suggestion would be a reasonable way to go.
As many people working with APK, which splits the user profile into fieldsets to show them via panels, it would be perfect to have the possibility of setting privacy within fieldgroups.
Regards,
Ben
#5
subscribing.
#6
Hi, I experienced the same problem like Ben when I was working with APK and CCKFP and found the discussion about it here. Are there any news concerning the coding? I think too it would be very worthwile to have the possibility to set the privacy settings within the fieldgroups. I can't do the coding (as I don't know how) but I could help testing.
Thank you and regards.
#7
subscribing
It would be great to have CCKFP inside fieldgroups.
#8
Is there any news on when this module will work on fields within fieldgroups? It is a good-looking module but this problem makes it unusable for most applications. Would a bounty of 250 bucks help to get this done in a couple of days (plus incorporating patches for the views issue noted)? [note: We tried the competition (CCK Privacy) and it is unattractive and behaves poorly when form_alter is applied to a form.]
#9
Any bounty would definitely help - since this is a module I support in my free time, any contributions to the module are greatly appreciated and would be noted on the project page. Time wise, my free time is a bit tied up, so it make take a little more than 'a couple' of days, but it would definitely become a priority.
Bryan
#10
Thanks, Bryan. I really understand about the time issue. Do you have any estimate on when this could be done, with the understanding that the aforementioned bounty can be delivered without delay? We just need to weigh our options. Best,
Bob
#11
Bob, my goal would be to have the patch at least partially tested by other people by the end of the weekend. Looking at my schedule, I should have some time to work on the module throughout the rest of the week. Some of the other pending patches could slow things down, but we'll see.
Bryan
#12
Great news - I have a patch for the implementation of hook_nodeapi that solves the problem of permissions in field groups. If you apply both this patch and the patch in #427022: hook form_alter rewrite, padlocks correctly display ONE time, for BOTH fieldgroups and their child fields. Additionally, the stricter preference takes precedence. If a fieldgroup is set to 'everyone' or 'buddy', while the child field is 'nobody', then all the fields in the fieldgroup EXCEPT the 'nobody' field are displayed. All the fields can be set to 'everyone' (or not set at all), but if the fieldgroup is set to 'nobody', then the field group is completely hidden. Also, by the nature of CCK, if all the elements of the fieldgroup are hidden, then the fieldgroup itself is hidden, so no orphan/empty fieldgroup.
Please test out/review & report. I'd like to get this in ASAP, along with the hook_form_alter patch in #427022: hook form_alter rewrite.
#13
Committed to CVS, will show up in the next development release. Please test out the new version to make sure there aren't any issues that come up before I make a new release.
Bryan O'Shea
#14
Pad icon now displaying, :)
But no action while clicking.
#15
install the http://drupal.org/project/jquery_impromptu module
#16
Thanks
Now it is working. :)
and could you please add any display text or any css class about the current privacy status of each field? so it will be very clear to end users.
and I am able to see the fields by another user even I set to private.
Thanks & Regards
Vinoth
#17
Vinoth, can you please check the latest -dev snapshot (May 26), and see if you can still see other user's fields. If you can, could you please send a screenshot or some more details of the settings you're using? I can't replicate the issue of the fields showing up after the patches were applied, but you're not the only person to bring up the issue.
Thanks,
Bryan
#18
hi,
i am using content profile and cck fields and groups,i installed cck field privacy ,i am able to see the padlock only for one cck field under group,if i set the privacy for more than one field under a group ,the padlock doesnt apper even for one field.i applied the patch but same error.
please help.