With the removal of admin/finesrules.pl and admin/issuingrules.pl,
the functions str_to_base64() and base64_to_str() in C4::Koha
are no longer used.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Patch to remove issuingrules.pl in favor of
using smart-rules.pl to manage loan and fine
rules. Several reasons for this:
* issuingrules.pl's matrix could grow rather large
if the library has a large number of item types
and patron categories
* successfully entering rules via issuingrules.pl
requires placing commas within input fields
* a sparse circulation policy matrix takes the
same amount of screen space as one that uses
rules for a lot of specific patron category/item type
combinations.
* having two administrative interfaces to the same
policy settings could be confusing.
* UI design of smart-rules.pl better lends itself
to adding more policy setting attributes to the
rules matrix.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Removed the separate admin/finesrules.pl script
to set the fines policy matrix: since admin/finesrules.pl
and admin/issuingrules.pl both touch issuingrules.pl, creating
a specific fine rule could silently override a default issuing
rule and prevent items from being checked out.
Circulation policy matrix settings for fines are now
handled in admin/smart-rules.pl
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The C4::Circulation::TooMany() function, which determines
if a patron is at the maximum loan limit, has been
changed to work as follows:
1. Checks the issuing rule that would apply to the
prospective loan to see if a loan limit (maxissueqty)
has been set.
2. Counts the number of loans that the patron has
that would fall under that loan rule.
IMPORTANT: that means that if a specific loan rule
exists for the branch, patron category, and item type
in question, *only* that rule's maxissueqty will be
checked here - it will not go on to check whether
a less specific rule has a lower loan limit.
3. If adding one more loan would bring that count
over the limit, returns a "too many" error.
4. If the loan hasn't exceeded a specific limit, checks
whether a branch/patron category circ rule has
specified a loan limit, regardless of item type.
If the patron has already reached *that* limit, returns
the "too many" error.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
This routine retrieves the branch/patron category circulation
rules for a given branch and patron category. The return
value is a hashref containing the following key:
maxissueqty - maximum number of loans across all item types
This will first check for a specific branch and
category match from branch_borrower_circ_rules.
If no rule is found, it will then check default_branch_circ_rules
(same branch, default category). If no rule is found,
it will then check default_borrower_circ_rules (default
branch, same category), then failing that, default_circ_rules
(default branch, default category).
If no rule has been found in the database, it will default to
the built in rule:
maxissueqty - undef
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
* Added ability to specify total loans allowed at a library
for the default patron category. If set, the default
limit is applied if no rule for the specific library
and patron category is set.
* Added ability to specify default total loans allowed
for the default library; this is applied if no rule
for the specify library is set.
* Form now indicates if the number of current checkouts
allowed is unlimited.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The alternate issuing rules editor can now allow
defining the maximum number of loans that a borrower
of a given category can take out per branch, regardless
of item type.
The form for entering this limit now appears below
the form for setting loan rules per patron category
and item type. The form only appears if a specific
branch is chosen, not if the default branch is used.
Also, some terminology changes:
* "Amount Loanable" => "Current Checkouts Allowed"
* "Amount" => "Fine Amount"
* "Grace Period" => "Fine Grace Period"
* "Charging Interval" => "Fine Charging Interval"
* "Loan time" => "Loan Period"
Documentation change: new screenshots for the alternate
loan rules form.
squashme terminology
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Extended help on the alternate circulation rules
form to list the order of issuingrules lookup as
follows:
same library, same patron type, same item type</li>
same library, same patron type, default item type</li>
same library, default patron type, same item type</li>
same library, default patron type, default item type</li>
default library, same patron type, same item type</li>
default library, same patron type, default item type</li>
default library, default patron type, same item type</li>
default library, default patron type, default item type</li>
This includes modifying two routines in C4::Circulation to
follow this order: GetLoanLength() and GetIssuingRule().
The reason for this change is to have Koha exhaust all issuingrules
possibilities for a branch before checking the rules for
the default branch - this is consistent with what an admin
might expect from looking at the issuingrules forms, which display
settings a branch at a time, and is more consistent with how
circulation rules should work for indepdendent branches.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Issuing rules are now explicitly sorted by patron category,
then item type. The default patron category sorts last; within
a list of item types for a given patron category, the default
item type sorts last. This follows the order in which
the issuing rules are applied.
Since the primary sort is patron category, also moved that
to be the first column in the issuing rules table.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Improvements to smart-rules.pl to allow it to
replace issuingrules.pl.
* standardized "borrower type" to "patron category"
* made default item type and patron category ('Any')
translatable
* regularized construction of parameters for rule
deletion operatrion
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The first new table is branch_borrower_circ_rules.
This table is used to store circulation rule attributes
that apply to a combination of patron category and branch
across all item types. The one attribute defined is
maxissueqty, which sets the maximum number of loans
that a patron of a given category can take out at a given
branch.
Note that branch_borrower_circ_rules is for attributes
that apply across all item types. This means that
issuingrules.maxissueqty has a different meaning: it is
the maximum number of loans per branch, category, and item type;
if issuingrules.itemtype is '*', that is a *default*
circulation rule used if no more specific rule is found.
The new table will allow the implementation of total
loan limit across item types without making the wildcard
'*' in issuingrules ambiguous. Specifically, if branchcode,
categorycode, or itemtype is issuingrules is '*', that will now
always mean a loan rule to be applied if a more specific rule cannot be found.
Setting issuingrules.itemtype to '*' will no longer mean
to set a total limit across item types for maxissueqty.
The remaining new tables are used to store default
rules for the default branch, the default patron category,
or both:
default_branch_circ_rules - for a given branch, specify
the rule to apply if no more specific rule on
branch and patron category is found (i.e. patron category is default)
default_borrower_circ_rules - for a given patron category,
specify the rule to apply if no more specific rule
on branch patron category is found (i.e., branch is default)
default_circ_rules - global default if no more specify rule
on patron category and branch is available. Note that this
table is constructed so that it can have at most
one row.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The basic problem is that the SIP logic doesn't know where the
input is coming from. It might be a RAW socket, and it might
be telnet. If it is telnet, although the specs declare a
character set (from MS, unfortunately), they do not specify a telnet
implementation. So you might get telnet handshaking or
renegotiations in the middle of an otherwise peaceful session and
these should not be taken as SIP commands. Patches include a move
towards using $CRLF from Socket to avoid problems w/ foreign platform
mapping \n and \r to \015 or \012.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
When edting only a part of the patron record (e.g.,
the library use section or the alternate address), the
zipcode and city were cleared due to an error in
form processing. Now the city and zipcode are set
only of those fields are actually in the submitted form.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The template for the guarantor search implies that
the zipcode is one of the values to be copied from
guarantor to guarantee. Fixed so that the transfer
can actually take place.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Added an ID attribute so that the JavaScript
for the 'delete guarantor' button could
clear the guarantorid field.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Prior to this patch, rebuild_zebra.pl -z was effectively
hanging on to a lock on the zebraqueue table, preventing
other scripts from inserting new entries into the table.
This had the effect of causing circulation operations
to time out.
Refactored by having rebuld_zebra.pl pull the active
queue into memory, then mark entries done by zebraqueue.id.
Consequently, rebuild_zebra.pl should no longer
block adding new entries into zebraqueue.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Created a new script, sync_items_to_marc_bib.pl,
to replace the item tags embedded in the MARC bib
records with fresh versions taken from the items table.
This script should be run as follows:
maintenance/sync_items_to_marc_bib.pl --run-update
Assuming that you're using Zebra, rebuild_zebra.pl -b -z
or rebuild_zebra.pl -b -r should be run after running
this script.
This script should be run if you have used
link_bibs_to_authorities.pl prior to the first
patch for bug 2258. It can also be used if there
is any reason to suspect that the embedded item tags
do not reflect the items table.
With this script I am creating a maintenance/ subdirectory of
misc/ to hold scripts that are meant to fix problems
in the database but are not (or should not be, anyway) necessary
for regular use.
Documentation: add to documentation for server side scripts
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
This patch modifies 13 HTML templates and includes that have lines in them longer than 998 characters. Lines this long are known to break git.
I believe that none of these change behaviour at all, but I'm concerned about one of them. It adds whitespace (carraige returns) inside a <title> tag. I'm not certain that all browsers will deal with this OK.
No documentation changes necessary here.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
If a MARC bib is modified by this batch job,
do not duplicate the item tags embedded in
it (e.g., 952 for MARC21). When modifying
a bib record, any embedded item tags must
be removed before calling ModBiblio - perhaps
this should be moved to ModBiblio itself.
Also removed an error in the job's help text.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The issue was that the index for itemtype is different depending
on whether you're using item-level or bib-level itemtypes. This
patch detects the system choice and sets the index properly
For documentation, please indicate that as part of profiling,
staff can refer to the AdvancedSearchTypes system preference to
choose where to draw the advanced search 'Types' from. Currently
this is implemented as a choice, between itemtypes and ccodes,
but it's been designed to work with any authorised value so long
as an index exists for searching by that authorised value.
By default, and if this syspref doesn't exist, it will pull from
itemtypes as before.
C4::Reserves::_Findgroupreserves(), instead of
getting all requests for a bib, now gets only the
requests that are title-level (itemnumber is null)
or for that specific item. This prevents an item
from filling an item-level hold for a different item
attached to the same bib, which is the expected
behavior for item-level holds.
[LL Bug 22]
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
