Hi! Looks like we need to do something with this issue. 1. Make sitegroup settable with property value set, with condition that it is only safe when object was just created and has not attachments and parameters? Or 2. Implement setsitegroup method which sets all related objects' sitegroup including object itself? Piotras
Hi, On 3/8/06, Piotras <pp <at> infoglob.com> wrote: > 1. Make sitegroup settable with property value set, with condition that > it is only safe when object was just created and has not attachments > and parameters? This should be quite simple, I'm surprised that it isn't so already. Just make $object->create() place the object in the user's sitegroup by default, but allow the default to be overridden by $object->sitegroup if the user is in SG0. There should be no need to have similar functionality in $object->update(). > 2. Implement setsitegroup method which sets all related objects' sitegroup > including object itself? -1 Way too complex in my mind. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - info <at> yukatan.fi Software craftsmanship, JCR consulting, and Java development
"Jukka Zitting" <jukka.zitting@...> wrote: > > 1. Make sitegroup settable with property value set, with condition that > > it is only safe when object was just created and has not attachments > > and parameters? > > This should be quite simple, I'm surprised that it isn't so already. It's in HEAD , and in stable branch since this morning. > There should be no need to have similar functionality in $object->update(). > > > 2. Implement setsitegroup method which sets all related objects' sitegroup > > including object itself? > > -1 Way too complex in my mind. Please , see how sitewizard works. We can forget about setsitegroup method as soon as we can create sitegroup admin group without sitegroup admin. And without sitegroup admin group which by default is created in SG0. We can start testing create method with settable sitegroup right now. And if it's proven to be working good we can forget about setsitegroup. However , many times I am logged in as SG0 admin ( using basic auth) and I create objects and set their sitegroup later. Just because I can not open and close my browser every one minute. ( which of course proves that one admin host per sg is a good thing ) Piotras(Continue reading)
Hi,
On 3/8/06, Piotras <pp <at> infoglob.com> wrote:
> However , many times I am logged in as SG0 admin ( using basic auth)
> and I create objects and set their sitegroup later.
> Just because I can not open and close my browser every one minute.
> ( which of course proves that one admin host per sg is a good thing )
How about if a new object inherited the parent objects sitegroup by
default. That would take care of a lot of problems. Something like
this:
1) If user is in SGn (n > 0), create object in SGn
2) If parent object is in SGx (x >= 0), create object in SGx
3) If sitegroup property is set to SGx (x >= 0), create object in SGx
4) Otherwise create object in SG0
The first rule takes care of all normal usage, the rest would cover
administrative tools like Aegir when using SG0. The order of rules 2
and 3 is debatable, but I think this order is better because its
better in avoiding potential database inconsistencies.
To be really safe we'd add checks to outlaw cross-sitegroup parent and
other links, but that's probably too much to ask. 
BR,
Jukka Zitting
--
(Continue reading)
Jukka Zitting wrote: > > To be really safe we'd add checks to outlaw cross-sitegroup parent and > other links, but that's probably too much to ask.
Hi, On 3/8/06, Eero af Heurlin <eero.afheurlin <at> nemein.com> wrote: > There are cases where SG0 parent for SGx object (mainly in styles) > should be allowed (extend a template style, override just some elements, > without having to copy the style and each element) Good point. That case should be covered by only applying the special rules to SGn (n > 0): 1) If user is in SGn (n > 0), create object in SGn 2) If parent object is in SGn (n > 0), create object in SGn 3) If sitegroup property is set to SGn (n > 0), create object in SGn 4) Otherwise create object in SG0 BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - info <at> yukatan.fi Software craftsmanship, JCR consulting, and Java development
"Jukka Zitting" <jukka.zitting@...> wrote: > Hi, > > On 3/8/06, Piotras <pp@...> wrote: > > However , many times I am logged in as SG0 admin ( using basic auth) > > and I create objects and set their sitegroup later. > > Just because I can not open and close my browser every one minute. > > ( which of course proves that one admin host per sg is a good thing ) > > How about if a new object inherited the parent objects sitegroup by > default. That would take care of a lot of problems. Something like > this: I think that real use cases are: 1. Create new sitegroup with admin group and admin person. And this can be solved with ability to set sitegroup when create method is called. 2. SG0 admin interfaces in hosted environments where SG0 host is required ( for example one ssl certificate per 100 sitegroups ) But the latter can be solved if not basic auth is used, which is done in Aegir for example. And this one resolves mgd_auth_midgard sitegroup delimeter issue. I wrote about my personall example because there is no such possibility to set sitegroup of created object using interface like spider. To sum up , I would like to propose:(Continue reading)
Piotras wrote: > "Jukka Zitting" <jukka.zitting@...> wrote: > >> Hi, >> >> On 3/8/06, Piotras <pp@...> wrote: >>> However , many times I am logged in as SG0 admin ( using basic auth) >>> and I create objects and set their sitegroup later. >>> Just because I can not open and close my browser every one minute. >>> ( which of course proves that one admin host per sg is a good thing ) >> How about if a new object inherited the parent objects sitegroup by >> default. That would take care of a lot of problems. Something like >> this: > > I think that real use cases are: > > 1. Create new sitegroup with admin group and admin person. > And this can be solved with ability to set sitegroup when create method is called. Please add : Also create host (as you have to be sg0 for that), pages and topics for the sitegroup. > To sum up , I would like to propose: > > 1. Sitegroup settable only when create method is called. > 2. Sitegroup not settable when update is called even for SG0 admin. > 3. setsitegroup method should be replaced with object's replication. ?? Please explain that one. > 4. mgd_auth_midgard should have sitegroup name parameter +1(Continue reading)
Tarjei Huse <tarjei@...> wrote: > > I think that real use cases are: > > > > 1. Create new sitegroup with admin group and admin person. > > And this can be solved with ability to set sitegroup when create method is called. > Please add : > Also create host (as you have to be sg0 for that), pages and topics for > the sitegroup. This is generic create method. So you can do this ( as SG0 admin ): $sg = new midgard_sitegroup(); /* it doesn't exist yet , but may be replaced with legacy sg */ $sg->name = "sgname"; $sg->create(); $host = new midgard_host(); $host->name = "my name"; $host->sitegroup = $sg->id; $host->create(); $group = new midgard_group(); $group->name = "sgname administrators"; $group->sitegroup = $sg->id; $group->create(); etc etc > > To sum up , I would like to propose: > >(Continue reading)
Hi, On 3/8/06, Tarjei Huse <tarjei <at> nu.no> wrote: > Piotras wrote: > > 1. Create new sitegroup with admin group and admin person. > > And this can be solved with ability to set sitegroup when create method is called. > Please add : > Also create host (as you have to be sg0 for that), pages and topics for > the sitegroup. The feature should be included in the generic $object->create() method so it applies to all cases. > > 3. setsitegroup method should be replaced with object's replication. > ?? Please explain that one. I still don't see a good use case for moving existing objects from one sitegroup to another. If that is needed, a better approach is to create a copy in the other sitegroup and delete the original object. That will avoid all the hairy database consistency issues. > > 5. Sitegroup delimeters should be dropped, or optionally supported. > Maybe only supported in basic auth? Sounds good, the delimiter parsing code could all be moved to midgard-apache. BR, Jukka Zitting(Continue reading)
Jukka Zitting wrote: > Hi, > > On 3/8/06, Tarjei Huse <tarjei@...> wrote: >> Piotras wrote: >>> 1. Create new sitegroup with admin group and admin person. >>> And this can be solved with ability to set sitegroup when create method is called. >> Please add : >> Also create host (as you have to be sg0 for that), pages and topics for >> the sitegroup. > > The feature should be included in the generic $object->create() method > so it applies to all cases. > >>> 3. setsitegroup method should be replaced with object's replication. >> ?? Please explain that one. > > I still don't see a good use case for moving existing objects from one > sitegroup to another. If that is needed, a better approach is to > create a copy in the other sitegroup and delete the original object. > That will avoid all the hairy database consistency issues. I guess a clone method might be ok. I'm not perfectly happy with that as I can se usecases where you want to do development and then deploy to a client or move functionality from one client and up to sg0 for sharing. Still, it is better to define limits and have something that works than to have no limits and nothing working.(Continue reading)
"Jukka Zitting" <jukka.zitting@...> wrote: > > > 5. Sitegroup delimeters should be dropped, or optionally supported. > > Maybe only supported in basic auth? > > Sounds good, the delimiter parsing code could all be moved to midgard-apache. According to issue reported by Torben. I should have big problem when loggin in to m-p.org when my username would contain '+' character. If we want to support this in basic auth we should dissalow some particular characters in person's usernames. Piotras
Hi, On 3/8/06, Piotras <pp <at> infoglob.com> wrote: > 1. Sitegroup settable only when create method is called. > 2. Sitegroup not settable when update is called even for SG0 admin. > 3. setsitegroup method should be replaced with object's replication. > 4. mgd_auth_midgard should have sitegroup name parameter > 5. Sitegroup delimeters should be dropped, or optionally supported. +1 Sound good. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - info <at> yukatan.fi Software craftsmanship, JCR consulting, and Java development
RSS Feed