[OGo-Users] Conflict Detection (Bug?)

[Adam Tauno Williams]

> > I have user A who is member of team X.
> > I create an appointment with a participant of X and a role of
> > NON-PARTICIPANT.
> > I create an overlapping appointment with a participant of A and a role
> > of REQ-PARTICIPANT.
> > I see a conflict.
> > Is this a bug?  My understanding was that a role of NON-PARTICIPANT
> > would suppress conflict.
> Hm. Possibly. Actually I'm not sure whether groups work with those  
> extended status codes. (you usually flatten groups when you want to  
> use the extended stuff because the 'confirm' stuff only makes sense  
> with individual participants, but of course NON-PARTICIPANT seems  
> reasonable).

Understood,  but it would be very useful to support NON-PARTICIPANT for
teams since it is an easy and efficient way to push an informational
entry onto the calendar view of many/groups-of users.

> > The same is true if I create an appointment with A:NON-PARTICIPANT and
> > another overlapping appointment with A:REQ-PARTICIPANT.  The
> > NON-PARTICIPANT appointment sees a conflict with the REQ-PARTICIPANT
> > appointment but the REQ-PARTICIPANT does not see a conflict with the
> > NON-PARTICIPANT appointment.
> > Shouldn't conflicts always appear from both sides?
> This is a good question :-) For REQ vs OPT vs NON-PART - probably.  
> But for status values, I'm not sure - eg if a value is tentative it  
> might depend which direction you check.

I'm good with not support status values for teams,  really just
interested in the role issue.

> > My understanding of conflicts is from the map:
> > Conflict-Map as implemented in the conflicts command:
> >               CHAIR REQ-PART OPT-PART NON-PART <NULL>
> > NEEDS-ACTION  yes   yes      might    no       yes
> > <NULL>        yes   yes      might    no       yes
> > ACCEPTED      yes   yes      yes      no       yes
> > DECLINED      no    no       no       no       no
> > TENTATIVE     yes   yes      yes      no       yes
> > DELEGATED     no    no       no       no       no
> Puh. This is 3 year old code :-)

So, of course there are no bugs... :)

> The SQL pattern seems to be this one:
>      pattern =
>        @"(%A > %@) AND (%A < %@) "
>        @"AND (%A = 0 OR %A IS NULL) "
>        @"AND (%A = 0 OR %A IS NULL) "
>        @"AND ((%A IN (%@)) AND "
>        // conflict for NEED-INFO CHAIR and REQ-PART events and then  
> for all
>        // ACCEPTED/TENTATIVE events (unless used with a non-part)
>        // args: stat, stat, role, role, role, stat, stat, role
>        // TODO: move to an own qualifier which is static and conjoined?
>        @"(((%A IS NULL OR %A = 'NEEDS-ACTION') AND "
>        @"  (%A = 'CHAIR' OR %A = 'REQ-PARTICIPANT' OR %A IS NULL)) "
>        @" OR "
>        @" ((%A = 'ACCEPTED' OR %A = 'TENTATIVE') AND "
>        @"  (NOT %A = 'NON-PARTICIPANT')))"
>        @")"
>        ;
> And it seems to use directed joins. Not sure, probably a review of  
> all that stuff would make sense.

Ok,  I'll see about taking a look.

On an aside I've found that LSDateAssignmentCommand does a replace when
updating an appointment's participants rather than updating existing
records.  And the source contains the comment -

/*
  New entry changed since old. We remove the old and add the new, not
  sure whether this makes sense. Can't we update the old assignment?
 */

I'm interested in modifying this to perform an actual update of the
standing record when a participant is already assigned.  We have
encountered a couple of instances where updating an appointment can
result in loss of the status (accepted, tenative, etc...) information
for participants because the client does not supply all the
participant's status when doing an update.   It would be much nicer if
the command left data like role & status as-is if the data is not
provided in the update.