my "content_field_privacy" table has an entry where the "field_name" value is "undefined". I checked the database when I noticed that upon reloading a profile, I didn't see anything noting the values I set, and there was only one value in the table even though I was trying to protect two fields. I imagine that the "undefined" value was passed for both fields, so the last field overwrote the first field's info.

My installation process had some errors along the way, so I don't know if that is causing a problem. Here are some things I had to do:

1) the content_field_privacy table had a sql error during installation of the module. So, I manually cut/pasted the CREATE query into mysql. I skipped the " /*!40100 DEFAULT CHARACTER SET UTF8 */" part and hardcoded the table name 'content_field_privacy'

2) I was getting some array_key_exists problems in line 110, saying that the second parameter was not an array. I don't quite know how the variable_get() function works, but it was not returning an array. I checked the "variable" table, and prior to going thru the module admin process of setting parameters, I didn't have a "cckfp_types" value in the table. After I set up some parameters, the error message went away.

I hope this helps. I am anxious to start using this ... although I will have to ask some questions about how to make it work with "user_relationships" instead.

CommentFileSizeAuthor
#10 cck_field_privacy.patch3.4 KBobsidiandesign
#6 cck_field_privacy.patch3.4 KBobsidiandesign
#5 cck_field_privacy.patch2.12 KBms2011

Comments

ChadH-1’s picture

ChadH-1 commented

The cck_field_privacy.js file needs to have the following line of code added at line 21 to save the field settings to the database:

      '  <input type="hidden" value="' + field_name + '" name="fieldname" />'+

So it should look like:

      '<form>'+
      '  <input type="hidden" value="' + field_name + '" name="fieldname" />'+
      '  <div><label><input type="radio" value="e" /> Everyone</label></div>'+
      '  <div><label><input type="radio" value="b" /> Buddies</label></div>'+
      '  <div><label><input type="radio" value="n" /> Nobody</label></div>'+
      '</form>', {
yoyoman’s picture

yoyoman commented

OK, it's saving values now. However, what it's saving looks to be a bit off. When logged in as the admin and editing someone else's profile, it saves as UID = 1 instead of the UID of the user.

I also have a question about user access control. As an authenticated user, my settings won't save unless I check "mopify cck field privacy". I thought it should be "modify own cck field privacy"

obsidiandesign’s picture

obsidiandesign commented
Assigned: Unassigned » obsidiandesign

These two bugs seem to have crept up during the final code cleanup. ChadH is correct about the addition to line 21 in cck_field_privacy.js; I'm looking into what exactly is wrong in terms of the uid setting on the form and the permissions. It seems something got crossed with these two in the final stage.

obsidiandesign’s picture

obsidiandesign commented

Just a note, the initial bug report is a duplicate of http://drupal.org/node/219876. My comments above are in reference to the second set of bugs listed in #2.

ms2011’s picture

ms2011 commented
Status: Active » Needs review
StatusFileSize
new cck_field_privacy.patch2.12 KB

I confirm these two problems are bugs:

  1. The field_name is not stored. Rather than using the hidden input type, let's continue using the OO js closures.
  2. The user ID is always the logged-in user, even when editing a node that belongs to another user. We need to provide $form['#node']->uid for existing nodes, and $user->uid for new nodes.

I have attached my solution as a patch:

(see attached)

obsidiandesign’s picture

obsidiandesign commented
StatusFileSize
new cck_field_privacy.patch3.4 KB

This patch incorporates mikesmullin's fixes above, and another fix that checks for the user id when initially filling in the privacy setting on the form, not just on submit.

EDIT: Patched updated to fix a problem on line 111 (should have made it into the initial patch, I don't know why it didn't, sorry).

yoyoman’s picture

yoyoman commented

Is anyone else getting this after the patch? I applied the patch to the Feb 12 dev version.

Parse error: syntax error, unexpected T_VARIABLE in .... /sites/all/modules/cck_field_privacy/cck_field_privacy.module on line 111

obsidiandesign’s picture

obsidiandesign commented

Fixed the patch/reuploaded - sorry, I knew about the problem, but for some odd reason when I fixed the line, the patch didn't catch it.

bensemmel’s picture

bensemmel commented

Hi,

getting the same error as yoyoman, even with the updated patch.

obsidiandesign’s picture

obsidiandesign commented
StatusFileSize
new cck_field_privacy.patch3.4 KB

Try this one; completely re-done from scratch. I think the original stayed, even though I removed it from the post.

obsidiandesign’s picture

obsidiandesign commented

Has anyone tried the updated patch? Want to make sure it works as intended before I commit it.

bensemmel’s picture

bensemmel commented

Tried the patch and it worked for me...

obsidiandesign’s picture

obsidiandesign commented
Status: Needs review » Fixed

Patch committed. Issue marked as fixed.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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