Forum OpenACS Development: What were the contents of priv_email, priv_name etc.?

Request notifications

There are fragments of a per-user privacy level in the current datamodel, like the columns priv_email and priv_name in users. I wonder what values they used to contain or were intended for - I remember vaguely something like that from acs3:

1... nobody should see it except admins
3... registered users

Is that correct? I couldn't find anything on the web where the semantics of these columns are explained.

Posted by Michael Bluett on
It's in Philip and Alex's Guide to Web Publishing, but Philip has edited quite a lot of the old content out. Eve Andersson, however, has an old copy which I have used to find references that I knew were in the book, but couldn't find on Philip's site. The particular page containing the priv_email reference is the one on Users.
Posted by Michael Bluett on
As an aside, the bugtracker currently ignores the privacy levels and displays all email addresses (as I wrote here). It is ideal for email harvesting robots. Perhaps it's time to report this as a bug?
Posted by Lars Pind on
Michael, File a bug report.

Tillmann: Since we've never honored them, I don't think it matter what they might have once stood for. Let's figure out what we want them to mean, and do it for the first release possible (given resources).

I think we'll want something along this axis:

- never show
- show to registered users
- show to other members of this subsite
- show to admins
- never show

perhaps eliminating a few of them.


Posted by Tilmann Singer on
Micheal, thanks for those links - weird that google hasn't indexed that site.

So these were the initial semantics:

0 means "show to everybody"
5 means "show to other registered users"
9 means "show to nobody except maintainers"

Lars: yeah I don't say we have to copy them, I was just looking for inspiration, assuming that there might have gone some thought into it by aD already.

I think 'never show' and 'show to admins' is redundant, at least if you mean site-wide admins, since those could always look into the db directly anyway. 'Show to other members of subsite' makes a lot of sense though - I wonder if 'show to admins of subsite' would be needed too.

I think assigning it integers with some gaps in it for future or site-specific extensions would be good, as well as making it scalar (is that the correct word?) so that higher values always mean more restricted, with 0 as lowest value 'show to all', so that comparisons like $priv_email>$privacy_threshold will always work regardless of later extensions.


May I suggest one more level of privacy: "show only to co-member", with "co-member" I mean one who is a member of at least one group in which I'm a member too.

Posted by Tilmann Singer on
Emanuelle, I don't see how this would be generally useful, but what's even worse I don't see how this could easily be implemented without adding a database call into the (hypothetic) user_display::get_name which would get executed for each returned name when assembling a list of names.

But I think the initial thought behind the numbering scheme was that sites could insert their custom privacy levels if they wanted to, and if the display proc would be nicely centralised then that would be easy.

Apart from that - what level of group/subgroup membership do you mean? All users of a site are part of the same group - Registered Users - for example, which would make the privacy level useless.


The level of groups I was thinking of, is clubs or classes as in a .lrn environment. I don't know how this could be implemented, I'm not familiar with openacs4 API and data-model. At Uned, we have a acs3 site in which we configured this privacy level so students may share their personal data (email, address, phone, etc.) only with their classmates. Also, the privacy level chosen for email can be different then the one chosen for address or phone.