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: ejort Status: patch 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* [1]: "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 :-) [1] http://drupal.org/node/22565#comment-32248 ejort Previous comments: ------------------------------------------------------------------------ December 10, 2004 - 05: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 7, 2005 - 07: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 - 16: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 [2] thread, but would be much more flexible. [2] http://drupal.org/node/21219 ------------------------------------------------------------------------ June 10, 2005 - 19:07 : ejort Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.p... (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 ------------------------------------------------------------------------ June 10, 2005 - 20:13 : Bèr Kessels 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 :)