By rick hood on

Profile fields (5.x) have this visibility option: "Private field, content only available to privileged users."

How does that work with Access Control? I don't see anything about it here:

http://drupal.org/handbook/modules/profile

Thanks, Rick

⋅ Categories: Drupal 5.x

Comments

rick hood’s picture

rick hood commented

Does anyone have any knowledge about this? Appreciate it, thanks, Rick

rick hood’s picture

rick hood commented

I still can't figure this out - anyone know how to do this?

rick hood’s picture

rick hood commented

Although I did not find the answer to my specific question, I did find a way to do what I needed to do (profile field permissions) so am posting answer here in case others need it.

This is great: http://drupal.org/node/35728

In combination with this: http://drupal.org/node/45774

Those two combined give you a way to allow profile fields to be viewed only by certain roles.

cozzi’s picture

cozzi commented

Is there a more text book answer to this Profile Field Visibility option? There must be some documentation somewhere about this?

decomposer’s picture

decomposer commented

This is explained in sorts at http://drupal.org/node/298699 -- #2

"Users with the "administer users" permission can see the private fields, but other users cannot. Make sure you test the search functionality with a non-admin user."

So, I take it that any user with permission to administer users will have access to this field. I've checked this and it does work that way.

mrtoner’s picture

mrtoner commented

A user can see private fields on his own profile, but not those of other users unless he has "administer users" permission. And I'm not sure if the information at the link above is authoritative, since the information given is for the Profile Plus module, not the core Profile module.

Raf’s picture

Raf commented

Doesn't seem to work for me.

Edit: I did some testing, as I fiddle a bit on the user page and thought that might influence things. The database itself gets the fields. There're no values in there, though (cause I can't fill them in anywhere).

The form, before the form altering (mainly changing the width of input fields and unsetting descriptions), doesn't have the new fields though. The data passed to hook_profile_alter doesn't have the new values either. Both do show the fields I entered about a month ago.

Flushing caches didn't help. Saving over and over and over, both fields and the entire profile setup, didn't help either.

This all is in both the root account and an account with "administer users" added specifically. I tested these permissions by printing data if user_access('administer users') is true, and that worked just fine.

Edit: Even with both the changes in hook_form_alter and hook_profile_alter commented out and just printing the data where the old fields're in, the new fields don't show up. They all belong to the same group, though (Profile, with machine code prefix profile_)

Edit: Alright, they show in the "add user" form, just not in the "edit user" form.

Edit: If I put "private" on, the fields don't show in the "add user" form either, even to those with "administrate users" permissions. Except when "show in registration form" is selected. That puts the "private" on the sideline.

Raf’s picture

Raf commented

Now this is very odd... The fields work just fine as soon as there's at least one user with info for those fields.

Another problem I have now, is that I can edit the fields just fine, but can't make them empty again -- even though they're set as not required.
Looking further into this.

Edit: Even more odd... When I edit one of these fields to contain nothing more but a single space, it accepts it. When I save and go back to the form again, the field contains a single space. When I save it a few times over and over to contain only a single space, it remains like that. Then, when I remove that space, so there's nothing in the field, it saves. When I then go to the form again, it's got the value from before I filled in that single space!

When I fill in 3 different values (full strings of several characters), saving after each change, it accepts each change. When I then change it to be empty, it goes back to that very first value. Does it somehow set the very first value ever entered for that field as the default value for every member?

Edit: How very, very odd... It works just fine for another user!

Edit: Ok, the one that always resets to the first value has an entry for that in the database. The other user, where it works just fine, doesn't. The difference between the two, is that the one that resets to the first value, was made using the user registration form, while the other one existed before these changes to Profile were made.

The correct values don't come from the profile_values table, but from the users table, more specifically from the data field. Only the value set in the user registration form actually goes to the profile_values table.

Edit: Tried making a new user. It acts like the user that was made before these changes. In other words: if you don't have the fields set as "appear on user registration form", none of them'll work properly.

When "appear on user registration form" is set, it works just fine -- except for edits (same issue as mentioned earlier, with the users table). This is for both public and private fields. It also doesn't matter whether you change it as admin or as the user himself (when given proper permissions in case these are necessary).

This all is also the case with the old fields I already had set and thought worked just fine.

I don't know what the data field in the users table is for, but I guess it's a cache for users or something like that...

Time to check whether or not it actually handles those form elements in the edit form.

Edit: One step closer... Profile_user() gets called, which calls profile_save_profile(), which saves all fields _profile_get_fields() returns. That last function returns all fields, based on a category passed on in its parameters. Profile_save_profile() gets that category from a parameter it gets passed on from profile_user(), and profile_user() gets it from parameter as well.
Now, the problem with that, is that that parameter is called account, while it should be called profile...

Will look further after lunchbreak.

Raf’s picture

Raf commented

Some things got inbetween, so couldn't finish it after lunchbreak. Finished it now, using hook_user and calling profile_save_profile both for insert and update, manually passing the right category along. Works like a charm, although I somehow doubt it's the way it's intended to be done.

jsr47’s picture

jsr47 commented

In case it helps you, I've written a module that gives some finer grained control over profile category visibility. It's hard to tell from your post what your goal is: mine was to have a 'private' category of profile information, in my site's case containing the user's snail mail address, for distribution of a newsletter. Obviously, that was not something we wanted revealed to all members of the site.

http://finity.org/content/drupal-limit-profile-categories-visibility-sel...

With this module installed, each category of profile information can be made visible or invisible to each user role. Note that it does not affect the visibility to the user himself - all users will be able to see all categories on their own profile, and edit them.