Forum OpenACS Improvement Proposals (TIPs): Tip #73 (Approved): Enable to Hide/Show User Email
Let the user to decide if he wants to show his email on the /shared/community-member . That will be managed from /pvt/home but that implies to add a data field on the users data table called show_email_p that for default will be null…
Another related thing is to let the SWA to hide/show emails of registered users using a new parameter show_users_email. This SWA action will not override the user selected action while show_email_p if its true or false, because if it is null then we know the user hasn't changed it manually yet, therefore the SWA changes will be used instead of user personal preferences.
This is a must-have feature for any site.
Do it on HEAD, before oacs-5-2 is branched, also implement it at opeancs.org. We already have partially the code working.
If you feel like getting deeper than a simple site wide on/off form option for email implement it in a way that allows levels of permission on the entire profile: e.g. I want my friends (and friends of friends) to see my entire profile (email included), but registered users and non-registered users to only see X,Y, and Z (with contact option over email limited to the form). For an example of different levels of view permission from a web based social networking site see orkut.com (which has permission level of profile based on relationship to user: friend, friend of a friend, strangers).
Now to make it even more interesting: with roles and different kinds of groups made possible by OpenACS it gets fun quickly (hypothetical example from .LRN: multifaceted student X wants to share certain parts of her profile with the pink commie hyper-liberal dissenter political student "club" she attends on Tuesdays and other parts of her profile with the young neo-conservative republican group she frequents Thursdays).
We need a user profiling system, that allows any community member to give permission on the elements of his profile. Which involves a considerably better UI for permissions in general, but let's take it step by step :).
One thing you have to take into account, that /shared/community-member is not the only place to access the e-mail of the user. Therefore you should enforce that parameter site wide. Which is difficult taking into account that you can just query the database :).
Will this completely hide the email address, or will it just take out the end of it or something?
The sencond stage will be to show the email for the public but not in an easy to grab it by spammers, lets say, the email will be shown like myemail AT thesite_dot_com, or if imagemagick is installed, then we'll show it as an image, but this will go in another TIP.
Another related thing is to let the SWA to hide/show
emails of registered users using a new parameter
You should take a look at the priv_email column. I believe at one time it was supposed to serve this purpose, "priv" being an abbreviation of "private".
I have no idea why it's an integer that defaults to 5.
Apparently that got copied partially into the ACS 4.0 datamodel but without the logic that actually implements it in various page queries.
"there were a bunch of similar fields in ACS < 4 the notion was a hierarchy of "privacy levels" you could set that would get increasingly tighter as you changed the level"
"Apparently that got copied partially into ACS 4.0 but without the logic that actually implements it"
1) The site wide admin can decide whether or not to expose the new option. Though the trend is to allow for more privacy when it doubt, the anonymity tends to weaken an online community because the members are less accountable. Better to encourage accountability, IMO. I'd even suggest putting a note on the admin page that says something along the lines of "You can allow users to hide their identities if privacy is critical, but you should be aware that this will tend to weaken your community".
2) At a minimum core should be checked for places that expose the user's email address, to make sure that the new parameter is obeyed. If this isn't done carefully it will do more harm than good, as people will now be counting on anonymity in a way that they weren't before.
3) Documentation must be written describing how to use this feature, and that documentation must be added to a list of necessary coding standards for "Mature and Standard" packages (I'll do the last part)
4) A test case is provided which sweeps code for possible violatons (ie, looks for any query of user email address and, perhaps, checks to see if the parameter is named within x lines of code.)
5) The original proposer is responsible for completing the work (this wasn't explicit in the TIP)
I agree and will implement Joel & Andrew's suggestions
And this is how it works:
acs-subsite with improvements:
acs-subsite has now a way to protect users emails by allowing users to choose the way
they want to show their e-mails, the field priv_email field at users table handles that:
4 = Normal email text link (mailto)
3 = As an image (Need ImageMagick software)
2 = Contact the user using a form.
1 = Not showing the email at all
If the user hasn't change his/her email-privacy-level (how the email is shown), then the site-wide-admin can choose how email will be shown by the EmailPrivacyLevelP parameter of acs-subsite.
One proc,"get_user_email", does all the work. So if want to show the user's email, you MUST use this function, that will return the proper html code.
For #3 level, when someone goes to shared/comunity-member's page for instance, the get_user_emai proc generates an image if is created (if
the user or the site-wide-admin especified and if the ImageMagick software is present) with the email of
the user on it, if the ImageMagick software is not present then the @ symbol is replaced with an image
to protect the email. If the email-image was created then it's stored on the content repository.
When a user edit his/her email then a new revision of the image is created as well.
A relation was created between the item_id and user_id to know what image is asociated to a user_id.
A content_folder and content_type were also created to store the users email-images.
For #2, when the user doesnt want to show their email, will be given link to a form were a message can be
sent to the user without showing his/her email.
The change of the level of privacy makes an update of the users table by changing
the priv_email field. All new users have for default level 5 in the priv_email field. When the priv_email equals
5 then the way that emails are shown is especified in the PrivateEmailLevelP parameter, otherwise the email will be
shown in the way that users especified (priv_email 4,priv_email 3,priv_email 2,priv_email 1)
The site-wide-admin can change the PrivateEmailLevelP in the acs-admin/users were a link to manage-email-privacy was created. And the user can change the way his/her email is shown in pvt/home.
We also change this pages that were showing the email of the user as well:
dotlrn/www/mebers.tcl (Mebers list)
dotlrn/www/spam-recipients (Spam all users)
Thanks to Miguel that did the development of this feature. (it works for pg and oracle =) )