Re: Sharing membership between different Plone sites

<VasudevaService-K9y3B4ipJAZZAIG4hdpdiNBPR1lH4CV8@public.gmane.org> (Priyadarshan) Mon, 22 Mar 2004 21:56:43 -0500
Newsgroups gmane.org.misc.vasudeva-server.web
Message-ID <[email protected]>
Dhyani,

your post is superb.

I created a permanent article here:

http://www.vasudevaservice.com/technical_articles/sharing_membership

I will comment on it later.

Thank you so much


priyadarshan
Vasudeva Server


On Mar 22, 2004, at 9:50 AM, (Dhyani) wrote:

> This is a message to all those who have been asking themselves: What  
> will
> happen it the world out there wants to become a member of one of our  
> new
> Plone-based sites - say, on srichinmoy.org - and then they go to
> srichinmoyraces.org or any other of our dozens or hundreds of sites,  
> and
> they want to be members of those, too - will they have to join each of  
> these
> sites individually, or is it possible to create an architecture such  
> that
> once they joined one site, they automatically joined all of them?
>
> That would be nice. But then, what happens to the member folders where  
> they
> can leave their wonderful comments about us? Let us say someone puts a
> comment about a race - on srichinmoyraces.org - then we wouldn't really
> appreciate to see this comment popping up on srichinmoylibrary.org.
>
> So, what we are looking for is an architecture that follows the  
> paradigm
> "membership - globally, member folders - locally".
>
> Fortunately, there is a straightforward solution. When you create a new
> Plone site, you are given the choice between the two options "Create a  
> new
> user folder in the portal" or "I have an existing user folder and want  
> to
> use that instead". While the first choice is the natural one under  
> normal
> circumstances, in our case we would select the second one. (Actually,
> deleting the acl_users inside a Plone site later on gives the same  
> result -
> as I just checked on my http://www.vasudevaserver.org:7091/Dhyani  
> which I
> mention because there were already some faithful members there, who  
> are now
> gone with the wind.) - Now, what happens is that the Plone site  
> inherits the
> next acl_users that it can find on the acquisition path, as can be  
> checked
> on Jagrata's new architecure where the Plone sites are not the direct
> children of the root, but of /home or /pub, respectively. The obvious
> architecture would be to have only one acl_users - either at the root  
> or
> inside /pub (for the public) or inside /home (for us guys).
>
> And of course, Plone will create a fresh Member folder for these users
> inside the current Plone site (on first-log-in-time, not on join-time,
> because there is no join-time for 99% of the sites!) This is not  
> unexpected,
> since a Plone site doesn't really have a chance to know about those  
> other
> Member folders in those other Plone sites, because a Plone site never  
> really
> knows anything about other Plone sites - a Plone site is a Universe.
>
> Unfortunately, the world is a complicated place at times (as we know  
> from
> Calvin and Hobbes). This global acl_users would work for all the Plone  
> sites
> underneath, BUT: it would not be a Plone-acl_users file, but a
> Zope-acl_users file. What are the consequences?
>
> 1. The good news is that the roles that are not part of the default
> Zope-users-system (like reviewer, editor - Zope thinks only in terms of
> manager, owner etc.) can be added on the Zope-level. They don't make a  
> lot
> of sense there, but Plone inherits them and Plone does understand their
> significance. What I mean is that when a user is a reviewer on the
> Zope-level, which doesn't mean anything to Zope, then he is also a  
> reviewer
> on the Plone-level, because Plone inherits the user properties from  
> Zope's
> acl_users, and Plone understands "reviewer" as "someone who is a Plone
> reviewer", which is a very good thing.
>
> 2. The not-so-good-news is that we are losing the  
> Group-aware-User-Folder
> stuff, since that is a Plone feature and not a Zope feature. Maybe I  
> can
> comfort Priyadarshan here a little by mentioning that we could have a
> different architecture for us (developers, editors etc.) and the  
> public,
> using Plone's user system for us and Zope's user system only for the  
> public,
> since it is the public's membership issue that we concerned with  
> anyway, and
> who wants to put them into different groups?
> - By the way, if anybody thinks he's just got a very smart idea: why  
> don't
> we put all our Plone sites into one big Parent-Plone-Site, with the  
> Parent
> containing an acl_users file (which would then automatically be a
> Plone-based Group-aware-User-Folder-acl_users file) and which would be  
> the
> one that all the children Plone sites inherit from, ---- forget it.  
> Doesn't
> work.
>
> 3. Now, what happens to our added member properties (the  
> gender-stuff)? If
> Plone loses its acl_users, will the new properties - which are  
> definitely
> Plone-customizations and unknown on the Zope-level - get lost as well?  
> Good
> news again - they don't get lost. Plone basically says, "I know you  
> are a
> member because your name is in Zope's stupid little acl_users, but I  
> know a
> lot more about you because I saved it in my own memberdata_tool".
>
> I hope that was helpful...
> Dhyani
>
>
>
> ----------------------------------------------------------------------- 
> ---
> This message is sent to you because you are subscribed to the mailing  
> list <VasudevaService-K9y3B4ipJAZZAIG4hdpdiNBPR1lH4CV8@public.gmane.org>.
> Vasudeva Service home: http://www.vasudevaservice.com/
> Browse list: nntp://news.gmane.org/gmane.org.misc.vasudeva-server.web
> List archive:  
> https://pop.vasudevaserver.org:13031/Lists/VasudevaService/List.html
> ----------------------------------------------------------------------- 
> ---
>


--------------------------------------------------------------------------
This message is sent to you because you are subscribed to the mailing list <VasudevaService-K9y3B4ipJAZZAIG4hdpdiNBPR1lH4CV8@public.gmane.org>.