Currently there are only these three Options

Private field, content only available to privileged users. (Admin users)
Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list)
Public field, content shown on profile page and on member list pages. (Everyone, everywhere)

It should be possible to set the visibilty of profile fields by user roles.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tulula’s picture

I agree!

If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields.

moshe weitzman’s picture

Title: Profile field visiblity » Profile field visiblity should vary by role
ejort’s picture

I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc.

More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates thread, but would be much more flexible.

ejort’s picture

Assigned: Unassigned » ejort
FileSize
12.97 KB

Hi,

Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to:

  1. access a field (for all accounts)
  2. access a field for your own account
  3. edit a field for your account

Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect.

I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg:

  1. hide some fields from anonymous users, while allowing other roles to still view that info
  2. have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE
  3. have fields viewable by some roles, but only editable by the admin
  4. have fields hidden from all except the admin, and editable only by the admin
  5. it will make you more attractive to the opposite sex etc.

I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that.

Cheers,
Eric

Bèr Kessels’s picture

I am not too sure about this.
A typical profile contains between five and 10 fields, but twenty fields is not unheard of. This patch will flood the permissions screen unnneccesary.
I would opt for the hard way: An advanced profile module, or CRM module, or so. hat module could implemen,t all sorts of advanced levelled permissions.
In order to maintain a high level of usability in core, we should try to minimize options and checkboxes. I know from flexinode, which adds similar dynamic permissions, that the interface for permissions is really not up to this big amount of permissions. I really think such things should not be in core.

Buty that all said, it /is/ a handy feature :)

ejort’s picture

Yes, unfortunately it can add a large number of permissions to the permissions page. I did consider trying to place the permission selections on each fields edit page instead (similar to the visibility settings), but as a certain eminent author recently wrote*:

please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages

:-)

I think that the PROFILE_PRIVATE and PROFILE_HIDDEN (and the PROFILE_PUBLIC_*) settings are currently doing just that, implementing an alternate permissions system which addresses a few use cases, but is ultimately not particularly flexible.

Is there any chance that the permissions sections can benefit from some collapsible goodness to alleviate the flooding? I think it's a shame to reduce the systems flexibility because it may create 'too many' permissions settings, especially as it is generally a set once and forget proposition. Perhaps we should look at the underlying UI problem?

*That would be Bér :-)

Bèr Kessels’s picture

Ejort, I know i wrote that. However, this is a little bit different. am not saying you should make a new system for changing the apperance of profile fields. I am only saying that having per-profile-field permissions is:
* way OTT for the big mayority of users
* extremely cluttering for the permission page (which, essetially is a problem in that interface, not in your "feature")

ejort’s picture

I don't agree that this is extremely off topic for most users. A large number of people using drupal in any business setting will likely find the extra flexibility invaluable (and the use cases popping up in discussions for regarding PROFILE_HIDDEN show that the current approach doesn't cover enough of the possibilities).

I've worked on multiple jobs where I had to create contact lists and employee profiles where basic information was accessible to the public (name, work email, profile text), certain details (direct phone numbers) were only visible to internal company employees, other data (mobile phone numbers) were visible only to team leaders, other data (next of kin contact details) were only visible to an admin, and the user wasn't allowed to edit certain items (such as the public profile text). I've had similar needs come up across several jobs, but then again I wrote the patch so of course I needed it! :-)

I also believe that the permissions page problem isn't too large an issue. The permissions are created in response to the admin creating profile fields (3 per field, 'access', 'access own', 'edit'), so the page has no extra permissions by default. This also isn't an interface that is accessed on a daily basis, and there is a good visual separation of the sections so it is easy to skim past the longer profile section if that's not what you're interested in.

Of course, this is all just my opinion, and I'm a biased observer :-)

Bèr Kessels’s picture

I know its a handy feature, that will be used in some cases. But then it should nbe in an advanced-profile.module. Not in core.

judah’s picture

I would have to disagree with you ber on this one. I have posted some comments on the Hidden Profile update mentioned above.

The permission system *should* be apart of core. These shouldn't be broken out into another advanced module. There *shouldn't* be a node_privacy_by_role. This is unheard of in other systems. I have worked on many other cms solutions and permissions is always a part of the design. Should we plaster them on every feature? No. But we should not so easily dismiss this issue. Node privacy by role and field privacy by role should be considered more closely as a core function rather than where it is now. IMHO.

