Joshua M. Ferraro a écrit :
Hey gang,
Just a few questions about some of the additions to 3.0 that I
haven't been keeping tabs on. Could someone clarify the following:
OK, i'll try :
1. what is a 'professional' borrower?
A teacher for example : a physical person, that is member of the
library not for a personal use. SANOP will tell you more, but, iirc,
some addresses are differents than for standard Adult super-category.
2. what is a 'department' (in overdues)? Is it a hard-coded authorized
value for item.location? Should it be defined in the framework?
mmm... where is do you see that ? It's something like "county", has
been added by SANOP, but I think it should/must not appear anywhere.
Pls let me know where it is still, i'll see how to remove it (the
hardcoded part)
5. what is the nature of AutomaticItemReturn syspref?
dunno (SANOP ?)
6. ReservesMaxPickUpDelay syspref ... what's it for, is it years,
days, months?
it's days. added by SANOP iirc
7. maxoutstanding, maxreserves, noissuescharge, shouldn't these
be in issuingrules?
They are in systempreferences sinces Koha 1.0 I think. I agree we
should improve reserve behaviour and include reserves rules like
issuing rules.
I don't see what would be improved by "maxoutstanding and
noissuescharges" depending on borrower category / itemtype / branch.
8. useDaysMode - shouldn't this also be in issuingrules?
dunno
9. borrowerRelationship - shouldn't this be configurable in the
borrower categories? maybe a new authorized value?
mmm... you're right about configurable in borrowers category. I'm not
sure it would be good to have an hardcoded authorized value, but maybe.
10. memberofinstitution syspref? - what is the effect of this
syspref?
dunno. (SANOP will know)
11. SubscriptionHistory syspref? what is the effect of this
syspref?
There are 2 subscription histories in OPAC : the "short" and the
"complete" one. This let you choose the default one, nothing more.
12. Would anyone object to me declaring bankruptcy on our sysprefs,
and re-naming all of them for 3.0? It might be a bit inconvenient
for a few libraries currently running Koha that want to upgrade,
but long term I think it would make things a lot simpler ...
If you "just" mean re-naming all of them, i'm 100% with you ! And I
suggest using the same naming conventions as for subs :
SubscriptionHistory and NOT subscriptionhistory.
I planned to ask toins for doing this, but all other code cleaning has
already taken too long.
About migration : it should not be a real problem, if we add some
"update systempreference set systempref="InstitutionMember" where
systempref="memberofinstitution"