Bug 41456 highlighted a few inconsistencies in the item_type field naming in the API's. I spotted that boh transfer_limit endpoints are using item_type string/null where I believe it should be item_type_id string/null.. it's should only be item_type if it's an object/null.
Created attachment 190922 [details] [review] Bug 41530: Rename item_type => item_type_id in transfer_limits API spec Following the API consistency work in bug 41456, this patch renames the item_type field to item_type_id in the transfer_limits API endpoints and definitions. The field should only be named item_type when it contains an embedded object (type: object/null). When it contains a foreign key ID (type: string/null), it should be named item_type_id for consistency. Changes: - Updated api/v1/swagger/definitions/transfer_limit.yaml - Updated api/v1/swagger/paths/transfer_limits.yaml (including documentation) - Updated Koha::Item::Transfer::Limit->to_api_mapping - Updated Koha::REST::V1::TransferLimits error messages - Updated t/db_dependent/api/v1/transfer_limits.t - Updated koha-tmpl/intranet-tmpl/prog/en/modules/admin/transfer_limits.tt Test plan: 1. Run API tests: prove t/db_dependent/api/v1/transfer_limits.t 2. Visit /cgi-bin/koha/admin/transfer_limits.pl 3. Select an item type from the dropdown 4. Check/uncheck transfer limits - verify they work correctly 5. Confirm the API requests use item_type_id field
Created attachment 190923 [details] [review] Bug 41530: Rename item_type => item_type_id in suggestions API spec Following the API consistency work in bug 41456, this patch renames the item_type field to item_type_id in the suggestions API definition. The field should only be named item_type when it contains an embedded object (type: object/null). When it contains a foreign key ID (type: string/null), it should be named item_type_id for consistency. Changes: - Updated api/v1/swagger/definitions/suggestion.yaml - Updated Koha::Suggestion->to_api_mapping Test plan: 1. Run API tests: prove t/db_dependent/api/v1/suggestions.t 2. Verify suggestions API continues to work correctly 3. Check that item_type_id field is properly mapped in API responses
Created attachment 190924 [details] [review] Bug 41530: Rename item_type => item_type_id in clubs holds API spec Following the API consistency work in bug 41456, this patch renames the item_type field to item_type_id in the clubs holds API endpoint. The field should only be named item_type when it contains an embedded object (type: object/null). When it contains a foreign key ID (type: string/null), it should be named item_type_id for consistency. Changes: - Updated api/v1/swagger/paths/clubs.yaml - Updated Koha::REST::V1::Clubs::Holds to use item_type_id Test plan: 1. Run API tests: prove t/db_dependent/api/v1/clubs_holds.t 2. Verify club holds continue to work correctly 3. Check that item_type_id field is properly mapped in API requests
I think this needs to be adjusted: suggestion/suggestion.tt 1366 if(row.item_type && row._strings.item_type.str) node += '; <span class="suggestion_itype"><em>%s</em></span>'.format(row._strings.item_type.str); maybe this one (to confirm): reserve/request.tt 1677 data.item_type = $('input[name="itemtype"]').val()||null;