[Koha-bugs] [Bug 34784] Add ability to populate empty item call numbers for a record based on the itemcallnumber system preference

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon Jan 15 22:05:32 CET 2024


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

--- Comment #28 from Tomás Cohen Arazi <tomascohen at gmail.com> ---
(In reply to Martin Renvoize from comment #27)
> The endpoints introduced here feel very specific and RPC rather than REST..
> I'm going to review with Tomas and see if we can come up with something a
> little more in keeping with the rest of the REST api's

I agree and have said something similar on private conversations with Kyle.

What I proposed Kyle in that conversation, was that we already have something
similar, and flexible enough so we can use the same pattern everywhere... POST
/jobs.

If we made this particular case process immediately, e.g. POST
/jobs/bach_call_number_update could return a regular job object, with Location
=> /jobs/:job_id, and the usual payload found in the job object would just
carry the needed information to avoid a second API call...

He didn't like it that it is not really a background job. I mention this
conversation in case it triggers some better idea to someone.

I have thought about this a bit more, and I feel like we could do something
like:

POST /biblios/:biblio_id/batch_call_number_update

which will return an object, representing the batch operation results (e.g. the
items that got modified, those that failed if partial success is accepted,
etc). It resembles too much what a 'job' is, hence my hesitation.

We should really find some middle ground and move ahead with this cool feature.
I don't entirely like the pattern, but it would be more RESTful.

My two cents.

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


More information about the Koha-bugs mailing list