[drupal-devel] [bug] PROFILE_HIDDEN updates

[Bèr Kessels]

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

 Project:      Drupal
 Version:      cvs
 Component:    profile.module
 Category:     bug reports
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  pyromanfo
 Updated by:   Bèr Kessels
 Status:       patch

I agree that there are a lot of valid use cases. But I really think all
this must be handled by an advaced_profile.module. We should keep
drupal core clean, that is why we have all the hooks. There are a lot
of hooks that allow you to mke advanced profile modules with
hierarchical-permissions and all, if you wish. But, please, not in
core.




Bèr Kessels



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

April 24, 2005 - 16:34 : pyromanfo

Attachment: http://drupal.org/files/issues/profile_hidden_update.patch (3.28 KB)

Here are some updates to the PROFILE_HIDDEN functionality.


Basically now if you have 'administer users' access, you can edit these
fields and they show up for you in the user's profile when editing.


If you don't then they don't show up for editing at all.  They still
should show up when simply viewing though.




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

April 25, 2005 - 19:00 : Dries

Not sure about this patch.  I'll give it some thought/testing.




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

April 27, 2005 - 14:00 : killes at www.drop.org

I am not sure the current implementation is too usefull. What about if I
want to add fields that users can neither see nor edit (like the roles)?




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

April 27, 2005 - 14:04 : judah

Having this feature would be helpful to me. But there are some
properties I would like to completely hide and some that would be
unnecessary to show the user.




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

April 27, 2005 - 21:55 : moshe weitzman

This is useful functionality. I have deployed drupal into a few
corproations and they often have profile fields like 'title' and
'telephone number' and 'department'. thos fields should be editable
only by administrators. thats what this patch allows, if i'm not
mistaken.




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

May 10, 2005 - 15:43 : pyromanfo

Any updates on comitting this?  I didn't think to check back because
this seemed like the original intent of the PROFILE_HIDDEN patch in the
first place, to make certain fields non-editable for users.




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

May 31, 2005 - 14:29 : pyromanfo

Is this going to be committed?




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

June 1, 2005 - 09:59 : judah

i think it is great but i think we were waiting to hear back on the
suggestion to provide the option to make some fields hidden from the
public AND the user. 


quote,
"...this seemed like the original intent of the PROFILE_HIDDEN patch in
the first place, to make certain fields non-editable for users."


add to that,
"to make certain fields non-editable for users and/or non-visible."


Use case -
JBFish333 has recently joined one of your drupal forum communities. He
has been active for 12 months occasionally helping others. Six months
ago he got into a heated debate with other members. He started using
profanity and disobeyed the rules 3 times. You warned him that he has
to stop and put this behavior in the hidden "Notes" field. He was doing
good and then this month he started using profanity again. You checked
his notes field and saw his history. Because he has been helping people
you warned him again privately that he has one last chance. He has said
that it won't happen again. You made mention of this in the notes
field.
- we don't want JBFish333 to see this profile field.




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

June 14, 2005 - 07:28 : Gestaltware

Typical applications of user fields that are hidden from the user (or
public) are for account control and/or customer profiling. You might
track lifetime revenue and profitability of a customer which you
probably wouldn't want them to see. You might store the initial referer
to cross-reference these against various customer acquisition methods.
You might store the TOS acceptance date, and if the TOS revision date
is greater than the TOS acceptance date, display the latest Accept TOS
form upon logging in. 


These are pretty much standard procedure for commercial sites (not so
much for community sites).




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

June 14, 2005 - 16:23 : ejort

The patch discussed in issue #14149 [1] is another (much more flexible)
approach to gaining this same functionality.


I agree that there are definitely many use cases for this, and other
variations of hiding data from XXX / restricting editing to XXX,
especially in corporate sites.


Cheers,
Eric
[1] http://drupal.org/node/14149