Suggestions endpoint RFC

This RFC should be the basis for making the suggestions endpoint follow the guidelines. Bug report has already been filed Bug 17314

Actions and routes

The following table presents the current implementation, and the proposed changes.

Description	Action	Proposed path
List suggestions	GET	/suggestions
Add a suggestion	POST	/suggestions
Get a suggestion	GET	/suggestions/{suggestion_id}
Overwrite a suggestion	PUT	/suggestions/{suggestion_id}
Delete a suggestion	DELETE	/suggestions/{suggestion_id}

suggestion object definition

DB schema	Liliputech	Katrin	tcohen	ashimema
suggestionid	suggestion_id
suggestedby	suggested_by	suggesting_user_id	suggestor_id
suggesteddate	suggestion_date
managedby	managed_by	managing_user_id	manager_id
manageddate	managed_date
accepteddate	accepted_date	accepting_user_id	acceptor_id
rejectedby	rejected_by		rejector_id
rejectiondate	rejected_date
STATUS	status
note	note	notes	notes
author	author
title	title
copyrightdate	copyright_date	publication_year (hide internal inconsistency)
publishercode	publisher_code	publisher (see biblioitems)
date	date_created	creation_date		updated_on
volumedesc	volume_desc	volume
publicationyear	publication_year	publication_year (see above and comment below)
place	publication_place
isbn	isbn
biblionumber	biblio_id
reason	reason	library_reply
patronreason	patron_reason
budgetid	budget_id	fund_id
branchcode	library_id
collectiontitle	collection_title	series
itemtype	item_type
quantity	quantity
currency	currency
price	item_price	list_price
total	total_price

Comments

--Kfischer 01:52, 30 July 2019 (EDT)

• You have suggestion_date but rejected_date as a little inconsistency.
• Instead of date_created, use creation_date? (see holds, items ,and other endpoints for comparison)
• Instead of item_price, maybe we should use just price or 'unit_price'?
• I am not sure about the term collection_title - it appears in the GUI too in some spots too and has caused some confusion in translation. I wonder if this should be series instead, which we use in other places.
• Are we sure copyrightdate and publicationyear are both used in Koha in this table? (I know they are in biblio/biblioitems, but not sure for suggestions)
• publisher_code doesn't really fit what we put in there, I'd prefer publisher (see Bug 11195)

--tcohen 9 January 2020 (EDT)

• publisher_code should be mapped into publisher, see the biblios endpoint.

--Kfischer 17:55, 12 January 2020 (EST) When you look at someting again, new things come up:

• suggested_by, managed_by, rejected_by all will all contain 'patron_ids'. I think it would be good to indicate this in the name somehow by using _id. Maybe: suggestor_id, rejector_id, manager_id OR suggesting_user_id, rejecting_user_id, managing_user_id?
• reason = library_reply? Just an idea, as there is always a bit of confusion between patron_reason and reason.
• Still think we need to resolve publication_year/copyrightdate. I think this comes form the different mappings in UNIMARC/MARC21 - but should we make this inconsistency visible to the outside world? Why not just have publication_year and fill in whatever is mapped in the installation in question.