[Kroupware] Attendee update situations

[Bo Thorsen]

On Monday 03 February 2003 13:50, Guenter Schwann wrote:
> On Monday 03 February 2003 12:39, Bo Thorsen wrote:
> > I'm currently working on attendees updating info on the tasks or
> > events.
> >
> > When the organizer of a task changes something, an update is sent out
> > (method Scheduler::Request, Sequence > 0) and this works fine now.
>
> Works fine _now_? Do you mean there was something wrong?

It was disabled and unimplemented in the kroupware code. If there is=20
somewhere in korganizer where this is also done, you should point me to=20
it. (Yes, I still feel like a newbie korganizer coder :)

> > But what should be done when an attendee of a task sends something
> > out? Currently (just committed to cvs) I send a mail to the organizer
> > with method Scheduler::Reply.
>
> When does a attendee send something other than an answer to the
> organizer, or a "refresh"?

I'm asking what should be sent, when the attendee sets the completed, or=20
something like that. Is it a REFRESH? Or is it a COUNTER? I'm not sure=20
about todos - had it been a meeting, then COUNTER was definately it.

/me should spend more time reading RFCs :-(

> > Two questions: Shouldn't the reply really be with method
> > Scheduler::Request and with Sequence++, or how do I do that? And
> > should this mail also go out to other attendees (not important since
> > the current implementation only allows a single attendee anyway)?
>
> Attendees should never send messages to each other. IMIP alway
> comunicates from/to the organizer.

Ok, then I can worry about updating other attendees later. It's possible=20
to do this by hand anyway.

> > When attendees of a meeting changes something, this will be done
> > locally only, since noone but the organizer are allowed to change a
> > meeting. But shouldn't the user at least be allowed to cancel a
> > participation in a meeting? If so, is this done by sending a Cancel
> > message?
>
> Attendees should send a "decline"-reply. Then the organizer deletes
> this attendee sends a "cancel" back. All other attendees receive an
> updated "request" (without changing their status - it's just an
> update).

Ok, this should work fine (if it wasn't for the fact that we disabled the=20
gui to do it).

Bo.

=2D-=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark