Round progress percentages appropriately#3465
Merged
Merged
Conversation
Reason is that using floor solved rounding up to 100% too soon, but it introduces the issue of rounding down to 0% for too long
3 tasks
Co-authored-by: stacktraceghost <222603941+stacktraceghost@users.noreply.github.com>
Lionqueen94
approved these changes
Jun 25, 2026
stacktraceghost
approved these changes
Jun 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Solves one of the three findings in #3159:
Reason it should be floor is to avoid rounding a percentage >= 99.5% to 100%, suggesting a completed status. However, always using floor also means we round a percentage between 0 and 1 down to 0 in some cases where we shouldn't.
So we introduced a function (hat tip to @stacktraceghost for the conversation and the pair programming)
calculateProgressPercentage()that calculates the percentage and rounds it down, except when it's within a range provided, in which case it rounds up.There are three occurrences where we calculate a progress percentage. The function is used in two of them:
Sidenote on the MultiProgressBar: it accepts values that add up to a total larger than 100. It seems to handle that fine. Because of the data we provide it, the total will at most be slightly larger than 100.
For the third occurrence, calculateDataEntryProgress, which is used for data entry progress of a single entry when a typist submits data entry, I did not introduce the function, since it serves no purpose. It calculates the percentage completed of the pages in data entry. Since it is extremely unlikely we will ever have more than 100 pages, the issue of rounding down to 0 or up to 100 when we shouldn't, will not occur.
Since my initial solution was changing the round to a floor for all three occurrences, I have kept that change for this occurrence in this PR. At least it is consistent with floor being the default way to round in
calculateProgressPercentage().How to test
Tests were updated or added for each of the changes.
Reviewer notes
No notes.