Venue blackout dates

[mhrivnak]

We need the ability to assign blackout dates to a venue. This should probably be a simple model with a venue FK, start datetime and end datetime.

Some care will need to be made to incorporate consideration of these blackout dates into the existing logic that determines if a venue is available, or what venues are available during a specified period.

[jimallman]

I'm guessing blackout dates define a period during which the venue is not available because of some outside activity, like facility maintenance or other scheduled events (versus events scheduled through openassign). Do I understand this correctly?

I gather we're really talking about blackout periods, each defined as a pair of dates, correct?

Can we assign n blackout periods to a venue?

Does each require explanation or description?

What roles / permissions are required to assign, change, and remove blackout dates?

[mhrivnak]

Correct on all counts. A description is a good idea.

For now, let's just give permission to Admin.

[jimallman]

A few detail questions regarding blackout periods:

I'm currently planning to use methods on the VenueManager to add / edit / remove blackout periods for a given venue. In the interest of uniformity, should I instead create a BlackoutPeriodManager for the new model, with standard create/update methods?

I assume the start and end dates for a blackout period are whole days, and not time values (ie, "ending at 2pm EST on Oct 20"). I'm looking for ways to enforce this "coarseness" on the field or its widgets. Suggestions are welcome if there's a standard idiom in Django or PR.

I assume blackout periods will affect calls to these methods:
RoomManager.get_available_rooms( )
VenueManager.get_available_venues( )
What about resource checks?
ResourceManager.get_available_resources( )
I'm guessing that any resources in a blacked-out venue would be actually be available. (The resource manager currently seems to treat resources as "portable" across venues.) Or, does a resource belong to its venue, and therefore be "otherwise occupied" (unavailable) during a blackout period?

I assume we won't offer blacked-out venues when scheduling new sessions. But should we block the creation or assignment of a session in this situation? If so, is there an existing exception class that would be most appropriate here?
OperationNotPermittedException <== This seems most appropriate to me
InvalidUsageException
AttributeNotUpdatedException
ValidationException
InvalidInputException

Similarly, should we block the modification of start / end dates for an existing blackout period, if this would conflict with already-scheduled sessions in this venue? If so, I assume we throw the same exception type as above.

[mhrivnak]

I think there should be a BlackoutPeriodManager.

I'm not sure about the whole days issue. I've queried Ryan, and we'll
see what he says.

We do not need to worry about resources with this.

Let's not block assignment creation if a session ends up scheduled
during a blackout period.

Let's not prevent modification or creation of a blackout period even
if there is a scheduled session that overlaps. At the very least, the
blackout period can prevent additional sessions from being scheduled,
and then the conflicting sessions can be dealt with manually- either
being rescheduled, or leaving them as-is.

On Mon, Jan 16, 2012 at 12:03 AM, Jim Allman
reply@reply.github.com
wrote:

A few detail questions regarding blackout periods:

I'm currently planning to use methods on the VenueManager to add / edit / remove blackout periods for a given venue. In the interest of uniformity, should I instead create a BlackoutPeriodManager for the new model, with standard create/update methods?

I assume the start and end dates for a blackout period are whole days, and not time values (ie, "ending at 2pm EST on Oct 20"). I'm looking for ways to enforce this "coarseness" on the field or its widgets. Suggestions are welcome if there's a standard idiom in Django or PR.

I assume blackout periods will affect calls to these methods:
 RoomManager.get_available_rooms( )
 VenueManager.get_available_venues( )
What about resource checks?
 ResourceManager.get_available_resources( )
I'm guessing that any resources in a blacked-out venue would be actually be available. (The resource manager currently seems to treat resources as "portable" across venues.) Or, does a resource belong to its venue, and therefore be "otherwise occupied" (unavailable) during a blackout period?

I assume we won't offer blacked-out venues when scheduling new sessions. But should we block the creation or assignment of a session in this situation? If so, is there an existing exception class that would be most appropriate here?
 OperationNotPermittedException     <== This seems most appropriate to me
 InvalidUsageException
 AttributeNotUpdatedException
 ValidationException
 InvalidInputException

Similarly, should we block the modification of start / end dates for an existing blackout period, if this would conflict with already-scheduled sessions in this venue? If so, I assume we throw the same exception type as above.

---

Reply to this email directly or view it on GitHub:
#51 (comment)

[rleathers]

It would be beneficial to specify a blackout period with greater granularity than just days. For example, Jan 16 11:30AM to Jan 16 5:15PM. Such a blackout might be due to any number of facility needs which do not need to be known to the system in any greater detail. (we could just use the reservation system, but then we would have other problems like mixing in facilities 'events' with the kinds of events we actually care about) A blackout of a partial day may have the effect of preventing a training event from being assigned on the same day - but it may not. That depends on the event requirements and should not be dictated by a system which fails to represent an accurate picture of blackout reality.

I suggest handling this in a manner similar to how we set up reservations for learning events. Of course, this would also allow a blackout period be used to make entire days or weeks unavailable as you were probably imagining.

Agreed - resources can be handled at a later date.

Michael's comments are spot on. A blackout period should mask the venue such that no NEW events can be scheduled on top of the blackout period. If something is already there the admin will need to deal with it - not the blackout period manager . When assigning a blackout period, it would be appropriate to see what is already scheduled and alert the admin, but not prevent assignment of the blackout.

[mhrivnak]

I'm grabbing this issue for a bit to add a couple of minor features that the UI needs.