object setsitegroup

	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

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/8/06, Piotras <ppinfoglob.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/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.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.

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

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/8/06, Piotras <ppinfoglob.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

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

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. 
> 

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)

/Rambo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


iD8DBQFEDsNvk2FlZlXdE74RA4gIAKCjprOMgOiM2yyZ2rYzT6bDAMF78QCf
b6Fa
bYjOAQLO/4+SMy2E7gDlgeU=
=kZQy
-----END PGP SIGNATURE-----

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> Hi,
> 
> On 3/8/06, Piotras <ppinfoglob.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:

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:

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.

Piotras


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/8/06, Piotras <ppinfoglob.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/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

Hi,

On 3/8/06, Eero af Heurlin <eero.afheurlinnemein.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/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

Piotras wrote:
> "Jukka Zitting" <jukka.zittinggmail.com> wrote:
> 
>> Hi,
>>
>> On 3/8/06, Piotras <ppinfoglob.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:
> 
> 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
> 5. Sitegroup delimeters should be dropped, or
optionally supported.
Maybe only supported in basic auth?

Also, you should remember that this will brake all legacy
admin interfaces.

Tarjei
> Piotras
> 
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
> For additional commands, e-mail: dev-helpmidgard-project.org
> 


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Tarjei Huse <tarjeinu.no> 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:
> > 
> > 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.

Jukka pointed to object's attachments and parameters ( and
even links).
 And when I wrote about setting SG for different objects
while being logged 
in SG0 admin I reminded myself that I couldn't edit some
object's parameters
later. Those were still in SG0. 
Briefly setsitegroup method should do *exactly* the same
what is done during 
replication to keep db structure ( and application's one! )
logic.

> > 5. Sitegroup delimeters should be dropped, or
optionally supported.
> Maybe only supported in basic auth?

The point is that this one is the only one problem 
 
> Also, you should remember that this will brake all
legacy admin interfaces.

Yes, if we want to keep mgd_auth_midgard. But such feature
should be a method
of midgard_account class which should ( probably ) extend
midgard_person ( if this 
one should be defined by schema ). 
So once we implement new auth mechanism we should be safe as
legacy apps 
like spider or Aegir won't be supported after 1.8 and even
won't be included in data package.

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org