[drupal-devel] [feature] Profile field visiblity should vary by role

Bèr Kessels drupal-devel at drupal.org
Fri Jun 10 09:13:39 UTC 2005


Issue status update for http://drupal.org/node/14149

 Project:      Drupal
 Version:      cvs
 Component:    profile.module
 Category:     feature requests
 Priority:     normal
 Assigned to:  ejort
 Reported by:  sushi76
 Updated by:   Bèr Kessels
 Status:       patch

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 :)




Bèr Kessels



Previous comments:
------------------------------------------------------------------------

December 9, 2004 - 19:38 : sushi76

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.




------------------------------------------------------------------------

March 6, 2005 - 21:40 : tulula

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.




------------------------------------------------------------------------

June 6, 2005 - 06:03 : ejort

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 [1] thread,
but would be much more flexible.
[1] http://drupal.org/node/21219




------------------------------------------------------------------------

June 10, 2005 - 09:07 : ejort

Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.patch (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:



* access a field (for all accounts)
* access a field for your own account
* 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:



* hide some fields from anonymous users, while allowing other roles to
still view that info
* have fields viewable by only the admin and user who owns the account
(like PROFILE_PRIVATE
* have fields viewable by some roles, but only editable by the admin
* have fields hidden from all except the admin, and editable only by
the admin
* 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







More information about the drupal-devel mailing list