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.
I'm not sure how to tackle this, I think it will need a to_api or TO_JSON overload or something.?
Created attachment 125235 [details] [review]
Bug 29105: Add effective_itemtype handling for Item API
Created attachment 125251 [details] [review]
Bug 29105: Unit test
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.
So this patch does one direction (i.e. results), but doesn't cater for searches using q_param yet.
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:
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?
(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?
+ $self->notforloan( $self->itemtype->notforloan ) unless $self->notforloan;
$self->notforloan may be 0 so we should use defined no ?