[OGo-Bugs][Bug 1916] Support non-participant role for teams regarding conflict detection

[bugs@opengroupware.org]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1916





------- Additional Comments From awilliam@whitemice.org  2007-09-25 14:36 -------
>From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20061023
SUSE/2.0.0.5-1.1 Firefox/2.0.0.5

Description of problem:
A team participant with a role of non-participant should not produce a conflict
for team or team members.  Use non-participant teams is useful for
informationally posting an event onto the calendar view of a group.

Version-Release number of selected component (if applicable):
TRUNK

How reproducible:
Always

Steps to Reproduce:
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.

Actual Results:  I see a conflict.

Expected Results:  My understanding was that a role of NON-PARTICIPANT
would suppress conflict.


Additional info:

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?

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

------- Additional Comments From awilliam@whitemice.org  2007-09-25 14:37 -------
>From helge -

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


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

> 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 :-)

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.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.