More progress bar issues + coding session.

The progress bar is really turning out to be quite time-consuming, as there always seems to be something that we need to add or change to get it doing what we want. It already has an absolutely insane amount of Javascript backing it, with multiple Ajax calls, to ensure that the progress bar is "smarter" than the user and doesn't allow them to check-in when they shouldn't, or skip check-ins without a penalty, etc.

As I had mentioned a few posts back, I was trying to get an undo function working for check-ins. I had been using paper_trail but was having to manually "roll-back" the check-in count for certain models because, for whatever reason, paper_trail was only rolling back three of the fields when I asked for the previous version of the model. During our coding session this past Sunday, I followed the directions on paper_trail's git page for explicitly telling the gem which model attributes it should roll back, hoping that I could force it to rollback the check-in count. Did it work? No!! So I decided to chuck the whole idea of using paper_trail because forcing the roll-back manually was causing serious inconsistencies that would later manifest themselves it weird bugs. For now, I think I'll try using a modal to ask the user to confirm that they want to check-in, which I thought would be a little simpler to implement...

But no! Here I thought showing a simple confirmation modal (I didn't want to use the default browser alert function) would be simple and it took me nearly two hours just to get it to cooperate. Creating and displaying the modal itself is simple (using the $('#modal-name').modal('show') and $('#modal-name').modal('hide') jQuery calls). However, it became quite complicated when I wanted to connect the modal's "Cancel" and "OK" buttons to jQuery click events. Some examples I found suggested using the <a> (href) tag (or "%a" in HAML) with the buttons. Bad idea. This prevented the "OK" click event from being registered properly when the modal was opened and the OK button was pressed. After nearly an hour of googling, I finally decided to remove the <a> tag and, lo and behold, the click event finally registered. After moving the Javascript code that updates the progress bar to a separate function and then calling that function from the OK click event, the confirmation dialog was finally working. I had to pull the code into another function because it appears that the Bootstrap modals do not block other events from occurring so the update code was being run as soon as the user clicked "Check-in" and the modal appeared. Maybe there is a way to force the modal to block all events until it is dismissed, but I haven't found it.