[buddypress-dev] Privacy component

[Donnie La Curan]

I like this idea of being able to have levels of friends and certain posts
are viewable by those people.

On Mon, Apr 14, 2008 at 6:39 PM, Isaac Chapman <isaac.a.chapman at gmail.com>
wrote:

> I guess this is mostly for Andy and/or Matt...
>
> I would like to contribute to buddypress by creating a privacy
> component which would allow people to set content to only be viewable
> by certain other people.  While WP is a very open platform and is
> great for sharing all its content, "social networks" usually allow
> their users to set up their own walled gardens based on who is defined
> as a friend, friend of a friend, being a part of a group, etc. If this
> is something that would be appropriate for BP, I have a couple of
> questions:
>
> 1. How fine-grained should the privacy options be?  Since it seems I
> read something every week or so about some social network offering
> more fine-grained control over privacy options (to be fair, it is
> usually Facebook making an about-face after changing something
> private-by-default to public-by-default and recoiling from user
> backlash), this seems like a good place to consider both the existing
> BP framework and potential future BP enhancements. As an example,
> while I've never looked at XFN in depth, will XFN potentially be used
> as a basis for determining BP friendships?  To start off with, I think
> the following non-mutually-exclusive options should be available as
> they correspond with what I hopefully understand BP's capabilities:
> a) Public
> b) Logged in WPMU users
> c) Logged in friends
> d) Members of specified groups
> e) Nobody (really only the content creator, but "nobody" is probably
> less confusing to most end users)
>
> Potentially a f) friends of friends - kind of a sql nightmare in
> having to join the bp_friends table several times to itself to search
> for permutations of initiator_user_id and friend_user_id.
>
> 2. What existing and potentially future planned types of content can
> be privatized?  Items in the posts tables seem like a no-brainer.
> Either extended individual profile pieces of data or possibly entire
> extended profile groups seem like they should also allow to be
> privatized, as this would allow for someone to set something like a
> phone number or the "contact" group to only be viewable by friends
> instead of people intentionally leaving some fields blank (phone
> number, email & home addresses, etc.) to prevent identity theft or
> potential harassment. (As changing profile privacy settings should be
> on the same admin page as changing the actual profile data, the
> xprofile_edit function would have to be altered to support this.)
>
> 3. Answers to the above questions will go along way in determining the
> best methods for storing/accessing privacy data, but do you have a
> preferred method of storing this data?  The seemingly normal WP method
> would be to store it as a serialized array, and that can be easily
> done by adding a "restricted_to" or similarly named field to each
> table that contains something to be privatized (this wouldn't
> currently work on allowing bp_groups privacy settings on a user by
> user basis).  Another method that wouldn't alter the existing WPMU
> schema would be to use a bp_privacy table, and while this makes
> intercepting, parsing and altering sql queries potentially more
> troublesome, it does have the advantage of allowing setting
> permissions on arbitrary data that doesn't neatly correspond to
> setting row level security on existing data such as user_email from
> wp_users or other non-extended profile data in wp_usermeta.
>
> Even if being able to privatize content such as posts, pages, links,
> etc. doesn't seem all that important, I really think end users will
> appreciate being able to change the privacy settings of their profile
> data.  From writing a fairly similar WPMU extended profile component,
> the only real changes that are necessary to allow "simple" profile
> privacy are:
> a) Add a "restricted to" field to bp_xprofile_data, allowing options
> a,b,c,e from question 1 above as either enums, integers, or bits (bits
> are better if you want to later add options that are not subsets of
> one another and hence mutually exclusive).
> b) Change the xprofile_edit function to allow changing/saving the
> privacy options.
> c) Change the profile display code to honor the privacy settings.
>
> (This simple approach leaves a user's email address or other
> wp_usermeta data in limbo as far as profile data is concerned.)
>
> Unfortunately, I can't share the profile component I wrote as it is
> contains a lot of proprietary code, and I'm not sure how useful it
> would be anyway as it has to piece together profile components and
> their permissions from several MS SQL tables.  I ended up using a
> combination of permission bits in my profile data table and a separate
> profile permissions table to track the fields of the other MS SQL
> tables containing separate profile data (mostly pre-WPMU associated
> member and demographic information) along with wp_users->user_email.
>
> Isaac Chapman
>
> P.S. It might be worth adding an sort_order type of field to the
> profile tables so the rows will be displayed in a consistent,
> definable order that isn't dependent on the order the fields were
> inserted.
> _______________________________________________
> buddypress-dev mailing list
> buddypress-dev at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/buddypress-dev
>



-- 
Donnie La Curan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://comox.textdrive.com/pipermail/buddypress-dev/attachments/20080414/79f31bdb/attachment-0001.htm