fix stale review_started_at column #1138
Conversation
|
Yes it will, though im not entirely sure that is a problem... The column is used to set the matching column in the task_review_history table. I can't think of a scenario where updating the column when a new reviewer starts a task is an issue or how the current implementation doesn't have the same problem since the review time will only get longer because it isn't being update after the first review. |
|
@CollinBeczak @jschwarz2030, I'll leave it to ya'll to figure out if this is sufficient or adds a regression. The timing itself is not documented very well, neither PR (the previous and this one) details enough to really "know" what the problem was, and there are also zero tests. |
ljdelight
dismissed
their stale review
Dismissing my review, see my latest comment.
|
The former PR was a preference change on how review time was captured for user review CSV reports. I am ok with the revert. It makes more sense that each review gets its own start time as it populated each review in the history table. |
Issue: Upon a second attempt to review a task, the review session has the first review session’s start time recorded under the field review_started_at. This results in incorrect, resulting high review time being calculated.
Solution: this pr removes the condition that prevent the column from being updated when a review session is started.