Re: Overlapped Bookings

[Doug Royer <Doug.Royer@xxxxxxxxxxxx>]

As I have heard others say over the last few emails/months:

        TRANSP is the way to go.

Questions:

        1) At the calendar level, should TRANS-NOCONFLICT or TRANS-CONFLICT
           be the only ones allowed?

        2) Should TRANSP: be allowed as a STORE property? As a default?
           overrideable?

David Madeo wrote:
>
> Hi,
>
> I haven't seen any discussion of Overlapped bookings in a while, so I
> read through all the email, collected all the ideas and wrote some
> text.  Hope you find this
> useful.
>
> Thanks, dmadeo
>
> [ PS Bruce mentioned the possibility of removing the component
> property and instead expanding the values for TRANSP.  So instead of
> just having TRANSP:OPAQUE and TRANSP:TRANS, you could have (and I'm
> paraphrasing), TRANSP:TRANS, TRANSP:TRANS-NOCONFLICT, TRANSP:OPAQUE,
> and TRANSP:OPAQUE-NOCONFLICT.  If the calendar property is set to
> CONFLICTS:FALSE, then the two OPAQUE (and TRANS) entries are treated
> identically, but still defined differently.  Since the calendar
> property may be changed back, the component properties do not lose
> their settings.  This makes as much sense to me as a specific
> component entry for CONFLICTS.  Comments welcome]
>
> ----------------------------------------
>
> W-23 CAP Calendar property to allow/disallow                 Y
>      booking overlapped or conflicting OPAQUE entries?
>
> 1.3 definitions
>
> Overlapped Booking
>
> A policy which indicates whether or not OPAQUE events can overlap one
> another.
> When the policy is applied to a calendar it indicates whether or
> not any OPAQUE events in the calendar can overlap. When applied to an
> individual event, it indicates whether or not it can be overlapped by
> any
> other OPAQUE event.
>
> 2.8 extensions to iCalendar (I'm not sure how this is different than
> section 12)
>
> CONFLICTS   A component level property which controls whether overlapped
> booking is allowed with this particular component.  This component
> property can be changed at any time, regardless of the Calendar
> property setting.  Only if the Calendar and the component properties
> are set to CONFLICTS:TRUE, will opaque components be allowed to be
> overlapped.  The default setting is CONFLICTS:TRUE
>
> 6.2 Access Control and CONFLICTS discrepancies
>
> Even if access control allows a CUA to store an event, the CONFLICTS
> Calendar or component setting may prevent it, returning an error code
> "6.3"
>
> 7.2.1.1.1
> Result: 6.3  Conflicts not allowed
>
> 9.1
> (in the VCALENDAR, VEVENT, VTODO, and VJOURNAL sections add the
> following)
>
> CONFLICTS
>
> 12.2
>
> CONFLICTS N Whether overlapped booking is allowed in this
> Calendar. Only if both the Calendar and the component have
> CONFLICTS:TRUE will the CS allow another overlapping OPAQUE component to
> be scheduled.  If the Calendar CONFLICTS property is changed,
> previously scheduled conflicting components are left alone.  Only if
> one of the conflicting components is rescheduled to a new time, will
> the Calendar setting apply.  The default setting is CONFLICTS:TRUE
>
> dmadeo