[Koha-bugs] [Bug 17314] REST API: Add API route to create, list and delete a purchase suggestion

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Sun Sep 18 17:32:01 CEST 2016


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17314

Jiri Kozlovsky <mail at jkozlovsky.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |In Discussion

--- Comment #2 from Jiri Kozlovsky <mail at jkozlovsky.cz> ---
(In reply to Katrin Fischer from comment #1)
> Hi, just read through this and have some notes/questions:
> 
> - collectiontitle: I think it's not clear in the interface what this is to
> be used for, maybe a question we should talk about first and then maybe
> choose a better name?

I don't actually know exactly what does it have to mean, but you can see it as
"Collection title" on the OPAC site for creating a suggestion:
http://koha-opac/cgi-bin/koha/opac-suggestions.pl?op=add

> - copyrightdate: MARC21 uses copyrightdate in the database, UNIMARC
> publicationyear. Both fields appear in biblioitems/biblio and in
> suggestions. Something to tidy up/take into account here?

In OPAC the copyrightdate has maximum 4 characters, so it is the MARC21. The
question is, whether we should allow specifying also the publicationyear?

> - negcap - This is to keep the robots off. My impression is that this would
> always be empty?

That's right, we leave it empty, thus we won't include it to the incoming data
for POST - the controller will take care of that.

> It's possible to make anonymous suggestions - will this be taken into
> account?

Oh, that's the first time I hear about this functionality. Could you provide me
with an example how to submit an anonymous suggestion?

> For DELETE:
> DELETE /suggestions/{borrowernumber}/{suggestion_id}
> Why include the borrowernumber? Would the suggestion_id not be sufficient?

It's because of the privileges check. Imagine some curious user in VuFind, who
changes his suggestion_id in the form and tries to delete suggestion of someone
else - this should prevent it and return 403 Forbidden.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.


More information about the Koha-bugs mailing list