[geeklog-devel] GSoC 2010 is on

Fri Apr 2 06:24:37 EDT 2010

That scenario should not come up. Groups are not reciprocal and they 
are not necessarily public. A user who wants to set the group 
permission of a socnet object should only see his personal groups in 
the drop down. Just because you've added me to one of the group lists 
you want to maintain doesn't mean I can see that group. The socnet 
plugin will need to figure out how to differentiate between "Jakh's 
Private List of People He Sends Joke Links To" and "The New Jersey 
PHP User Group". In the first case, the list is only used by Jakh to 
create Links and share them with Jakh's friends. The people on the 
list see the links but cannot examine the list since it's private. 
The second list is obviously supposed to be public and every member 
of that list should be able to set permissions of an object to 
include that list.

This is why the core code stays away from user owned groups. The 
context of what the user owned groups mean is not understood by core. 
It is only understood by the socnet plugin. In my original proposal 
there were several kinds of groups and rules for inviting people into 
public groups and approval systems for groups and how reciprocal 
friendship works, and so on. None of that is in the patch. The patch 
contains only what is minimally sufficient to allow all of that stuff 
to be written as part of a plugin. Someone still has to come up with 
all those rules and determine how they will be enforced and how they 
will be conveyed to the user via the browser. None of that is core's business.

As the feature request in the bug tracker explains, there is a 
downside to this. Currently there is a global in Geeklog $_GROUPS. It 
contains the list of all groups the currently logged on user is a 
member of. It is used by SEC_inGroup to determine if the current user 
is a member of a group. It is also commonly used in SQL statements of 
the form: "WHERE group_id in (" . explode(',', $_GROUPS) . ')'; to 
select a set of objects to which the current user has permission to 
view. That all is unchanged. The problem is the dropdown box created 
by SEC_getGroupDropdown. This function also attempts to use the 
$_GROUPS array to create a list of <option> tags for a <select> 
block. The problem is that this is not the right way to go about it. 
Just because I am in your friend list doesn't mean I should be able 
to create objects visible to all your friends or any of the other 
friend lists I'm on.

So the simple solution is to force SEC_getGroupDropdown into 
Administration only duty. It only returns system groups. If you need 
a list of groups that should appear in a dropdown list with the 
socnet plugin's approval, the socnet plugin will need to provide a 
function that does that. My guess is there will be a gl_socgroup 
table in the database. At the moment I assume it would just contain 
grp_id and grp_type fields but I could see other fields being added 
as the socnet plugin needs control data for its groups.

At 04:35 AM 4/2/2010, Jakh Daven wrote:
>Content-Type: multipart/alternative; boundary=001636426fe35b843d04833cdc40
>Content-Transfer-Encoding:
>
>Hi Joe,
>
>I am a would-be GSoC student participant and I am interested in 
>taking up the Socnet project. I will go through your patch, test it 
>during the weekend and try to figure out how it fits in with socnet. 
>I have glanced through the documentation in the feature request and 
>I would like to add a few points on how Socnet will handle this in 
>my view. From the feature request page:
>
>Code displaying this (such as SOC_getGroupDropdown) would need to 
>handle how to display the group names intelligently.
>
>
>Will the group names in the drop down be unique?. If yes, we will 
>need to get the user name from the uid and attach it to the group 
>name (since group names are not unique). For example the drop down 
>would contain the following items:
>    * Joe Mucchiello's Friends
>    * Jakh Daven's Co-Workers
>    * Jakh Daven's Friends
>Is this correct? We will need to handle user name+group name clashes somehow.
>
>As you said, even if it does not make it into 1.7.0, it will be very 
>useful to the gsoc devs, Thanks for the patch.
>
>Cheers,
>Jakh
>
>
>On Fri, Apr 2, 2010 at 11:30 AM, Joe Mucchiello 
><<mailto:joe at throwingdice.com>joe at throwingdice.com> wrote:
>At 01:39 AM 4/2/2010, Vincent Furia wrote:
>Only had a few minutes tonight to take a look. Have a couple comments though:
>
>1.  1.7.0 introduces Postgresql support, we'll need SQL updates for 
>it as well.
>
>
>Yeah, I know. I can read the docs and make something up. But someone 
>more familiar with pgsql should write that. If I had been targeting 
>1.7.0 directly, I'd have created the files at a minimum. I just 
>figured 1.7.0 is a moving target and a 3-way merge with mercurial 
>should be easier than it use to be with CVS. Someone just needs to 
>checkout from the 1.6.1 commit. Merge my changes and then try to 
>push the changes back up. (Although, I admit, for me this is just my 
>understanding of the theory behind a DVCS.)
>
>
>2.  Since your using the column grp_owner in where clauses everytime 
>you select from the group table, I think we need an index on it. I 
>think the UNIQUE INDEX in MySQL also acts as sorting index, but I 
>don't think (but I'm not sure) that a MSSQL CONSTRAINT acts as an index.
>
>
>Again, I just mirrored what I saw in the mssql files. If what you 
>say is true there are potentially no indexes (other than primary key 
>indexes) on the mssql install as I see no place where a CREATE INDEX 
>statement is executed. Unfortunately I don't have anywhere to run 
>mssql to test it out. Ultimately, I wasn't worried about indexes on 
>the database because they can always be tweaked ad hoc in a worst 
>case scenario. Besides, Geeklog is lousy about indexes. If you've 
>ever upgraded a database continuously from an early version you 
>might end up with duplicate indexes on various tables.
>
>
>I'll have more time to look at it over the weekend.
>
>
>Thanks.
>
>
>P.S. You may be a bit late for 1.7.0. Dirk indicated a feature 
>freeze earlier this week and is aiming for a Beta 1.7.0 over the weekend.
>
>
>I always miss the feature freeze emails. Looking back he didn't 
>actually call it a feature freeze. Just a beta this weekend. I sent 
>him an email about this yesterday that he didn't answer. So I can 
>still hope this time I made it under the wire. Technically I suppose 
>this only needs to be part of 1.7.1hg so that GSoC devs can use it.
>
>
>----
>Joe Mucchiello
>Throwing Dice Games
><http://www.throwingdice.com>http://www.throwingdice.com
>
>
>No virus found in this outgoing message
>Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.176).
><http://www.pctools.com/free-antivirus/>http://www.pctools.com/free-antivirus/
>_______________________________________________
>geeklog-devel mailing list
><mailto:geeklog-devel at lists.geeklog.net>geeklog-devel at lists.geeklog.net
>http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 

No virus found in this outgoing message
Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.176).
http://www.pctools.com/free-antivirus/