[Koha-bugs] [Bug 25037] Add support for multiple checkout types

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

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

--- Comment #40 from Lari Taskula <lari.taskula at hypernova.fi> ---
(In reply to Katrin Fischer from comment #39)
> Hi Lari,
> 
> I really like the idea of circulation types - I think I actually suggested
> something like that when on-site was introduced at the time, because I know
> other systems use this concept.
Just curious, which systems and how does it work in them?

> I have 2 comments for discussion/consideration.
> 
> 1) "This commit adds an authorised value category "CHECKOUT_TYPE" and
> an authorised value "OS" (on-site) and "C" (normal checkout)."
> 
> I feel this is not necessary and would vote for hard-coding the circulation
> types and their descriptions. It will make it translatable and keep people
> from 'messing' with it. Unless you plan to really allow people to add a lot
> more of those?
The default values are both hardcoded and exist as authorised value. While we
are at it, my idea was to add database support for dynamicity. Although, fully
supporting such feature would require more changes in the GUI and circulation
logic which I do not plan to implement.

What comes to messing with the values - we can set a RESTRICT flag into the
foreign key which means one cannot change nor delete the authorised values,
unless the whole issues and old_issues table is empty. This way a librarian
cannot accidentally mess up a production system (unless they really did not had
any checkouts (active or returned) yet).

But we can proceed with only hardcoding the values. We can move the authorised
value patches to another Bug for someone else to continue from there. In order
to protect issues.checkout_type from non-existing types, we could use an ENUM
data type that only allows a value from a set of possible hardcoded values.

I will do that now so we can get this Bug moving easier. We can then later
choose whether to include auth value functionality or not.

> I'd also use more speakign abbreviations, maybe 'ONSITE' and
> CHECKOUT - no need to make things more cryptical than necessary. It would
> help doing reports etc. too.
I don't have any preference on the code choices. We can make it more readable.

> 2) On the mailing list it was suggested to have 'normal' 'on-site' and
> 'all'. I am not sure about the 'all'. I feel it might be complicating things
> more than necessary. If all was to preserve current behaviour, I don't think
> that would work as on-site currently is 1 day by default, independent of the
> normal loan period.
The circulation rules part of this Bug was moved to Bug 25089. "All" is useful
if you only need to separate one or two rules between the types of checkouts.
As an example, you could then have one full set of rules with "All" scope, and
loan period = 1, renewals allowed = 0 with "on-site" scope.

Thx for your input!

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