[Kolab-devel] Resources and groups

[Steffen Hansen]

On Tuesday 07 September 2004 10:50, Martin Konold wrote:
> Am Dienstag, 7. September 2004 10:39 schrieb Bo Thorsen:
>
> Hi Bo,
>
> > development group for example). Both have an account on the server,
> > so you have for example:
> >
> > Account "red car <red.car at somewhere.com>"
> > Account "meeting room <meeting.room at somewhere.com>"
> > Account "kolab development <kolab at somewhere.com>"
> >
> > And the Kolab group has five real persons.
> >
> > You can then invite these to your meetings like anyone else. So the
> > secretary makes a Kolab meeting by inviting
> > meeting.room at somewhere.com and kolab at somewhere.com.
> >
> > The question here is what should happen now. Which options should
> > we have on answering this?
> >
> > For groups, we can use these settings:
> >
> > 1) Free: accept; Busy: decline
> > 2) Free: accept; Busy: leave in INBOX for user handling
> > 3) Always leave in INBOX
> >
> > For resources, you could argue that 1) is the only one that makes
> > sense. But for small companies it might make sense to give the
> > others too. That only requires that some person has read/write
> > access to the account.
> >
> > The only place this should be controlled, is in the web gui. It
> > does not make sense to try and make some protocol for it to be
> > controlled by the clients.
> >
> > So, did I miss some usable option?
>
> Your proposal is already much more extensive compared to other
> offerings. I also agree that the policy shall only be controlled via
> web gui.
>
> 1) is definetly the most important in addition I want to have
> 4) always accept
>
> Rational for 4)
>
> There are use cases where it makes sense to have an "overview" like
> calendar. E.g. everyone meeting with some customer is asked to also
> invite the "customer calendar" in order to centrally track the
> meetings with this customer. Of course the customer may actually be
> many different contact persons....

Ok, so we need another LDAP attribute "automationAction"[1] in 
kolabInetOrgPerson that can hold one of ( 
	"ACT_ALWAYS_ACCEPT", 
	"ACT_ALWAYS_REJECT", 
	"ACT_REJECT_IF_CONFLICTS",
	"ACT_MANUAL_IF_CONFLICTS",
	"ACT_MANUAL"
)

Currently, the resource/group handling script sends a tentative reply if 
groups are configured for ACT_MANUAL_IF_CONFLICTS. Should it stay this 
way or should it rather do nothing if there is a conflict?

[1] Suggestions for better names are welcome.

regards
-- 
Steffen Hansen          |       Klarälvdalens Datakonsult AB
Senior Software Engineer|       http://www.klaralvdalens-datakonsult.se
                        |
                        |       Platform-independent
                        |       software solutions