This followup fixes the wthdrawn typo exist in updatedatabase.pl and
does not display the lostitem date if the lostitem value is not set (!=
"").
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Add date fields to track when an item was marked as lost or withdrawn.
Display those fields on catalogue/moredetail.pl
Test Plan:
1) Apply patch
2) Run updatedatabase.pl
3) Pick a record with items, browse to the 'items' tab ( moredetail.pl )
4) Mark an item as lost, verify the field "Lost on:" displays below
the "Lost status" field with todays date.
5) Mark the item as not lost, verify the field no longer displays
6) Repeat steps 4 and 5 with the Withdrawn field.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Basketgroup.tt is very hard to read. This patch simply reindents it.
No visible changes expected
Regression test :
- check the list of opened and closed basketgroups for a vendor is
displayed properly
- check an individual basketgroup (closed and opened) is displayed
properly
- check you can edit a basketgroup and save changes
- check you can print and export a basketgroup
- check you can close and reopen a basketgroup
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch make possible to view an individual closed basket group
without reopening it.
- It adds a new "View" button on closed basket group list
- It creates a view for closed basket groups, with 3 buttons (reopen,
print, export)
- It adds a "delete" button on standard "edit" view (for open
basket groups)
To test :
1/ regression test :
- create some empty basket groups
- create some basket groups by closing baskets
- in the list of basket groups closed and opened, check you can use
the buttons that existed before the patch (close and print, delete,
export, print, reopen)
- click on "Edit" to edit a opened basket group : check everything is
like before :
-- change the billing and delivery places,
-- add a note,
-- put some new baskets in the bg,
-- remove baskets from it
-- save it without checking "close" box => it should be saved but kept
open
-- edit it again, and make other some changes (define a freetext
delivery place for example)
-- save it with checking "close" => it should be saved but closed
2/ new feature test
- click on "view" button on top right column of some closed basket group
- check all the displayed informations are correct (places, free place,
note, list of baskets)
- check you can not change anything
- click on "print" button => check a pdf is created
- click on "export" button => check a csv is created
- click on "reopen" button => you should stay on the same basket group, but
it is now open and you can make some changes
- go back to the basket group list of the vendor. Check the reopened bg
is in "open" tab
- click on "edit"
- click on new "delete" button => the bg should be deleted, and you are
redirected to the bg list of the vendor.
Signed-off-by: cedric.vita@dracenie.com <cedric.vita@dracenie.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, t and xt. Works as advertised.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Under certain circumstance, a search term without quotation marks
returns the expected results while the same search with a
double quote embedded in it would fail.
Koha should ignore the quotation marks and return results anyway.
This appears when QueryWeightFields syspref is activated (and
QueryAutoTruncate is off), as field weighting builds a complex CCL
query using double quotes around search words. This patch simply
replaces double quotes in search words by a space.
Test plan :
- Set QueryAutoTruncate off (you may also need to set QueryFuzzy to off)
- Set QueryWeightFields off
- Perform a serch on two words where you have results, like : centre "ville
=> you get results
- Set QueryWeightFields on
- Perform same serch
=> you get the same results
Signed-off-by: Leila <koha.aixmarseille@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Under certain circumstances, namely where QueryParser is off,
QueryWeightFields is on, and QueryFuzzy and QueryAutoTruncate are
off, a search with a double-quote embedded in it can fail: for
example
web application
would return results where
web "application
does not.
This patch adds an automated regression test.
To test:
[1] Apply this patch and run prove -v t/db_dependent/Search.t;
two tests should fail.
[2] After applying the main patch that fixes the bug, the
prove -v t/db_dependent/Search.t should succeed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The borrowers search is by default on columns surname, firstname,
othernames and cardnumber.
(See C4::Members::_express_member_find).
Adding DB indexes will really increase the query speed.
This patch adds DB indexes on surname, firstname, othernames (cardnumber
has already an index).
Those indexes must be defined with a size because columns are mediumtext.
Test plan :
Test with mysql client :
mysql> explain select * from borrowers where surname like 'A%';
+----+-------------+-----------+-------+---------------+-------------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+-------+---------------+-------------+---------+------+------+-------------+
| 1 | SIMPLE | borrowers | range | surname_idx | surname_idx | 767 | NULL | 395 | Using where |
+----+-------------+-----------+-------+---------------+-------------+---------+------+------+-------------+
=> key show the index is used
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, changes from updatedatabase and in kohastructure match.
I think deletedborrowers can be left out, as it's not queried when doing
patron searches. Patron deletes still work as expected.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch modifies LangInstaller.pm to enable separation
of translation for Staff UI and Staff Help files.
It's a move that make sense, Help strings accounts for
44% of total word count for Staff, and as stated on
Comment #1, it could enable a different workflow on
translation work.
It's more a hack than an elegant solution, but it works.
Feel free to suggest another approach.
To test:
We need to test complete functionality, i.e. create and update
translation files and install translation, and verify that no
string is missing.
1) Before applying the patch, we need some data from staff file.
Pick your language, say de_DE, and
cd misc/translator/
perl translate update de-DE
msginit -i po/de-DE-i-staff-t-prog-v-3006000.po -o de-old.po --no-translator --no-wrap --locale=de_DE
egrep ^msgid de-old.po | sort | tee s-old | wc -l > number-old
We have the file s-old with all strings, and the number of strings on number-old
2) Apply the patch
3) New help file is called de-DE-staff-help.po, so create one
cp'ing old staff on new help
cp po/de-DE-i-staff-t-prog-v-3006000.po po/de-DE-staff-help.po
4) Make a new update, and analize
perl translate update de-DE
msginit -i po/de-DE-i-staff-t-prog-v-3006000.po -o de-new.po --no-translator --no-wrap --locale=de_DE
msginit -i po/de-DE-staff-help.po -o de-help.po --no-translator --no-wrap --locale=de_DE
egrep ^msgid de-new.po | sort | tee s-new | wc -l > number-new
egrep ^msgid de-help.po | sort | tee s-help | wc -l > number-help
cat s-new s-help | sort | uniq | tee s-all | wc -l > number-all
cat s-new s-help | sort | uniq -d | tee s-dup | wc -l > number-dup
Ideally what we need to found is:
diff s-old s-all = zero lines (old strings vs new strings)
In my test I got one line, but it's a false positive (the string "• " is present on new staff)
On numbers,
number-old - number-new - nummber-help + number-dup = 0
or
number-old - number-all = 0
(in my test again I have 1 as result, same string. Also there are 137
repeated lines between new staff and help)
All this tells me that all string to translate are preserved
5) Install translation
perl translate install de-DE
Enable language on staff, and check that help files are translated
6) Finally, create translation files
rm po/de-DE-*
perl translate create de-DE
verify that all files are created. Tests of 4) can be repeated.
7) Verify that no strings from help are present on staff UI file
egrep help po/de-DE-i-staff-t-prog-v-3006000.po
Only results came from help-top and bottom, and a few "help" on staff strings
Signed-off-by: Fridolyn SOMERS <fridolyn.somers@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested according to test plan. Checked various pages in OPAC,
staff and intranet, translation was ok.
Passes QA script and tests.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes the following rwo errors:
1. When selecting 'show more' above a facet, the advanced search page
is displayed.
2. When restricting search on a library facet, all the biblio records
of this library are returned.
The patch fixes the way URL are encoded with TT filter. See:
http://search.cpan.org/~abw/Template-Toolkit-2.25/lib/Template/Manual/Filters.pod#url
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patch works nicely. Tests done:
- 'More' link on facets redirects to advanced search before applying
the patch. After appyling the link works correctly.
- In my tests, the facet links themselves worked nicely, limiting the
search as expected.
- Availability search works ok for me with patch applied.
- Also made sure to click on some links containing diacritcts (German
umlauts).
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
To test:
Make sure
- independentbranches is turned on
- Your user doesn't have superlibrarian permission
Then
- Try to check out an item with home and holding branch !=
logged in branch
Patch works alright.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Looking at the TT plugin directory I notice we have some plugins that
seem to do the same thing:
KohaBranchName.pm
Branches.pm
This patch drops KohaBranchName in favor of Branches
Test Plan:
1) Apply this patch
2) View a basket group, note the branch name is displayed
3) View a subscription's details, note the branch name is displayed
4) View suggestions, note the branch names are displayed
5) Return an item that needs transfered, note the branch name is displayed
6) Run 'prove t/db_dependent/Koha_template_plugin_Branches.t'
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Also tested with a branch name with umlauts.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds 3 filters for the serials search:
- location
- callnumber
- expiration date
To test:
- Search serials by location and/or callnumber and/or expiration date
and check that results are consistent.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch repairs a regression introduced by the main
patch where it became impossible to search for cancelled
orders from the advanced order search form.
This patch also tweaks the wording on the order status
drop-down on the order search form to clarify that the
default status filter is orders that have any status
except cancelled.
To test:
[1] Before applying this patch, perform an advanced
order search (acqui/histsearch.pl) for orders
with status cancelled. Observe that no hits are returned.
[2] Apply the patch and run the search again. This time,
the cancelled orders should be returned.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a problem where the quantity / items column
in the acquisitions detail table would display ilnks to
items for cancelled orders.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
With this patch, the basket number on the bib details page is linked
to the basket management page only if the staff user has the appropriate
permissions.
To test:
[1] Log in as a user with the acquisition/order_manage permission.
Bring up a bib record that is attached to an order and verify
that the basket number is an active link.
[2] Log in as a user that doesn't have the acquisition/order_manage
permission. Verify that the basket number displayed on the bib
details page is not a hyperlink.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised. No regressions found.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a new tab "Acquitition details" on the catalogue detail
page. It provides a list of order made for this biblio.
New system preference:
AcquisitionDetails: Hide/Show the new tab. The default for
new and upgraded installations is to display the new tab.
Test plan:
1/ Apply the patch.
2/ Select the "placing an order" value for the AcqCreateItem pref.
3/ Create a new order with X items.
4/ Go on the catalogue detail page for the selected biblio.
5/ Click on the "Acquisition details" tab and check that your order is
displayed. Itemnumbers are present in the last column. Check that links
are not broken.
6/ Close your basket.
7/ Status become "Ordered"
8/ Receive X-1 items.
9/ Come back on the catalogue detail page. There are 2 orders: 1
complete and 1 partial. The complete one has a receive date.
10/ Receive the last item.
11/ Now you have 2 orders with a complete status.
12/ Cancel the last receipt.
13/ You have 1 ordered and 1 complete (2 items).
14/ Cancel the first receipt.
15/ You have 1 ordered (3 items).
16/ Delete your order
17/ You have 1 deleted order.
18/ Switch the AcqCreateItem pref to "receiving an order"
19/ Do again steps 3 to 17.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This dependency is used in load testing (misc/load_testing/*)
Test plan:
Check if you see the dependency listed on About/Perl modules.
Verify if the version information is correct.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Resolves warning on uninitialized author in split on line 128.
Just adds the same behavior for title on line 129 for completeness.
Fixes typo on occurrences and two other minor typos.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
On step 6 (at least), the circulation and return page redirect to the
select branch page and nothing is done.
The script should die if the user used is the sql administrator account.
Test plan:
Suppose that the sql admin account is root/root and koha/koha a
superlibrarian account.
1/
perl misc/load_testing/benchmark_staff.pl --steps=6
--url=http://admin.koha.local/cgi-bin/koha/
--password="koha" --user="koha"
should produce:
...
Step 6
...
2/
perl misc/load_testing/benchmark_staff.pl --steps=1
--url=http://admin.koha.local/cgi-bin/koha/
--password="root" --user="root"
should produce:
Authentication successful
You cannot use the database administrator account to launch this script
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a problem where if a staff member sets the
*defaultSortField/*defaultSortOrder system preferences to relevance
ascending while QueryParser is enabled, default keyword search
would break -- the query parser config did not declare relevance asc
as a possible "modifier".
Note that setting the sort order to relevance ascending does not
actually make catalog search return results with the least relevant
records showing up first; Zebra does not support such a mode. In other
words, relevance ascending acts exactly the same as relevance descending.
Test plan:
0/ Create some biblio with "history" in the title and
ensure that the QueryParser system preference is enabled.
1/ Define prefs defaultSortField = relevance and defaultSortOrder = asc
2/ Search "history" on the staff interface
3/ Note that no result is returned.
4/ Apply the patch
5/ Verify the queryparser config file in use takes the modification into
account (see the queryparser_config value in your $KOHA_CONF file).
6/ Relaunch the search and verify results are returned
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
Verify all sample_frequencies.* files have been moved from optional
to mandatory directories.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
Verify all sample_numberpatterns.* files have been moved from optional
to mandatory directories.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All sample files for numbering patterns are moved from optional
to mandatory.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Under Plack/mod_perl wrapping, sub update_item() will become a closure,
so after the 1st run it will retain its own private instances of the
following variables: $booksellerid, $datereceived, $unitprice, $rrp,
$biblionumber.
I.e., in case update_item() gets invoked 2nd+ time (inside
the same process, but for different-subsequent receives) it may
incorrectly flag the (old, wrong) biblionumber for Zebra reindexing,
and erronously modify the current item[s] with the previously
used (wrong) values.
This simple patch should make acqui/finishreceive.pl Plack-compatible.
Test plan:
Test patched acqui/finishreceive.pl script (create and receive some
orders w/ items, etc.). Ensure items are gettting added and/or modified
correctly during receiving process.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised, no regressions found.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a plugin for field 100 of UNIMARC
authorities.
To test on a UNIMARC site:
1) Apply the patch
2) Edit some authority framework, field 100
3) Link subfield 'a' to unimarc_field_100_authorities.pl
plugin, save
4) Edit or add auth record, click on '...' to bring plugin
5) Modify field 100a
6) Save record
Thanks to Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> for
converting Vitor's original patch to a Git patch and doing
some tidying.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Stephane Delaye <stephane.delaye@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In the templates opac-authoritiessearchresultlist of prog and
bootstrap the incorrect parameter 'valuec' is changed to 'value'
To test:
1) Insert an authority record with a 5xx field (on MARC21 or UNIMARC)
2) Index the record
3) Search for the record in using OPAC authorities search.
4) Click one of the "see also" links built from the 5xx field, the link
doesn't work
5) Apply the patch
6) Close the browser
7) Open the opac and select the english interface
8) Redo the search
9) Now the link works
10) To use the patch in others languages you need to regenerate the
templates.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with bootstrap.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Following commit remove the use to valuec:
commit 31f41e2c1d
Bug 8206: Specify index in OPAC authority search
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The subroutine _filter_fields is not used by the module
and the sub _columns is only used by it
This patch removes the dead code.
To test:
[1] Verify that the following tests pass
t/Budgets.t
t/Budgets/CanUserModifyBudget.t
t/Budgets/CanUserUseBudget.t
t/db_dependent/Acquisition.t
t/db_dependent/Acquisition/GetOrdersByBiblionumber.t
t/db_dependent/Acquisition/Invoices.t
t/db_dependent/Acquisition/OrderFromSubscription.t
t/db_dependent/Acquisition/TransferOrder.t
t/db_dependent/Acquisition/close_reopen_basket.t
t/db_dependent/Bookseller.t
t/db_dependent/Budgets.t
t/db_dependent/Serials.t
t/db_dependent/Serials_2.t
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Looks good to me.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
As a follow-up after December 4 meeting.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Correct addition, no problems found.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes the message that is displayed when attempting to
view circ history for the anonymous patron more informative. It
also removes a potential source of log noise if the AnonymousPatron
system preference happens to be set to a blank value.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When using an anonymous patron to anonymise issues history, this patron
may have a huge number of old issues. In this case, trying to display
the reading history of this patron will perform a huge SQL query.
It is not useful to have the reading history of this anonymous patron.
This patch adds an alert instead of old issues when displaying reading
records of anonymous patron.
Test plan :
- Set syspref AnonymousPatron to 0.
- Select a borrower with old issues. For example 123.
- Look at its reading records page : members/readingrec.pl
=> Old issues are displayed in a datatable
- Set syspref AnonymousPatron with this borrower number. For example 123.
- Look at its reading records page
=> Old issues are not displayed and an alert is displayed
- Using SQL query, remove old issues of this borrower :
DELETE FROM old_issues WHERE borrowernumber=123.
- Look at its reading records page
=> A message is displayed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This works as advertised and seems like a reasonable thing to do. I
suspect that someone will object... Perhaps that person will implement a
solution which uses an AJAX DataTable.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The caching introduced by the main patch is not ideal
as it won't work correctly if a persistance engine is used.
However, I have good reason to expect that bug 8089 will
be worked on (because I'm going to do it) so that Koha::Cache
can be used for this prior to the release of 3.16.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch ensures that the package-level cache is updated
when add_holiday() is used. Note that except for the test
case added by this patch, there doesn't seem to be anything
that actually calls ->add_holiday(); it may be better to remove it.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Each time a Koha::Calendar object is created, its constructor retrieves
all holidays from the database and create a DateTime::Set object with
all holidays.
[RM note: I've observed that the time it takes DateTime::Set to be
initialized with a set of dates increases faster than linearly with
the number of dates. I think this, more than just retrieving a bunch
of holidays from the database, is what is most expensive.]
In one of our customer's DB, there are 11085 special_holidays and 598
repeatable_holidays. When a loan is returned, there are 3 calls to
Koha::Calendar->new.
This patch adds caching of the holiday list via package-level variables
as well as lazy fetching of the holidays. (RM note: this means that if
a persistance engine is in use, updates to the holiday list will not
be reflected during checkout. I'm allowing this breakage for now on
the plan that bug 8089 will be fixed soon and we can switch to using
Koha::Cache).
Nytprof benchmarks (on a 3.8.x branch):
In DateTime::Set->from_datetimes:
3 times (5.49ms+4.90s) by Koha::Calendar::_init at line 80 of Koha/Calendar.pm, avg 1.63s/call
on a total of 7.67s (of 10.2s), executing 6353333 statements and 3031273 subroutine calls in 147 source files and 36 string evals.
for the circulation/return.pl page.
Comparing the access_log:
Without the patch:
checkout: time=2759838
checkin: time=1832751
Without the patch and with overdues:
checkout: time=1086727 + time=1144706
checkin: time=3928854 (x2)
With the patch and overdues:
checkout: time=1077839 + time=1060886
checkin: time=2420898
Test plan:
- checkout an item with a return date < today
- checkin the item and verify the suspension period is well calculated
(depending on the holidays).
- prove t/db_dependent/Holidays.t
- t/Calendar.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Intermittently problems in the calling environment
cause a C4::Biblio routine to be called with an undefined
MARC::Record object. This results in the process
dying and returning to the end user a low level
message such as 'cannot call method x on an undefined
object'.
For exported subroutines taking a MARC::Record object,
check that object is defined otherwise return a logical
return value and log a stack trace to the error log.
A couple of cases were checking but dying, this may have
unwelcome results in a persistent environment so croak has
been downgraded to carp
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adds lots of checks for $record in various places, should
not affect behaviour.
Passed all tests and QA script, including new unit tests.
Tested adding and saving a new record.
Also tested detail and result pages without XSLT.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Same fix for the staff interface.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Both patches tested with English and German, diacritics
now appear correctly if UTF-8 is selected as encoding.
Passes all tests and QA script.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
