Add API routes for getting item availability and holdability. Holdability check requires a target borrower (either user himself or borrowernumber). I'm thinking of following endpoints: GET /api/v1/items/{itemnumber}/availability GET /api/v1/items/{itemnumber}/holdability For myself GET /api/v1/items/{itemnumber}/holdability?borrowernumber=X For X Terms: - availability: Does not require login or permissions. Makes a simple check if item is in a valid state for holdings. In other words, check "notforloan", "onloan", "itemlost", "withdrawn", "damaged". - holdability: Requires login and also catalogue permission if the request is made for another borrowernumber than myself. Item is holdable if it is available and if it satisfies IsAvailableForItemLevelRequest and CanItemBeReserved in C4::Reserves + (also debarments and fines?)
After thinking this issue further and researching other availability definitions that we have in Koha, I think the above definition of availability is confusing and misleading, and routes are not good. Availability is more broad term than what described in the first post, for example item can be available for in-house use but not for checkouts, and by using these routes, this kind of information should also be presented. I'm open to ideas :)
How about returning JSON with all the values possible? Let's say for availability: { in_house: true, checkout: false }
Created attachment 53271 [details] [review] Bug 16826: Add API route for getting item availability GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking item availability. The route does not require login and does not consider patron status, as its purpose is to be fast and efficient in checking general availability of item(s), much like in a typical search. Because of this, this route does not tell us whether item is holdable or available for checkout for a specific patron. Patron-specific availability will be introduced in another patch. For this route, item is NOT available if: - item on loan, - item reserved, - item withdrawn, - item lost, - item restricted, - item or itemtype not for loan Depending on system preference, item may or may not be available: - item damaged (depending on AllowHoldsOnDamagedItems), The returned information is some necessary item information combined with: - available (bool) - availability_description ((array of strings) reasons for possible restrictions to availability, such as ["notforloan"]) - hold_queue_length (int) - expected_available ((string) due date if onloan) Possible values in availability_description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered" Patch adds $item->get_availability() in Koha::Items and introduces a new Koha::Item::Availability class where we can store item-related availability information. Includes REST tests and unit tests for new subroutines in Koha::Item and Koha::Item::Availability. To test: 1. Play around with an item. Place a hold on it, checkout, set it damaged etc. 2. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 3. Check that the availability status is as described in the patch description above. Also make sure reasons for unavailability are in availability_description. 4. Repeat steps 1-3 until you are confident route works as expected. 5. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t
(In reply to Jiří Kozlovský from comment #2) > How about returning JSON with all the values possible? > > Let's say for availability: > { in_house: true, checkout: false } I think this is a good option for showing different types of availabilities. Anyway, to start pushing this feature forward, I wanted to upload a patch containing my current progress. It has the problem that I was thinking about earlier. For example the patch above considers an item with "notforloan" status as unavailable, while it could still be for reading room use. Btw, is this the definition of in-house use? Also, what other cases should we consider? I could modify this patch to better inform the different types of availabilities. Before that, it would be great to have input from others as well :)
Created attachment 53276 [details] [review] Bug 16826: Add API route for getting item availability
How about something like this for general/anonymous availability? GET /availability/items?itemnumber=2225 returns for example: [{ "barcode":"TEST000002", "biblioitemnumber":"629", "biblionumber":"629", "checkout": { "available":false, "description":["notforloan","reserved"], "expected_available":null }, "hold_queue_length":1, "holdingbranch":"CPL", "homebranch":"FFL", "itemcallnumber":"782.42166092", "itemnumber":"2225", "local_use": { "available":false, "description":["reserved"], "expected_available":null }, "location":"some_location", "onsite_checkout": { "available":false, "description":["onsite_checkouts_disabled"], "expected_available":null } }] ((+add hold-availability) In this example local_use = checkout with ignoring notforloan, and onsite_checkout = OnSiteCheckouts syspref ? (local_use ? true:false):false) Anyway, what about when checking availability for a specific patron? Is it better to use the same route or use a completely different route? The reason I consider separation between anonymous availability and logged-in availability is my fear that this endpoint will be super busy, and availability for a specific patron is probably a heavy operation. On the other hand, if I used this route, I think I would just want one route with always giving me the correct availability status (checkout, hold, local_use, onsite_checkout etc) for an item, regardless of me being logged-in or not. Opinions are welcome.
Created attachment 53371 [details] [review] Bug 16826: Add API route for getting item availability GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking anonymous item availability. Patron status is not checked. The returned data is for example: { "checkout": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "hold": { "available": true, "description": [], "expected_available": null }, "local_use": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "onsite_checkout": { "available": false, "description": ["onsite_checkouts_disabled"], "expected_available": null }, "hold_queue_length": 1, + some basic item information on locations, bib/bib(item)numbers etc. } Possible values in availability description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered". (+"onsite_checkouts_disabled" for onsite_checkout) To test: 1. Play around with an item. Place a hold on it, checkout, set it damaged etc. 2. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 3. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 4. Repeat steps 1-3 until you are confident the route works as expected. 5. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t
Created attachment 53672 [details] [review] Bug 16826: Add API route for getting item availability Fixed tests.
Created attachment 53675 [details] [review] Bug 16826: Add API route for getting item availability Updates documentation for Koha::Item::Availability.
Created attachment 53813 [details] [review] Bug 16826: Add API route for getting item availability Reverts some small unintended changes (unneccessary e.g. line breaks)
It works for me so far. Are you going to do any further changes to this bug or you are willing to mark it as Needs Signoff? All tests passed for me, so I could sign this off.
How about returning the due_date of current checkout so that user can create better idea when it'll be available for him? I know you already include "expected_available", which is nice, but when there is also a hold on checkedout item, there is empty value in it. What do you think?
(In reply to Jiří Kozlovský from comment #11) > It works for me so far. Are you going to do any further changes to this bug > or you are willing to mark it as Needs Signoff? I could mark it as Needs Signoff, maybe it will initiate some more interest on this :) (In reply to Jiří Kozlovský from comment #12) > I know you already include "expected_available", which is nice, but when > there is also a hold on checkedout item, there is empty value in it. Thanks Jiří, good catch! Updating the patch to fix this.
Created attachment 53826 [details] [review] Bug 16826: Add API route for getting item availability Fixes missing "expected_available" from checkout-availability if the item has holds.
Created attachment 53827 [details] [review] Bug 16826: Add API route for getting item availability GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking anonymous item availability. Patron status is not checked. The returned data is for example: { "checkout": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "hold": { "available": true, "description": [], "expected_available": null }, "local_use": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "onsite_checkout": { "available": false, "description": ["onsite_checkouts_disabled"], "expected_available": null }, "hold_queue_length": 1, + some basic item information on locations, bib/bib(item)numbers etc. } Possible values in availability description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered". (+"onsite_checkouts_disabled" for onsite_checkout) To test: 1. Play around with an item. Place a hold on it, checkout, set it damaged etc. 2. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 3. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 4. Repeat steps 1-3 until you are confident the route works as expected. 5. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz>
(In reply to Lari Taskula from comment #14) > Created attachment 53826 [details] [review] [review] > Bug 16826: Add API route for getting item availability > > Fixes missing "expected_available" from checkout-availability if the item > has holds. Now it works as expected, nice job!
Created attachment 53922 [details] [review] Bug 16826: [QA Follow-up] Add 'new_status' to Swagger definition Adds missing "new_status" to item's Swagger definition. Also, to avoid forgotten columns in definitions, adds a test to compare item-definition to database's items-table. To test: 1. Run t/db_dependent/api/v1/items.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz>
Comment on attachment 53922 [details] [review] Bug 16826: [QA Follow-up] Add 'new_status' to Swagger definition Sorry about this patch, I've messed up bug id - had to be 16825 instead of 16826.
Created attachment 54053 [details] [review] Bug 16826: Add API route for getting item availability Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz> Fixed small mistakes in documentation and removed itemnumberPathParam from Swagger; it belongs to Bug 16825.
Created attachment 56128 [details] [review] Bug 16826: Add API route for getting item availability GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking anonymous item availability. Patron status is not checked. The returned data is for example: { "checkout": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "hold": { "available": true, "description": [], "expected_available": null }, "local_use": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "onsite_checkout": { "available": false, "description": ["onsite_checkouts_disabled"], "expected_available": null }, "hold_queue_length": 1, + some basic item information on locations, bib/bib(item)numbers etc. } Possible values in availability description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered". (+"onsite_checkouts_disabled" for onsite_checkout) To test: 1. Apply patch and run minifySwagger.pl perl misc/devel/minifySwagger.pl -s api/v1/swagger/swagger.json -d api/v1/swagger 2. Play around with an item. Place a hold on it, checkout, set it damaged etc. 3. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 4. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 5. Repeat steps 1-3 until you are confident the route works as expected. 6. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz>
Rebased on top of master.
Created attachment 56129 [details] [review] Bug 16826: Add API route for getting item availability Fixing typo in test plan. This plan applies: To test: 1. Apply patch and run minifySwagger.pl perl misc/devel/minifySwagger.pl -s api/v1/swagger/swagger.json -d api/v1/swagger 2. Play around with an item. Place a hold on it, checkout, set it damaged etc. 3. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 4. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 5. Repeat steps 2-4 until you are confident the route works as expected. 6. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz>
Created attachment 56130 [details] [review] Bug 16826: Add API route for getting item availability Fixing one more typo in test plan: To test: 1. Apply patch and run minifySwagger.pl perl misc/devel/minifySwagger.pl -s api/v1/swagger/swagger.json -d api/v1/swagger/swagger.min.json 2. Play around with an item. Place a hold on it, checkout, set it damaged etc. 3. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 4. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 5. Repeat steps 2-4 until you are confident the route works as expected. 6. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz>
Created attachment 56295 [details] [review] Bug 16826: Add API route for getting item availability GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking anonymous item availability. Patron status is not checked. The returned data is for example: { "checkout": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "hold": { "available": true, "description": [], "expected_available": null }, "local_use": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "onsite_checkout": { "available": false, "description": ["onsite_checkouts_disabled"], "expected_available": null }, "hold_queue_length": 1, + some basic item information on locations, bib/bib(item)numbers etc. } Possible values in availability description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered". (+"onsite_checkouts_disabled" for onsite_checkout) To test: 1. Apply patch 2. Play around with an item. Place a hold on it, checkout, set it damaged etc. 3. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 4. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 5. Repeat steps 2-4 until you are confident the route works as expected. 6. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz>
Removed minifying step from test plan after Bug 17432 was pushed.
Created attachment 57271 [details] [review] Bug 16826: Add API route for getting item availability GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking anonymous item availability. Patron status is not checked. The returned data is for example: { "checkout": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "hold": { "available": true, "description": [], "expected_available": null }, "local_use": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "onsite_checkout": { "available": false, "description": ["onsite_checkouts_disabled"], "expected_available": null }, "hold_queue_length": 1, + some basic item information on locations, bib/bib(item)numbers etc. } Possible values in availability description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered". (+"onsite_checkouts_disabled" for onsite_checkout) To test: 1. Apply patch 2. Play around with an item. Place a hold on it, checkout, set it damaged etc. 3. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 4. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 5. Repeat steps 2-4 until you are confident the route works as expected. 6. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz>
Created attachment 57321 [details] [review] Bug 16826: Add API route for getting item availability GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking anonymous item availability. Patron status is not checked. The returned data is for example: { "checkout": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "hold": { "available": true, "description": [], "expected_available": null }, "local_use": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "onsite_checkout": { "available": false, "description": ["onsite_checkouts_disabled"], "expected_available": null }, "hold_queue_length": 1, + some basic item information on locations, bib/bib(item)numbers etc. } Possible values in availability description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered". (+"onsite_checkouts_disabled" for onsite_checkout) To test: 1. Apply patch 2. Play around with an item. Place a hold on it, checkout, set it damaged etc. 3. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 4. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 5. Repeat steps 2-4 until you are confident the route works as expected. 6. Run the following tests: - t/Koha/Item/Availability.t - t/db_dependent/Items.t - t/db_dependent/api/v1/availability.t Signed-off-by: Jiri Kozlovsky <mail@jkozlovsky.cz> Fixed a bug in finding existing holds. Added some more tests to cover it.
Created attachment 57369 [details] [review] Bug 16826: Add Koha::Item::Availabilit(y/ies) for item availability This patch adds classes for calculating and storing item availability information. Usage is simple, e.g. holdability; my $item = Koha::Items->find(123); my $holdability = $item->availabilities->hold; if ($holdability->available) { # available for hold! } else { # $holdability->description holds the reason for unavailability } To test: 1. Run t/db_dependent/Koha/Item/Availability.t
Created attachment 57370 [details] [review] Bug 16826: Add REST endpoint for displaying item availabilities GET /availability/items?itemnumber=123 GET /availability/items?itemnumber=123+456+789 GET /availability/items?biblionumber=321 GET /availability/items?biblionumber=321+654+987 This patch adds above routes for checking anonymous item availability. Patron status is not checked. The returned data is for example: { "checkout": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "hold": { "available": true, "description": [], "expected_available": null }, "local_use": { "available": false, "description": ["onloan"], "expected_available": "2016-07-13" }, "onsite_checkout": { "available": false, "description": ["onsite_checkouts_disabled"], "expected_available": null }, "hold_queue_length": 1, + some basic item information on locations, bib/bib(item)numbers etc. } Possible values in availability description are an empty array and any of: "onloan", "reserved", "damaged", "withdrawn", "itemlost", "restricted", "notforloan", "ordered". (+"onsite_checkouts_disabled" for onsite_checkout) To test: 1. Apply patch 2. Play around with an item. Place a hold on it, checkout, set it damaged etc. 3. Make GET requests to /api/v1/availability/items?itemnumber=YYY, where YYY is an existing itemnumber. You can also try with biblionumber=XXX query parameter, where XXX is an existing biblionumber. 4. Check that the availability statuses are correct and that availability description lists the appropriate status for unavailability. 5. Repeat steps 2-4 until you are confident the route works as expected. 6. Run t/db_dependent/api/v1/availability.t
I fixed some bugs that I found during testing, and also thought the old patch should be split into two; first for introducing new classes and the second for API. I hope this makes it a bit more understandable and easier to test. All availability logic was moved from Koha::Item to Koha::Item::Availabilities. I think this way is cleaner and we avoided previously added 170 lines of code from Koha::Item that could (and should) as well be in its own module. I left a simple link into Koha::Item, $item->availabilities that you can easily use for accessing availability data. Another way is to create a new Koha::Item::Availabilities object and passing $item for the constructor. Also I added some useful item data in return JSON. Since these updates changed a lot, I set this Bug back into Needs Signoff status.
Created attachment 57371 [details] [review] Bug 16826: Add REST endpoint for displaying item availabilities
Created attachment 57373 [details] [review] Bug 16826: Add REST endpoint for displaying item availabilities Include missing Swagger spec files.
Created attachment 57382 [details] [review] Bug 16826: Add REST endpoint for displaying item availabilities Include missing Swagger spec files part 2
Checks for circulation rules and patron status will be delivered in follow-ups asap.
Created attachment 58456 [details] [review] Bug 16826: Availability Swagger definitions GET /availability/biblio/hold GET /availability/biblio/search GET /availability/item/checkout GET /availability/item/hold GET /availability/item/search
Created attachment 58457 [details] [review] Bug 16826: Swaggerize Koha::Availability objects Koha::Biblio::Availability->swaggerize Koha::Item::Availability->swaggerize Constructs a HASHref that contains all availability data to be returned in a JSON object. Numifies numbers to be numbers instead of strings. E.g. biblio swaggerize { "biblionumber": 1234, "availability": { "available": true, "notes": { "Patron::SomethingToNote": { "cool": 1 } } }, "item_availabilities": [ { "itemnumber": 5678, "availability": { "available": false, "unavailabilities": { "Item::Withdrawn": {} } } } ] }
Created attachment 58458 [details] [review] Bug 16826: Controllers for availability
I added Bug 17712 as a dependency and attached new patches that use Koha::Availabiltiy to provide more detailed availability answer via REST API. I also marked the old patches obsolete.
Created attachment 60155 [details] [review] Bug 16826: Availability Swagger definitions GET /availability/biblio/hold GET /availability/biblio/search GET /availability/item/checkout GET /availability/item/hold GET /availability/item/search
Created attachment 60156 [details] [review] Bug 16826: Swaggerize Koha::Availability objects Koha::Biblio::Availability->swaggerize Koha::Item::Availability->swaggerize Constructs a HASHref that contains all availability data to be returned in a JSON object. Numifies numbers to be numbers instead of strings. E.g. biblio swaggerize { "biblionumber": 1234, "availability": { "available": true, "notes": { "Patron::SomethingToNote": { "cool": 1 } } }, "item_availabilities": [ { "itemnumber": 5678, "availability": { "available": false, "unavailabilities": { "Item::Withdrawn": {} } } } ] }
Created attachment 60157 [details] [review] Bug 16826: Controllers for availability
Created attachment 60218 [details] [review] Bug 16826: Controllers for availability GET /availability/biblio/hold GET /availability/biblio/search GET /availability/item/checkout GET /availability/item/hold GET /availability/item/search Includes API tests. To test: 1. prove t/db_dependent/api/v1/availability.t 2. Use Swagger-UI or make direct GET requests to specified availability endpoints, and make sure the returned data looks ok.
Created attachment 60219 [details] [review] Bug 16826: Controllers for availability GET /availability/biblio/hold GET /availability/biblio/search GET /availability/item/checkout GET /availability/item/hold GET /availability/item/search Includes API tests. To test: 1. prove t/db_dependent/api/v1/availability.t 2. Use Swagger-UI or make direct GET requests to specified availability endpoints, and make sure the returned data looks ok.
Created attachment 60267 [details] [review] Bug 16826: Availability Swagger definitions GET /availability/biblio/hold GET /availability/biblio/search GET /availability/item/checkout GET /availability/item/hold GET /availability/item/search
Created attachment 60268 [details] [review] Bug 16826: Swaggerize Koha::Availability objects Koha::Biblio::Availability->swaggerize Koha::Item::Availability->swaggerize Constructs a HASHref that contains all availability data to be returned in a JSON object. Numifies numbers to be numbers instead of strings. E.g. biblio swaggerize { "biblionumber": 1234, "availability": { "available": true, "notes": { "Patron::SomethingToNote": { "cool": 1 } } }, "item_availabilities": [ { "itemnumber": 5678, "availability": { "available": false, "unavailabilities": { "Item::Withdrawn": {} } } } ] }
Created attachment 60269 [details] [review] Bug 16826: Controllers for availability GET /availability/biblio/hold GET /availability/biblio/search GET /availability/item/checkout GET /availability/item/hold GET /availability/item/search Includes API tests. To test: 1. prove t/db_dependent/api/v1/availability.t 2. Use Swagger-UI or make direct GET requests to specified availability endpoints, and make sure the returned data looks ok.
Created attachment 62727 [details] [review] Bug 16826: (follow-up, squashable) Remove warnings Squash to Swaggerize Koha::Availability objects
Changing this to Needs Sign-off (I can see no discussion in here) Btw Lari, nice job !
I don't agree with the proposed endpoints layout. I belive we should have /items/{item_id}/availability instead. The ->swaggerize methods aren't needed anymore as Koha::Object(s) implement the TO_JSON method with similar behaviour. This was obviously written before the TO_JSON addition.
(In reply to Tomás Cohen Arazi from comment #49) > I don't agree with the proposed endpoints layout. I belive we should have > /items/{item_id}/availability instead. > > The ->swaggerize methods aren't needed anymore as Koha::Object(s) implement > the TO_JSON method with similar behaviour. This was obviously written before > the TO_JSON addition. Looks like it's Failed QA then ? Also, it would be nice to have more opinions on what the endpoints should be (/availability/object vs /object/availability)
(In reply to Julian Maurice from comment #50) > (In reply to Tomás Cohen Arazi from comment #49) > > I don't agree with the proposed endpoints layout. I belive we should have > > /items/{item_id}/availability instead. > > > > The ->swaggerize methods aren't needed anymore as Koha::Object(s) implement > > the TO_JSON method with similar behaviour. This was obviously written before > > the TO_JSON addition. > > Looks like it's Failed QA then ? Yes. > Also, it would be nice to have more opinions on what the endpoints should be > (/availability/object vs /object/availability) I agree! It really depends on how it is going to be used.
HI Lari, I just wanted to mention bug 21116 - tcohen worked on this as a way of prototyping new endpoints so the structures could be worked out a bit more before adding them to Koha - might be useful here or elsewhere
I'm no longer able to work on this, so I'm setting assignee to default. Feel free to continue this work.
*** Bug 13927 has been marked as a duplicate of this bug. ***
I'd love to revisit this. For now, I'm planning to look at https://github.com/NatLibFi/koha-plugin-rest-di since the folk in Finland have been kind enough to make their work available there!
I took a short cut to add an availability endpoint in bug 23336 but I'd love to see a more thorough treatment done longer term. The availability code needs a cleanup along the lines of what NatLibFi do I believe but I didn't have the sponsorship to go the distance that way. Happy to help though
(In reply to Martin Renvoize from comment #56) > I took a short cut to add an availability endpoint in bug 23336 but I'd love > to see a more thorough treatment done longer term. The availability code > needs a cleanup along the lines of what NatLibFi do I believe but I didn't > have the sponsorship to go the distance that way. I've been wondering a bit if the word "availability" means different things to different people as well. For me, I'm interested in the "Status" message that we see on the OPAC. Is that the same thing needed for the checkout or is it a bit different?
(In reply to David Cook from comment #55) > I'd love to revisit this. > > For now, I'm planning to look at > https://github.com/NatLibFi/koha-plugin-rest-di since the folk in Finland > have been kind enough to make their work available there! I've just been talking to Ere on Zoom. I'm going to use the plugin API for now while I do a demo for a library, and if that goes well, then I'd be interested in working with Ere and anyone else (Tomas? Martin?) who want to help move this into core Koha.
(In reply to David Cook from comment #58) > (In reply to David Cook from comment #55) > > I'd love to revisit this. > > > > For now, I'm planning to look at > > https://github.com/NatLibFi/koha-plugin-rest-di since the folk in Finland > > have been kind enough to make their work available there! > > I've just been talking to Ere on Zoom. I'm going to use the plugin API for > now while I do a demo for a library, and if that goes well, then I'd be > interested in working with Ere and anyone else (Tomas? Martin?) who want to > help move this into core Koha. How did it go?
(In reply to Katrin Fischer from comment #59) > How did it go? I've had a few issues with the plugin, but Ere and I have worked on them. Overall, I don't have anyone actively using the integration I was working on that needed the plugin, so it hasn't advanced since May/June.
We add a 'get_availability' API in bug 23336. It was initially inspired by the work in the aforementioned plugin, however the scope was narrowed.. It would be great to continue that work to clean up the availability calculations and migrate them into Koha:: namespace asap.