tkellen
commented
8 years ago Doing so now.
Closed jugglinmike closed 8 years ago
tkellen
commented
8 years ago Doing so now.
tkellen
commented
8 years ago Looks pretty straightforward. Was this issue present with the previous implementation?
jugglinmike
commented
8 years ago All signs point to "yes."
tkellen
commented
8 years ago Super confused how that could be the case--it would have greatly skewed our billable/non-billable counts in Admiralty and we rely on those heavily for knowing when we've completed delivery of an SOW. Thanks for putting this together @jugglinmike!
jugglinmike
commented
8 years ago This bug was only evident when navigating between weeks in the same phase. The general workflow is to verify a single week per review session. In that case, navigation is primarily between that one week across phases.
The unrelated bugs surfaced by the change into daylight savings time caused delays in the review process, and ultmately forced you guys to review multiple weeks at once.
My guess is the atypical workflow, combined with the more prominent presentation of the "billable" attribute, made this bug especially apparent.
tkellen
commented
8 years ago That actually makes perfect sense. That also accounts for the two or three times where things went askew and we were unable to determine the root cause to submit a bug report. Thanks @jugglinmike! Also, I just deployed this.
jugglinmike
commented
8 years ago tkellen
commented
8 years ago aughh! lol
tkellen
commented
8 years ago PS: It hasn't escaped me that I introduced this bug. Sorry!
jugglinmike
commented
8 years ago It escaped me until you pointed it out. Now I am plotting ways I can sneak a back door into the Nest API.
When the underlying utilization changes for a given day, ensure that the "billable" value is updated accordingly.
@tkellen Mind giving this a once-over?
Resolves gh-126