[Kolab-devel] Resources and groups

[Bo Thorsen]

On Tuesday 07 September 2004 11:42, Steffen Hansen wrote:
> 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?

So you suggest that if we leave it to manual handling, it should send out 
a tentative accept until someone has answered it? Hmm, I don't see much 
of a point in doing that.

> [1] Suggestions for better names are welcome.

Sounds fine to me. But the "ACT_ALWAYS_REJECT" doesn't seem that helpful 
to me. And it's a fifth option. Wouldn't hurt to make it of course, and 
it's likely easy enough to implement.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20040907/e0edcdbb/attachment.sig>