Description
Jonathan Druart
2014-05-01 12:07:38 UTC
Created attachment 27867 [details] [review] Bug 12168: Spent and ordered budget values are wrong if deep > 2 A really weird (and old) code process the calculation for the spent and ordered sublevel funds. It only takes into account the direct children. So if you have: fund1 (spent=100) parent of fund11 (spent=10) parent of fund111 (spent=1), you get: fund | base-level | total spent fund1 | 100 | 110 fund11 | 10 | 11 fund111 | 1 | 1 which is wrong, it should be fund | base-level | total spent fund1 | 100 | 111 fund11 | 10 | 11 fund111 | 1 | 1 Test plan: - Create 1 budget and 3 funds with the same structure as above. - Create some orders and receive them (not all). - Go on the fund list view and verify the values are correct. Created attachment 27868 [details] [review] Bug 12168: Add unit tests for GetBudgetHierarchySpent GetBudgetHierarchyOrdered Test plan: prove t/db_dependent/Budgets.t Note: This addition may sound overkill but I found this bug developping bug 12164 and I will reuse all of that. Created attachment 27877 [details] [review] Bug 12168: Add unit tests for GetBudgetHierarchySpent GetBudgetHierarchyOrdered Test plan: prove t/db_dependent/Budgets.t Note: This addition may sound overkill but I found this bug developping bug 12164 and I will reuse all of that. I test against master 3.15.00.051. Applying: Bug 12168: Spent and ordered budget values are wrong if deep > 2 Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging C4/Budgets.pm CONFLICT (content): Merge conflict in C4/Budgets.pm Failed to merge in the changes. Patch failed at 0001 Bug 12168: Spent and ordered budget values are wrong if deep > 2 So I pass the patch to "Patch doesn't apply" status. Created attachment 28102 [details] [review] Bug 12168: Spent and ordered budget values are wrong if deep > 2 A really weird (and old) code process the calculation for the spent and ordered sublevel funds. It only takes into account the direct children. So if you have: fund1 (spent=100) parent of fund11 (spent=10) parent of fund111 (spent=1), you get: fund | base-level | total spent fund1 | 100 | 110 fund11 | 10 | 11 fund111 | 1 | 1 which is wrong, it should be fund | base-level | total spent fund1 | 100 | 111 fund11 | 10 | 11 fund111 | 1 | 1 Test plan: - Create 1 budget and 3 funds with the same structure as above. - Create some orders and receive them (not all). - Go on the fund list view and verify the values are correct. Created attachment 28103 [details] [review] Bug 12168: Add unit tests for GetBudgetHierarchySpent GetBudgetHierarchyOrdered Test plan: prove t/db_dependent/Budgets.t Note: This addition may sound overkill but I found this bug developping bug 12164 and I will reuse all of that. I test the patch against master 3.15.00.051. The values are correct as required. So I pass the patch to "Signed Off" status. Created attachment 28289 [details] [review] [PASSED QA] Bug 12168: Spent and ordered budget values are wrong if deep > 2 A really weird (and old) code process the calculation for the spent and ordered sublevel funds. It only takes into account the direct children. So if you have: fund1 (spent=100) parent of fund11 (spent=10) parent of fund111 (spent=1), you get: fund | base-level | total spent fund1 | 100 | 110 fund11 | 10 | 11 fund111 | 1 | 1 which is wrong, it should be fund | base-level | total spent fund1 | 100 | 111 fund11 | 10 | 11 fund111 | 1 | 1 Test plan: - Create 1 budget and 3 funds with the same structure as above. - Create some orders and receive them (not all). - Go on the fund list view and verify the values are correct. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 28290 [details] [review] [PASSED QA] Bug 12168: Add unit tests for GetBudgetHierarchySpent GetBudgetHierarchyOrdered Test plan: prove t/db_dependent/Budgets.t Note: This addition may sound overkill but I found this bug developping bug 12164 and I will reuse all of that. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Pushed to master. Thanks, Jonathan! *** Bug 11714 has been marked as a duplicate of this bug. *** |