| Summary: | Stock Rotation duration test | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Lisette Scheer <lisettepalouse+koha> |
| Component: | Tools | Assignee: | Martin Renvoize (ashimema) <martin.renvoize> |
| Status: | CLOSED WORKSFORME | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | george, lisettepalouse+koha, martin.renvoize |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | 11897 | ||
| Bug Blocks: | |||
It does appear to have reset when it arrived back at home branch. Placed an item in a rota 4/17/2019 (Duration 20 days) Arrived at new home 4/18/2019 (Day 0) Hold found and sent to another branch 4/24/2019 (Day 6) Hold filled, checked out, returned to home branch 4/26/2019 (Day 8/Day 0) 5/8/2019 should have been Day 20. As of 5/9/2019 it has not moved forward. I will check again on 5/17/2019 to make sure it moves on. Lisette Thanks Lisette, that's really helpful to know. What would you expect the correction functionality to be here I'm wondering? Martin, After this I went and looked at the code and it looks like it needs to be on the shelf for 20 days at the branch (in a row I think) for it to move on when the cronjob runs. What we were hoping for with the stock rotation was more like this: June 1, Rota moves from MOS to BOV set to be there for 120 days. September 29, Rota moves from BOV to DEA set to be there for 120 days. Doesn't care if it was checked out during that time, on the shelf, in transit or anything. Lisette https://github.com/Koha-Community/Koha/blob/master/Koha/StockRotationItem.pm#L117-L140 is the code in question. It certainly reads to me as though it should work as you expect (note the filtering of branchtransfers by the appearance of 'StockrotationAdvance' in the comments field). I'll try to come up with an automated test we can add for the unit tests to prove this. Martin, I tested again and it is working now. I had not had the cron-job set up correctly so it didn't run the first time. Now it is working as expected. (In reply to Lisette Scheer from comment #5) > Martin, > > I tested again and it is working now. > I had not had the cron-job set up correctly so it didn't run the first time. > Now it is working as expected. Can the bug be closed? |
It looks like this uses the branchtransfers column datearrived to check for duration. Does that mean if an item goes on hold to another branch and then is returned, the duration for that item is reset to be the the full duration again? >>Comment # 371 on bug 11897 from Martin Renvoize >>Must admit, my recollection of this code is somewhat vague... But, I believe >>the combination of home branch with the date fields prevents that particular >>issue. However, it would be nice to have a test to prove that hypothesis.. >>might be worth opening another bug for that? Per Martin's comment above, can we test to see if an item goes on hold to another branch and then is returned does the duration get reset based on the last date that item arrived at its home branch. Lisette