Having said that I do understand the need to break things or branch things too. So it is up to you designers to consider this.

Assuming this patch gets approved I would suggest you make the role assignment options available on the profile edit page if it's not already.

killes@www.drop.org’s picture

judah: Drupal has the benefit that we can use any node access scheme we like by using another module.

@all: I think the best thing would eb to make profiles nodes and wait for cck for field based permissions.

Bèr Kessels’s picture

I think an interim solution would be to:
* make profiles nodes
* use Flexinode if one wished for profiles . otherwise use a dediceated node for this
* add per field permissions to flexinode.

Boris Mann’s picture

I think that profile does indeed need to be re-vamped at some point, and making it a node is likely the right way to go -- then we can benefit from all the field-level work that is going on as we head towards CCK.

This is a good interim patch, and should likely be applied to HEAD until someone comes up with the one true profile node -- following our motto to commit things a little earlier so that they can get some testing and use, rather than waiting forever. I know we have a need for it right now as well, and so will help keep this up to date.

The one issue is the UI for permissions. It should probably be a separate screen, rather than access control. I would put it directly in the per-field edit screen (e.g. admin/setting/profile/edit/1) or be a permission tab (e.g. admin/setting/profile/permissions).

fago’s picture

the profile node sounds good.

i think it's also good to have the possibility to define profile fields for different roles only, so that every role has its own profile.
i've done recently a site, where i needed very extended profiles - so i wrote a profile.module based on the drupal profile.module which does this and a lot of other customized stuff.. i also introduced profile-fields, which can be edited only by user with "administer users", as mentioned here.

i think, you might run into same problem i did:
i already mentioned this issue

i'm using this patch, i posted there, on this site.
otherwise a user could just inject data, with the same name as admin-only-field, in the user-data field, which will be loaded in the user object by user_load(). further profile_load_profile won't overwrite the value..

dmclark’s picture

