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

[dcook at prosentient.com.au]

Hey Lari,

I had never even heard of on-site checkouts before reading your email. 

My vote is whatever makes things simplest for librarians. The current circulation and fines rules system is so complex that I have yet to meet a librarian who understands it intuitively.

That said, I feel like Owen Leonard might be re-engineering that system currently? So he might be the best person to talk to.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Lari Taskula
Sent: Wednesday, 1 April 2020 5:25 PM
To: Koha Devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] On-site checkouts and circulation types proposal

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200401/9050ea02/attachment-0001.sig>