[Koha-devel] On-site checkouts and circulation types proposal

[Jonathan Druart]

Hi Lari,

I think it would be interesting to get opinions from the general
mailing list. What are the different use cases? Which rules are
suitable for such separation?
Theoretically, all. But in practice?

Your idea is good I think, and certainly a great way to answer the need.

Few things:
You will not double the size of the table horizontally, but maybe
vertically. Instead of 1 row you will end up with 2.
To prevent it to be doubled, the "type" will need to be "normal",
"onsite", or "both" if current maxissueqty == maxonsiteissueqty

Keep in mind the syspref ConsiderOnSiteCheckoutsAsNormalCheckouts.

Cheers,
Jonathan

Le mer. 1 avr. 2020 à 08:24, Lari Taskula <lari.taskula at hypernova.fi> a écrit :
>
> Hi fellow Koha devs,
>
> I'm working on Bug 24101
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24101 in which
> our client wants the ability to separately define circulation rules for
> normal and on-site checkouts. They need the ability to renew on-site
> checkouts, define due date calculation parameters and additionally
> specify separate fine rules (not mentioned in bz ticket yet).
>
> I wanted to ask for your thoughts on this.
>
> Initially I was thinking of duplicating the rules of normal circulation
> the way maxissueqty and maxonsiteissueqty is currently done, but in the
> end this would lead to duplicating almost all of the circulation rules.
> That would not be very convenient and it seems like a short-sighted way
> of solving this problem because it leaves no room for . Who wants to see
> the circulation rule table doubling in width? Not me.
>
> Another, more elegant approach would be to define a new circulation rule
> scope "circulationtype" that defines whether a rule applies to normal or
> on-site checkout (or any other type of checkout someone may come up with
> in the future). Now that we are able to explicitly define a scope that a
> specific circulation rule follows, this would make sense. No need for
> ugly duplication and we can get rid of maxonsiteissueqty too.
>
> Anyways, before I start implementing such a change I wanted to ask for
> support from the community, or better yet even cooler ideas. Perhaps
> there is something about Koha that I have missed that could already
> solve their problem.
>
> Thanks for your time.
>
> --
> Lari Taskula
> CEO, Hypernova Oy
> +358449857337
> Kauppakatu 25 C 409
> 80100 Joensuu, Finland
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/