sorry if this is a nOOb question, but I try to apply the patch and get:
patch: **** malformed patch at line 9: /**

drumm’s picture

Status: Needs review » Needs work

There needs to be an upgrade path so existing private and public settings are set up ad permissions when people upgrade.

Code which becomes unused, such as the old constant definition, should simply be deleted.

In scanning through the comments it looks like profiles as nodes came up. This is a bad idea at this point because a lot of work is actively being done on the node system by John with Content Creation Kit. It would be somewhat like building without a solid foundation, or simply making CCK work harder than necessary. I think this would potentially introduce other issues. Any discussion of profiles as nodes should be moved off of this issue so this patch, which appears to not need it can go through.

budda’s picture

I merged this patches functionality in to custom profile module which also includes taxonomy functionality and profile field searching.

To avoid the huge amount of access control check boxes (which I got because there were about 40-50 profile fields!) I made the following changes:

* Re-added the 'private' radio for Visibility setting.
* If visibility==private then the access control checkboxes for that field only are added to the main permissions page. You can then set access/edit own field, view other users profiles, all based on roles.

I've just put it live on a site where it's going to be tested better by the admins.

If all goes well i'll re-upload this modded profile.module to http://www.ixis.co.uk/drupal-modules/profile (module is 4.6.3 based)

Patrick Nelson’s picture

budda,

Is there any chance of having this patch updated for 4.7?

It's brilliant and exactly what I need.

Regards

Patrick

Patrick Nelson’s picture

Sorry, figured out how to do it. It wasn't that difficult, after all.

If anyone else wants this patch for 4.7, drop me a line.

moshe weitzman’s picture

ay progress here? a HEAD version of the patch would be nice.

__Tango’s picture

Patrick Nelson, can you post your patch here?

Patrick Nelson’s picture

FileSize
31.76 KB

I'm really sorry about this, everyone, but I've subsequently decided to drop the patch on my own site.

I've managed to dig around and find the altered file with the patched lines in. Unfortunately...

1) I cannot patch so I've had to attach the full file. Hope someone can make sense of it

2) My alterations were done against profile.module v1.127 so if you want it against the current HEAD or CVS version, you'll have to work backwards to this version and then forward again.

I'm really up to my neck in it with work at the moment on my own site, but if I get chance, I'll try and do the patch again against current file.

In the meantime, if there is anything that I can do to help anyone, please ask.

munga’s picture

FileSize
8.31 KB

attached.

diff -uw --strip-trailing-cr profile.module\?rev\=1.127 profile_5.module

__Tango’s picture

Status: Needs work » Needs review
FileSize
9.67 KB

This is a patch that will apply cleanly against the latest CVS version 1.132.

__Tango’s picture

I have applied this patch, however i have 102 fields in my proflie (yes, 102). and as Ber Kessels wrote earlier the access control screen gets a bit out of hand.

It seems that there have been a fair number of requirements as well as suggestions for what the future of the profile.module is. I'd like to know what direction the drpual core team is looking at. There was some mention of using CCK or Flexinode, but i'm not sure about the details of CCK, so will it provide the ability to have per-field (or per-"field group" maybe) acls by role or by user?

budda’s picture

Patrick,

Without installing you patch, could you tell me if you did anything different to the one i produced earlier in this thread.
If it's the same, I can probably chuck together a HEAD/4.7 patch for my stuff.

Patrick Nelson’s picture

If I recall, I did have to make some changes to make it work for 4.7. It would probably have been Forms API changes using the formupdater.module.

Other than that, I doubt I would have changed anything else.

__Tango’s picture

budda, in looking through the profile_5.module that Patrick Nelson posted and your profile.zip on your website, it looks like there are some significant differences. I just noticed that the profile_5.module does not have any of the taxonomy stuff.

budda’s picture

Tango: the patch in this thread is for visibility settings in profile.module

The modded profile.module on the (Ixis) site does lots more, taxonomy, field searching as well as the visibility.

I recently submitted the search stuff again as a seperate patch for profile.module HEAD/4.7

__Tango’s picture

budda: could you explain what taxonomy features you added to your custom profile module? Also, can you post your patch here, or point me at the node that contains it?

sami_k’s picture

The patch doesn't apply cleanly against 4.7b5 in case anyone wanted to make a new patch... I think something like this should be committed, because it's pretty much required for any type of site with multiple types of users.

drumm’s picture

Status: Needs review » Needs work
alexis’s picture

Is this already in CVS? I am seeing the profile fields permissions under admin/access in the latest CVS.

Regards!

nydrupalfan’s picture

I don't think it is in cvs yet...

This is a great feature! There are some profile fields that admins don't want users to edit. Could someone re-roll a patch for the latest cvs? Also, possible bug: when using the old patched profile.module, member list pages don't seem to work unless the user has the "administer users" permission. Without it, they get "access denied."

Robin Monks’s picture

The issue located at http://drupal.org/node/14149 was a duplicate of this issue. Please move all discussion and patches to this issue.

Robin
I ♥ Bugz

igrcic’s picture

Hi guys,

what do you think about idea that parmission shouldnt be on field level, but on category level? And fields are cateogrized in profile categories.

Dont know if this is allready mantioned yet here...sorry if it is.

LAsan’s picture

Version: » 7.x-dev

Feature request moving to cvs.

ejort’s picture

Assigned: ejort » Unassigned

Unassigning myself from this.

hermanstrom’s picture

Version: 7.x-dev » 5.7

hi! i am new to drupal, bumping my way around it. i mostly don't know what i am doing. i saw you post on a node http://drupal.org/node/14149 #24, where you attached a patch profile.acl-by-role.1.132.patch 9.67 KB. i wounder if you know where i can get something like that but for more current revision, mine is $Id: profile.module,v 1.189.2.8 2007/07/26 19:16:48 drumm Exp $. thank you, herman

StevenPatz’s picture

Version: 5.7 » 7.x-dev
paschy’s picture

Hello,

is there any similar patch for d6?

LXNdR’s picture

I could need one too.

jsaints’s picture

I can make this patch happen for HEAD for 7.0, but first I would like to know from the experts on the profile module what they think about the earlier comment:

"what do you think about idea that permission should not be on field level, but on category level?"

We could build permissions so that only certain roles can access certain profile field categories. This might make a lot less clutter on the permissions page.

Thoughts? Pros/Cons?

Thanks

babbage’s picture

Subscribing.

spudfpdv’s picture

Hi Guys,

This should sort it out: http://drupal.org/project/profile_role

Profile fields based on roles:

Relate profile field categories to particular roles, instead of all fields being related to all roles. Use profile to define all user data fields, but restrict which fields are related to users of a particular role. The interface allows you to relate profile field categories to roles. As the screenshot depicts, one or more roles may be assigned to a give field category.

Regards.

Damien Tournoud’s picture

Status: Needs work » Closed (won't fix)

The profile module is obsolete, and field access allow this. Won't fix.

hixster’s picture