Add calendar view / export with reservation information

[orenyk]

We've received the following feature request:

I have a question- Is it possible to see a monthly calendar view for the with a graphic representation of who has what out, and for which days? I’m thinking of the view that the Google Calendar has (screen attached). I’m hoping so, as it would make visualizing who has what (and when it is due) at a glance and easy to sort out.

This actually sounds like a great idea, although it might be a bit tricky to implement since we'd likely want to limit the equipment displayed in a given calendar. Also, keeping #1061 in mind, we probably don't want to write our own calendar display software as much as provide a calendar export API that can be accessed using current online standards (e.g. iCalendar format) for any one of our equipment hierarchies and then embed something like a Google Calendar view of that calendar on the various pages. I'd like this to be done in the next sprint and will try to take it on myself.

2015-12-10

While working on this I had an awesome idea - we should also offer time-based calendar views for operations purposes. An example could be either a week-long or month-long calendar with all of the reservations upcoming for that week - it might be a nice way to get a higher level view for inventory prep purposes, for example. Just a thought, and it should be fairly straightforward to implement if I write nice DRY code 😄.

2016-01-04

Checklist:

• Implement controller concern to enable calendar views / export
  • Write tests!! (TDD if possible)
  • Implement HTML view of calendar
  • Implement iCal export of calendar for Google calendar
• Implement hover with equipment item info if present
• Implement color-coding by status or equipment item
• Fix monkey-patches
  • Manual date queries in generate_calendar_reservations methods pending ToS reset checkbox is centered #1266

Things to keep in mind:

1. Make sure this can apply to nested resources

[caseywatts]

++iCal export sounds like a great way to get this feature
We can sidestep view concerns by just exposing the data that way :D

[orenyk]

This should be useful.

[orenyk]

working on this based on the branch from #1329 to use the dependency updates there

EDIT This technically makes this blocked on #1367

[orenyk]

Ok, so I've been reading the Testing Rails book by Thoughtbot (thanks @jeminlee) and so I'm going to try and apply some of the patterns / lessons I've picked up in this feature. I'm also going to try to implement 100% TDD as a learning exercise. I've started setting up feature specs - I'm going to write a bunch of pending cases as a framework and then flesh them out one at a time. We're also going to want request specs for the API route, potentially view specs for the calendar partial, controller specs for the new calendar actions, and probably unit tests for the various models / PORO's that are written to support the iCal format. More to come!

[orenyk]

Ok, got my first test done and am working with routing and controller concerns to reduce code duplication. I also spent a while looking into generating calendar views and it appears as though our best bet is the fullcalendar-rails gem, which is just a repackaging of the FullCalendar jQuery plugin for Rails. Technically it permits drag/drop of events in the calendar but I'm assuming we can disable that since it makes no sense in our use case. At the moment I'm thinking of looking at reservations +/- 6 months from the current day just to limit it somewhat, but I'd welcome feedback as to whether or not that makes sense.

Note that the passing of the current test does not, in any way, mean that the view has been properly set up - I was just spoofing the existence of a "calendar item" through a list, but we'll definitely have to figure out a proper layout with the appropriate UX elements (link back to the equipment, link to download iCal file, link to import to Google Calendar?, etc). We'll also have to figure out where to link to this view and how to authorize it (at the moment I'm thinking just admins and above, but this is also definitely up for discussion).

I just thought of something awesome - we could totally generate time-based calendar views as well, e.g. reservations for today, reservations for the next week, etc, that could be used for inventory prep or general operations purposes and would link directly to the relevant reservations, almost like a dashboard. I think we can make this work pretty easily, especially if most of code is modular - all that changes is which reservations we're displaying in the calendar. I'll add it to the main issue description.

Finally, I removed the blocked tag since I'm not currently blocked from working on it, but this will be blocked if #1367 isn't merged in by the time it goes into review.

[orenyk]

Btw, note the following article about testing Controller Concerns.

[orenyk]

Here's a great article on how to integrate FullCalendar into a Rails app.

[orenyk]

Let's see if we can make some progress here :-)

[orenyk]

Definitely getting somewhere (I've got FullCalendar up and running and it's pulling events from a JSON response to the calendar route, woo hoo!). Unfortunately, feature testing is going to be difficult since FullCalendar is all JS-based, and we currently don't have capybara-webkit set up. Looking into that now.

[orenyk]

Set up JS testing (it's pretty straightforward), but ran into a funny testing bug. I was originally creating 2-day reservations (due date one day after start date) for testing, but since those can overlap a weekend they sometimes result in two cells for a single reservation (so testing for one cell per reservation can fail). That was fun to debug 😄.

Overall, the concern is really nice and modular, it should be trivial to add a /calendar and /calendar.json route to any resource as long as we define the required private methods. I also just confirmed that by default the calendar routes are restricted to admins and superusers based on our default ability.rb. I still have to expand the test suite to include controller specs and feature specs for all relevant resources. I also have to implement the iCal routes so we can potentially import to Google Calendar / other apps. I'm going to get back to #1378 and will return to this afterwards.

[orenyk]

Whoops, the reserved_in_date_range scope I've been using only returns reserved reservations, but not those in the past or checked out. I believe I made a general-purpose date overlap scope in #1266, but we'll have to wait until that's merged into master and we rebase to use them.

[orenyk]

I was going to implement color-coding events by equipment item but in the end I'm not sure how to generate a sufficiently large palette (although assigning colors to items as we iterate through the reservations with a hash would have been pretty cool), so I think we'll just go by status.

[orenyk]

In case anyone was interested to see how it looks so far:

[orenyk]

Trying to do some testing; unfortunately since our concern requires some private methods to be defined we can't test it in an empty controller as advocated in the link above. Instead, I'm going to put together a shared example instead and we'll pull it into each of the controller spec files.

[orenyk]

Started putting this together; it's a bit complicated and I'm trying to figure out how to write code that will work for all the various controllers. Done for tonight!

[orenyk]

Ok, shared example for all controllers is working with a single spec (for now) and kinda nice, if I may say so myself. I rebased onto master to take advantage of the updated scopes from #1288 but it turns out I didn't write a generalized overlap scope (we just have the reserved_in_date_range. I might refactor that into an overlap scope and just add reserved to the end wherever it's currently being used, but we'll see. Back to this later!

[orenyk]

Might have broken rubocop... not sure what's going on but will investigate.

[orenyk]

Ok, when rebasing I (wrongly) deleted Gemfile.lock to resolve the merge conflict instead of checking out the copy from master and re-running bundle install to add the new gems. This updated a whole bunch of dependencies, apparently breaking rubocop. This has now been fixed 😄.

[orenyk]

We've got an optional hover / tooltip (thanks Bootstrap) when a reservation is checked out and I've expanded the controller tests to handle both the JSON and HTML cases. I guess it's time for iCal!

[orenyk]

iCal is working! Tried moving it to a separate class but that broke things (I think since we were trying to hijack the constructor). Just going to change save calendar start and due dates in the session (like the reports) and that should do it!