It is possible to create holds with duplicate priorities. The reason for this is that typically the priority is calculated before placing the hold. When the hold is placed the priority is calculated. This can easily be shown by opening up two browser windows and starting to place a hold for a record in each one. You'll see that both list the same priority. If you than place the hold in each window, both holds will have the same priority!
Created attachment 41996 [details] [review] Bug 14733 - Unit Tests
Created attachment 41997 [details] [review] Bug 14733 - Prevent a record from having holds with duplicate priorities It is possible to create holds with duplicate priorities. The reason for this is that typically the priority is calculated before placing the hold. When the hold is placed the priority is calculated. This can easily be shown by opening up two browser windows and starting to place a hold for a record in each one. You'll see that both list the same priority. If you than place the hold in each window, both holds will have the same priority! Test Plan: 1) Run unit tests pre-patch, note they fail 2) Run unit tests post-patch, note they succeed
Created attachment 41998 [details] Bug 14733 - Tidy AddReserve
This works, but it does have the side effect that in the staff interface where it shows the priority when placing a reserve. It will say Priority 1 for example Then you save it, and now its priority 2 ... I think this will prompt bug reports from Librarians. Do we care about that?
(In reply to Chris Cormack from comment #4) > This works, but it does have the side effect that in the staff interface > where it shows the priority when placing a reserve. > > It will say Priority 1 for example > > Then you save it, and now its priority 2 ... I think this will prompt bug > reports from Librarians. Do we care about that? That thought had occurred to me, but I didn't take any action on it. We could change the "Priority" label to "Estimated priority", or just do away with the field altogether. I'm not sure I see the advantage of having it at all. What do you think?
Created attachment 42658 [details] [review] Bug 14733 - Unit Tests Signed-off-by: Heather Braum <hbraum@nekls.org>
Created attachment 42659 [details] [review] Bug 14733 - Prevent a record from having holds with duplicate priorities It is possible to create holds with duplicate priorities. The reason for this is that typically the priority is calculated before placing the hold. When the hold is placed the priority is calculated. This can easily be shown by opening up two browser windows and starting to place a hold for a record in each one. You'll see that both list the same priority. If you than place the hold in each window, both holds will have the same priority! Test Plan: 1) Run unit tests pre-patch, note they fail 2) Run unit tests post-patch, note they succeed Signed-off-by: Heather Braum <hbraum@nekls.org>
Created attachment 42734 [details] [review] Bug 14733 - Unit Tests Signed-off-by: Heather Braum <hbraum@nekls.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 42735 [details] [review] Bug 14733 - Prevent a record from having holds with duplicate priorities It is possible to create holds with duplicate priorities. The reason for this is that typically the priority is calculated before placing the hold. When the hold is placed the priority is calculated. This can easily be shown by opening up two browser windows and starting to place a hold for a record in each one. You'll see that both list the same priority. If you than place the hold in each window, both holds will have the same priority! Test Plan: 1) Run unit tests pre-patch, note they fail 2) Run unit tests post-patch, note they succeed Signed-off-by: Heather Braum <hbraum@nekls.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 42736 [details] [review] Bug 14733: Replace 'priority' with 'estimated priority' Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 42880 [details] [review] Bug 14733: (QA followup) make tests independent of already defined branches The current tests were expecting the first defined branch to be CPL. That's not the case on my box so they failed. This patch adds the creation of two new random branches/branchcodes, and replaces the legacy use of CPL and MPL in favour of the new ones. It relies on TestBuilder for the task. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Patches pushed to master. Thanks Kyle and Jonathan!
Pushed to 3.18.x, will be in 3.18.12. Noting that I resolved a conflict in the unit tests regarding the number of tests.
Pushed to 3.18.x, is in 3.18.12. Note that I left off the tests for 3.18.