Bug 29105 - items responses do not respect effective_itemtype
Summary: items responses do not respect effective_itemtype
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Martin Renvoize
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-24 09:57 UTC by Martin Renvoize
Modified: 2022-02-25 06:33 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 29105: Add effective_itemtype handling for Item API (926 bytes, patch)
2021-09-24 11:19 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 29105: Unit test (1.58 KB, patch)
2021-09-24 14:16 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 29105: Add effective_itemtype handling to items api (1.17 KB, patch)
2021-09-24 14:16 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2021-09-24 09:57:22 UTC
The item objects we return from various items API routes do not respect the effective itype offerings.

Example, itype is mapped directly from the item itype field to item_type.. it should check for effective itemtype and return the result of that.

Similarly notforloan is mapped directly, but can depend on the effective itemtype.

There are possibly others.
Comment 1 Martin Renvoize 2021-09-24 09:58:04 UTC
I'm not sure how to tackle this, I think it will need a to_api or TO_JSON overload or something.?
Comment 2 Martin Renvoize 2021-09-24 11:19:50 UTC
Created attachment 125235 [details] [review]
Bug 29105: Add effective_itemtype handling for Item API
Comment 3 Martin Renvoize 2021-09-24 14:16:48 UTC
Created attachment 125251 [details] [review]
Bug 29105: Unit test
Comment 4 Martin Renvoize 2021-09-24 14:16:51 UTC
Created attachment 125252 [details] [review]
Bug 29105: Add effective_itemtype handling to items api

This patch adds effective_itemtype handling to the items api.

We overload the to_api method to replace the itype column value with
that of the effective itemtype code.

We also add in the notforloan fallback that is apparent in
catalogue/details.tt status templates.
Comment 5 Martin Renvoize 2021-09-24 14:53:46 UTC
So this patch does one direction (i.e. results), but doesn't cater for searches using q_param yet.
Comment 6 Tomás Cohen Arazi 2021-11-08 13:05:48 UTC
When dealing with an 'item' object it is legit to set item_type to null. Returning the effective (calculated if absent on the item) item type might confuse the consumer to think it has an item_type set. I'd prefer we add the option to embed the effective item_type like in:

x-koha-embed: effective_item_type
Comment 7 Martin Renvoize 2021-11-09 09:38:24 UTC
Hmm.. difficult. I can see where you're coming from... but I'd be tempted to not require an embed to enable it's return and rather return it as a standard field.. so itype + effective_itype fields both always present in the result?
Comment 8 Tomás Cohen Arazi 2021-11-09 09:40:57 UTC
(In reply to Martin Renvoize from comment #7)
> Hmm.. difficult. I can see where you're coming from... but I'd be tempted to
> not require an embed to enable it's return and rather return it as a
> standard field.. so itype + effective_itype fields both always present in
> the result?

Yes.
Comment 9 Fridolin Somers 2022-02-25 06:33:05 UTC
+    $self->notforloan( $self->itemtype->notforloan ) unless $self->notforloan;
$self->notforloan may be 0 so we should use defined no ?