[geeklog-devel] GL2 and site relationships
tony at tonybibbs.com
Wed Jan 5 13:54:13 EST 2005
Let me try explaining this another way.
The first relationship would be independent. In 1.3.x there is no way
to do this. If you want two unrelated sites running under the same
database...forget about it. In this the sites are truly separate with
their own users, their own groups, own content.
The second relationship, peer-to-peer, might be a suite of on line
publications. For example purposes, they might all be computing
publications with one specializing in Programming and the other in, say,
Networking and Security. Each would have their own sets of groups,
permissions, etc. However the admins can pick and choose what content
they are willing to share with their affiliate sites. Thus the
Programming site could 'listen' to the LDAP topic on the networking and
security site so that when, for example, a story submission on LDAP was
made the Programming site would get it as well.
The last, and more complicated is the affinity relationship. This
imposes a hierarchy where the parent site admin can control content
downstream. So, for example, take a large company like Honeywell.
Honeywell's HQ would have their own site. Each regional division would
have their own Gl2 site under the Honeywell umbrella. The look and feel
can even be drastically different by the content comes two sources, the
HQ site and any content generated at the regional level.
Not the greatest example but does that make more sense?
Simon Lord wrote:
> Ok, so what's the underlying question Tony is asking if we can
> simulate separate depts under GL2?
> If we can assign a theme to a meta-group then in theory these
> meta-groups would look like independent sites. No?
> On Jan 5, 2005, at 1:10 PM, Vincent Furia wrote:
>> If I understand what your asking, I think between groups and the ACLs
>> under GL2 you'll get this functionality for free (as long we keep in
>> mind people may want to do things this way when we're writing the rest
>> of the code).
>> On Wed, 5 Jan 2005 13:06:36 -0500, Simon Lord <slord at marelina.com>
>>> My current solution to this is to assign each dept as a GROUP. That
>>> way each dept only sees stories/links etc meant for them. It's not
>>> perfect, but it would be if a new *kind* of group object were created
>>> to categorize content into a meta-group. This would allow us to assign
>>> the *meta-group* tag to users who would automatically only be able to
>>> read and post to their meta-group.
>>> Some depts, such as the Documentation dept, would need to have
>>> permissions to search more than just within their own meta-group in
>>> order to gain access to information to author proper documentation. So
>>> a means to allow a user/or group access to more than one meta-group
>>> would be cool.
>>> Is that complex? I think it would work swimingly across sites as well
>>> seeing as how users are tagged with a specific meta-group depending on
>>> where they sign in/sign up and thus only see data pertaining to that
>>> On Jan 5, 2005, at 12:04 PM, Tony Bibbs wrote:
>>>> One thing missing from the current GL2 data model is the ability to
>>>> run multiple sites under one database. These sites may, or may not,
>>>> have a relationship of some sort. This definitely needs to be added.
>>>> I wanted to quickly describe this and how I am proposing to solve
>>>> Organizations, particularly businesses, would want to use a CMS like
>>>> GL2 allowing each entity in their table of organization to have their
>>>> own site. These relationships can be in three different modes:
>>>> 1) Independent. They share the same database but have no relationship
>>>> between them. As such they effectively act as their own independent
>>>> GL2 site
>>>> 2) Peer-to-Peer. You may have two GL2 sites with different but
>>>> related content. This model would allow one site to magically
>>>> 'submit' items that can be included on the other site given that site
>>>> administrator wants it.
>>>> 3) Affinities. This covers the scenario I eluded to where you have a
>>>> number of GL2 sites that are related to one another. There will
>>>> always be a top level 'master' who can create affinities under them
>>>> who can control their own content but are subjected to content changes
>>>> the 'master' feels is appropriate to them.
>>>> My first question is do we still want to support this sort of
>>>> functionality? Doing so would complicate overall administration but
>>>> we could probably hide that complexity if, at installation, we knew
>>>> the admin didn't care to run more than one GL2 site in the single
>>>> geeklog-devel mailing list
>>>> geeklog-devel at lists.geeklog.net
>>> geeklog-devel mailing list
>>> geeklog-devel at lists.geeklog.net
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
More information about the geeklog-devel