[Koha-bugs] [Bug 23710] Holds broken on intranet, displays a JSON page with an error

[bugzilla-daemon at bugs.koha-community.org]

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

--- Comment #21 from Agustín Moyano <agustinmoyano at theke.io> ---
(In reply to Marcel de Rooy from comment #20)
> QA Comment:
> I will pass QA on this patch set since we want to resolve the issue
> introduced by the clubs feature. Need to say that we should also test stuff
> that makes a feature fail in various ways so that a thing like this should
> have been noticed in earlier testing.
> 
> I am happy that we reached a point that we start using the API in code now,
> but I think that the communication about doing so was a bit "poor" (no
> offense). I would have expected more info on the mailing list or so.. Maybe
> it was discussed in the dev meeting, but I missed it ;)
> 
> I have my doubts on the code quality in this particular case though. Which
> is probably a direct result of incorporating the API in old
> templates/scripts. I understand completely the complexity of doing this in a
> minimalistic way..
> 
> [1] The current reserve template on OPAC does not use API calls. The
> intranet template uses a mix of API calls and the old script. Solving bugs
> here will even be harder while holds already is a difficult area.
> 
> [2] The Holds module of the REST API and especially here the add subroutine
> should not contain lots of "business logic" such as e.g. testing
> AllowHoldDateInFuture here. There is really too much code there, and again a
> mix of AddReserve and Koha::Holds. Again I understand that the refactoring
> of C4/Reserves is not complete. Performance issues etc. But in the meantime
> we now also "polluted" our new REST API code?
> 
> Please do not consider this as hard criticism on the REST API, but I am just
> being concerned about the growing complexity of the codebase while we all
> are still working on parallel tracks..

Hi Marcel, first of all, thanks for testing, and don't sorry, no offence taken.

On point [1] I agree completly. OPAC should use the same method as intranet, so
I'll add a bug as soon as I can.

On point [2], I agree that code in API modules should be as simple and clean as
possible, but business logic must be checked on the "API side".. we can not
rely that it will be implemented on the cliente side. Maybe this kind of logic
could be implemented with helpers of mojolicious. What are your thoughts?

Thanks!

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