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: ejort Status: patch 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 ejort Previous comments: ------------------------------------------------------------------------ April 25, 2005 - 02: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 26, 2005 - 05:00 : Dries Not sure about this patch. I'll give it some thought/testing. ------------------------------------------------------------------------ April 28, 2005 - 00:00 : killes@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 28, 2005 - 00: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 28, 2005 - 07: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 11, 2005 - 01: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. ------------------------------------------------------------------------ June 1, 2005 - 00:29 : pyromanfo Is this going to be committed? ------------------------------------------------------------------------ June 1, 2005 - 19: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 - 17: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).