[drupal-devel] [feature] Profile field visiblity should vary by role
drumm
drupal-devel at drupal.org
Fri Aug 12 01:34:09 UTC 2005
Issue status update for
http://drupal.org/node/14149
Post a follow up:
http://drupal.org/project/comments/add/14149
Project: Drupal
Version: cvs
Component: profile.module
Category: feature requests
Priority: normal
Assigned to: ejort
Reported by: sushi76
Updated by: drumm
-Status: patch (code needs review)
+Status: patch (code 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.
drumm
Previous comments:
------------------------------------------------------------------------
Thu, 09 Dec 2004 18:38:09 +0000 : 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.
------------------------------------------------------------------------
Sun, 06 Mar 2005 20:40:34 +0000 : 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.
------------------------------------------------------------------------
Mon, 06 Jun 2005 05:03:27 +0000 : 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
------------------------------------------------------------------------
Fri, 10 Jun 2005 08:07:49 +0000 : 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
------------------------------------------------------------------------
Fri, 10 Jun 2005 09:13:37 +0000 : 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 :)
------------------------------------------------------------------------
Fri, 10 Jun 2005 09:53:27 +0000 : ejort
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* [2]:
"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 :-)
[2] http://drupal.org/node/22565#comment-32248
------------------------------------------------------------------------
Fri, 10 Jun 2005 13:27:15 +0000 : Bèr Kessels
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")
------------------------------------------------------------------------
Tue, 14 Jun 2005 15:22:41 +0000 : ejort
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 :-)
------------------------------------------------------------------------
Tue, 14 Jun 2005 15:37:19 +0000 : Bèr Kessels
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.
------------------------------------------------------------------------
Tue, 14 Jun 2005 16:12:35 +0000 : judah
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.
------------------------------------------------------------------------
Tue, 14 Jun 2005 21:09:23 +0000 : killes at www.drop.org
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.
------------------------------------------------------------------------
Wed, 15 Jun 2005 11:19:20 +0000 : Bèr Kessels
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.
------------------------------------------------------------------------
Wed, 15 Jun 2005 14:14:07 +0000 : Boris Mann
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).
------------------------------------------------------------------------
Wed, 15 Jun 2005 17:22:49 +0000 : fago
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 [3]
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..
[3] http://drupal.org/node/21515
------------------------------------------------------------------------
Wed, 15 Jun 2005 21:44:15 +0000 : dmclark
sorry if this is a nOOb question, but I try to apply the patch and get:
patch: **** malformed patch at line 9: /**
More information about the drupal-devel
mailing list