[koha-commits] main Koha release repository branch 3.16.x updated. v3.16.14-25-ga4fcb6a
Git repo owner
gitmaster at git.koha-community.org
Fri Oct 2 10:54:18 CEST 2015
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "main Koha release repository".
The branch, 3.16.x has been updated
via a4fcb6a535907acf68e58ab8de43ecb6b6c9942d (commit)
via 3f7deae568227027fb3664b0109af2ce7b8d6c16 (commit)
via 37f0bddb17ed53e7049c295c6e2b24c3392c888c (commit)
via 53e060308d163fed9411c3d4a4b5027aba6832bc (commit)
via 20e74039a306dfb279b551f704b46708c95a96ec (commit)
via 3e7564e5938545d9ac3997b3f25d18ec975d2db3 (commit)
via f8472ef26cf352e5ee9df2420d78fa2dca3db074 (commit)
via 499bb94087c67f0a9a123c9c756e847cc6818bfd (commit)
via 56054e34a6d1cea5f57817d699ac1fbb696fcb44 (commit)
via 1180efe11e93d1e3004ec29e0962ac83ed54e461 (commit)
via efa0ff294398f065f923309b3eba4783205b9c29 (commit)
via beb77b06bd3867eca1d867e1fca0e62a629560a1 (commit)
via 821aa63e4126331ad36164ac98f5f4093bbb72ed (commit)
via 46559c51e7de4bfaa77eb5878d82c7b85707bfbd (commit)
via 1016ba0f75d1fca4dcd8dda1f73311f1cb9237ef (commit)
via f4ba93afd2241bf7689199674c3596135996971f (commit)
via 087b6a43d9af1179485e7745bbf7c905f71d2a8f (commit)
via 95fc0a6b2f27d4c584a5f7a4b127fedd2cd82124 (commit)
via 6bb191aab575dbd7b6a03d5c9da1fa547a03acf3 (commit)
via 643af3350915f375f1e60bfe5935d0827ef35b8c (commit)
via 62c341301f3745b48bdee6363e258819e60b29e5 (commit)
via f365143c184dfd96fb4bd98dd1873ac3feb26794 (commit)
via 2e87354a74948e494965ee21e3ab6160c6467b2b (commit)
via 7ef68ea59d1f30529645bb24fbd73082354dd833 (commit)
via 22fa695d598a8f3345a883d15079f1021cbc0161 (commit)
from 6edb2c2ab6147a0d4e60c600c6d9b37572736637 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit a4fcb6a535907acf68e58ab8de43ecb6b6c9942d
Author: Mason James <mtj at kohaaloha.com>
Date: Sat Jul 25 20:51:52 2015 +1200
Bug 14602 - Fix failing t/Creators.t test
to test..
1/ run t/Creators.t test from git repo, get a FAIL
2/ apply patch
3/ repeat step 1, get a PASS
mason at xen1:~/g/k/3.16.x$ sudo koha-shell -c 'export PERL5LIB=/home/mason/g/k/3.16.x ; cd /home/mason/g/k/3.16.x ; prove -v t/Creators.t' k316x1
t/Creators.t ..
1..16
ok 1 - use C4::Creators;
ok 2 - use C4::Creators::PDF;
ok 3 - testing new() works
ok 4 - testing pdf file created
ok 5 - testing Add() works
ok 6 - testing Bookmark() works
ok 7 - testing Compress() works
ok 8 - testing Font() works
ok 9 - testing FontSize() is set to 12 by default
ok 10 - testing FontSize() can be set to a different value
ok 11 - testing Page() works
ok 12 - testing StrWidth() returns correct point width
ok 13 - testing Text() writes from a given x-value
ok 14 - testing Text() writes to the correct x-value
ok 15 - testing End() works
ok 16 - test file /tmp/4YjPQDExeS created OK
ok
All tests successful.
Files=1, Tests=16, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.48 cusr 0.05 csys = 0.57 CPU)
Result: PASS
Signed-off-by: Liz Rea <liz at catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Mason James <mtj at kohaaloha.com>
commit 3f7deae568227027fb3664b0109af2ce7b8d6c16
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Fri Jul 3 11:02:22 2015 +0200
Bug 14382: [QA Follow-up] Bad regex alarm
The regex /|date>>/ will match much more than you like :)
The unescaped pipe is bad, but you also need to remove the >> because
the split a few lines above it removes them already.
This allows you to recover from an error like this one, running another
report with a string parameter:
The given date (india%) does not match the date format (us) at
Koha/DateUtils.pm line 144.
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Amended for possible spaces around the word date.
commit 37f0bddb17ed53e7049c295c6e2b24c3392c888c
Author: Mark Tompsett <mtompset at hotmail.com>
Date: Wed Jun 24 12:13:46 2015 -0400
Bug 14382: Non-ISO Date parameters generate empty reports.
The issue is that SQL expects ISO dates, but the user may wish to view dates according to the dateformat system preference.
By detecting a date preference, the non-ISO dates can be converted to ISO dates before being stuffed back into the SQL query to be executed.
TEST PLAN
---------
1) Add a report with date parameters.
-- I used 'Holds placed in date range' from
http://wiki.koha-community.org/wiki/SQL_Reports_Library
2) Set your dateformat to YYYY-MM-DD
3) Run the report
-- Note the SQL reads
"... BETWEEN '{date formatted in YYYY-MM-DD}'..."
-- If there is supposed to be data, there is some.
4) Set your dateformat to MM/DD/YYYY
5) Run the report
-- Note the SQL reads
"... BETWEEN '{date formatted in MM/DD/YYYY}'..."
-- If there is supposed to be data, there is none.
6) Apply patch
7) Repeat steps 2-5
-- The SQL will always read YYYY-MM-DD (ISO) format.
-- The report will have data, if there is some.
8) koha qa test tools.
Signed-off-by: Amit Gupta <amit.gupta at informaticsglobal.com>
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Adding a QA follow-up.
Signed-off-by: Mason James <mtj at kohaaloha.com>
commit 53e060308d163fed9411c3d4a4b5027aba6832bc
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Tue Sep 1 16:11:54 2015 +0200
Bug 14683: [QA Follow-up] Similar change for staff
Script memberentry.pl contained a similar line.
Solution is simpler here.
Test plan:
[1] Add, change or clear the sms number at staff side.
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit bdf4894c507f4bac6b2b79c7ca3b7a556d246ed5)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit c323e07c0c7ec403af15e40da7d82b997cb3eefc)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 20e74039a306dfb279b551f704b46708c95a96ec
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Fri Aug 28 09:13:09 2015 +0200
Bug 14683: [QA Follow-up] Mixup between mobile and smsalertnumber
This is an issue discussed on older reports already in the past.
Column mobile in borrowers is actually 'Other phone', not necessary a
mobile number. The name of the field is confusing. (Renaming it is
outside the scope of this report.)
The field that we are editing here is smsalertnumber. It should not be
compared with mobile at all.
What could be the side-effect of this correction?
===
First, the change is only relevant for libraries with pref SMSSendDriver
enabled.
In the past patrons editing their message preferences saw mobile (read:
other phone) in their smsalertnumber field (if the latter was still empty).
If they saved it, it was copied to smsalertnumber.
This change does not affect these patrons. They just have the same number
in two columns. No big deal.
What if a patron does not yet have a smsalertnumber? In that case no sms
is sent in Letters.pm. So no change in behavior. If he submits
opac-messaging now, he will no longer copy his other phone to smsalert [we
cannot assume that it was mobile anyway!]. If he enters a mobile number,
it will be saved correctly in the right field.
Conclusion: this change will not break things or hurt anyone. It only
prevents unwanted copying other phone to smsalertnumber.
Also modified the compare to prevent uninitialized warnings.
And removed a commented warn.
Test plan:
[1] Add, edit or delete the SMS number on opac-messaging regardless of
the value of Other Phone (in the badly named mobile field).
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 9b8d7168beb27342c4c483a0812e3a6789fabced)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit bc720464216eca9d5283596af23d2c2c926e7093)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 3e7564e5938545d9ac3997b3f25d18ec975d2db3
Author: Joonas Kylmälä <j.kylmala at gmail.com>
Date: Wed Aug 19 11:42:50 2015 +0000
Bug 14683: Unable to clear SMS number
Enables to clear SMS number.
To test:
1. Go to opac-messaging.pl
2. Insert SMS number and submit
3. Clear SMS number and submit
4. Observe that the sms number did not change
5. Apply patch
6. Clear SMS number and submit
7. Observe that the sms number changes
Sponsored-by: Vaara-kirjastot
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Adding a follow-up.
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 5b1c7e4c359e974e5aca801579db72b356741a0f)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 227d7b950e682300a7697ada4f6837a950f098e6)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit f8472ef26cf352e5ee9df2420d78fa2dca3db074
Author: Lari Taskula <larit at student.uef.fi>
Date: Thu Jul 30 18:34:49 2015 +0300
Bug 14621: Messaging preferences table needs to be sorted
I have been working with messaging preferences and I noticed a weird issue in Firefox on Ubuntu.
On messaging preferences page, the table is unsorted and the content in rows are generated randomly
on every page refresh. When you select/deselect checkboxes and refresh the page (without posting the changes),
Firefox will remember your choices. Now the issue is that when the table is unsorted and the rows keep
changing on page refresh, Firefox has trouble remembering your choices. This makes it appear as if the
checkboxes are magically changing values on each page refresh.
Here is a patch that prevents this problem by sorting the messaging settings.
Signed-off-by: Chris Cormack <chrisc at catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 46ac35f8e11c06a784ca309b0dc876aff9469edb)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 6c44d1f4645b4c98577d6af23b05b9608b421253)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 499bb94087c67f0a9a123c9c756e847cc6818bfd
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date: Mon Aug 31 09:36:02 2015 -0400
Bug 14760: Disabled courses display in the course reserves list for items
If an item is on reserve for two courses but one of those courses is
disabled, both courses are still listed on opac-detail.pl!
Test Plan:
1) Enable course reserves
2) Create two courses
3) Place one item on reserve for both courses
4) Disable one of the two courses
5) View the record details for that record/item
6) You should see both courses listed in the course reserves column
7) Apply this patch
8) Reload the page
9) You should now only see the active course in the course reseves column
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron at veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 73e9dcb70fcf24dc87af7c5af6f38102206863ae)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 9c31f1af9bb7b87dd794f40dd2bc7673b720c674)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 56054e34a6d1cea5f57817d699ac1fbb696fcb44
Author: Fridolin Somers <fridolin.somers at biblibre.com>
Date: Tue Aug 25 11:33:04 2015 +0200
Bug 14721: OAI-PMH must return error when no results
When getting records from OAI-PMH, an error must be returned if there is no results.
See : http://www.openarchives.org/OAI/openarchivesprotocol.html#ErrorConditions
Test plan :
- Enable OAI webservice
- Perform a query that will return no results. ie : /cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml&from=2099-12-30&until=2099-12-31
=> Without patch you get a response with :
<ListRecords/>
=> With patch you get a response with error code :
<error code="noRecordsMatch">No records match the given criteria</error>
- Check a good query returns still results
- Same test with ListIdentifiers verb
Signed-off-by: Mirko Tietgen <mirko at abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 64992a05ce87af7bf595c8d6f0b9d528887a2e44)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 3d8e059513db08f2070e33ea1562d7cdd915797c)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 1180efe11e93d1e3004ec29e0962ac83ed54e461
Author: Julian Maurice <julian.maurice at biblibre.com>
Date: Fri Sep 4 08:57:08 2015 +0200
Bug 14766: unimarc_field_4XX: escape ', ", \n, \r
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit abd71d017ea68f4209e41b34282e8fce8170e175)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit c7dfbfedd3d298753b4d96d5ce50363c2cfc65fc)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit efa0ff294398f065f923309b3eba4783205b9c29
Author: Paul Poulain <paul.poulain at biblibre.com>
Date: Wed Aug 26 10:54:30 2015 +0200
Bug 14766: Complete cataloguing plugin unimarc_field_4XX
Add subfields l, n and o for better UNIMARC compliance
Signed-off-by: Chris Cormack <chrisc at catalyst.net.nz>
Note: I just did a code audit here, as I don't know enough about
UNIMARC to know if the 4XX fields should have these subfields.
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 503dd6036974b4208bd5cd60a87bb28599987f45)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 84ee44110a934632ddcc8da59aa805c45a79786e)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit beb77b06bd3867eca1d867e1fca0e62a629560a1
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Tue Jul 14 13:12:46 2015 +0100
Bug 11273: FIX barcode generation in acquisition if hbyymmincr
When AutoBarcode is activated and you have set AcqCreateItem to 'on
order' there is a Javascript error when you try to generate a barcode
for the item:
TypeError: document.f is undefined
http://localhost:8080/intranet-tmpl/lib/jquery/jquery.js
Line 11
Test plan:
0/ a. Set AutoBarcode to hbyymmincr
b. Set AcqCreateItem to 'on ordering'
c. Set the plugin barcode.pl to the barcode field for the default
and the ACQ frameworks
1/ Go on the add items page (cataloguing/additem.pl) and confirm that
the plugin works as expected.
2/ Go on the New order page (acqui/neworderempty.pl) and confirm that
the plugin works as expected.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron at veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 5b521eb394771ee305777f0b44098be5fdd11cc7)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 272650cb3f1e2d3ac24559ede0049b263b829762)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 821aa63e4126331ad36164ac98f5f4093bbb72ed
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Tue Jul 14 18:07:37 2015 +0100
Bug 14354: Prevent edition of items from other branches if IndependentBranches is on
If IdependentBranches is ON, to edit/delete items from other branches
you need to be superlibrarian.
Currently a "simple" staff user cannot edit them from the edit item page
but from the catalogue detail page.
The edit links should not be displayed on this table.
Test plan:
O/ Set IndependentBranches to "Prevent".
Create a record and add 2 items:
Set homebranch to L1 for item I1.
Set homebranch to L2 for item I2.
1/ With a superlibrarian user, you should be able to edit both items.
2/ With a "simple" user attached to L1, you should only be able to edit
I1. The edit links should not be displayed for I2.
Note that the checkbox is displayed on the catalogue detail page (item
list), but on the batch tools, it won't be possible to select non-modifiable
items.
TODO: Add a server-side check. Indeed it is still possible to edit an
item if the user know the url.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron at veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit bcab2416399e93f5ce9b1083395c052046d5d02a)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 28fe340ea75475903a1063f734dec45781d35f90)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 46559c51e7de4bfaa77eb5878d82c7b85707bfbd
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Wed Sep 2 15:07:07 2015 +0100
Bug 11247: Improve tests
This patch makes the tests non dependent on the DB and test the 3 marc
flavours.
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 6e0b61e2acea7c797c1da727474daf7d7a657574)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 27ba1a6fa1a5be170d9bf04747f31caab15766b1)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 1016ba0f75d1fca4dcd8dda1f73311f1cb9237ef
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Wed Aug 26 14:09:53 2015 +0200
Bug 11247: Add a simple unit test for TransformHtmlToXml
The unit test is db dependent (as Jonathan correctly remarked),
since the sub checks a preference.
Test plan:
Run t/db_dependent/Biblio/TransformHtmlToXml.t
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit d1335a766d7b54c470701b0055fc99be2e7e7628)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 74e46b7467aa69e5a77d0b7689ddd2d24d76805d)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit f4ba93afd2241bf7689199674c3596135996971f
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Tue Aug 18 18:40:31 2015 +0100
Bug 14584: Encoding broken with system preferences
The pref are double encoded.
From bug 12411:
"This will fix the encoding issues existing in 3.14 and 3.16.
The issue still appear in master but is fixed by bug 11944."
They should not have been pushed together.
Test plan:
1) You need an accentuated language installed.
2) Go to NoLoginInstructions pref, and add some accentuated message like
"Hélo médames é mècieüx"
3) refresh opac home page, message should be gibberish
4) apply patch. Message should be ok now.
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
Works as expected.
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at unc.edu.ar>
(cherry picked from commit 813a047e236947a815c4be3c3dde38f19844b962)
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
(cherry picked from commit 270187404e87bdae985e70a590834ed2dc5d49c7)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 087b6a43d9af1179485e7745bbf7c905f71d2a8f
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Fri Jul 10 16:11:48 2015 +0100
Bug 12965: Prevent to erase an existing item type
On creating an item type, if it already exists, it will replace the
existing one.
This patch prevent that and display a message to the interface.
Note: The fields are lost.
Test plan:
1/ Create an item type 'AAA', description 'AAA'
2/ Edit it, update the description with 'BBB'
3/ Create an item type 'AAA' with a description 'CCC' => you should get
a warning "already exists".
Works well, no errors
Signed-off-by: Amit Gupta <amit.gupta at informaticsglobal.com>
Signed-off-by: Joonas Kylmälä <j.kylmala at gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Warning message is triggered.
Adding, editing and deleting item types still works.
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit eb12ee1e223b662cd1e89c0a56a5d1c083ba1ddc)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 95fc0a6b2f27d4c584a5f7a4b127fedd2cd82124
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Wed Jul 15 12:49:03 2015 +0100
Bug 12885: Fix if url contains +*... and HTML5 Media is enabled
The special regex chars are not escaped in C4::HTML5Media.
Test plan:
1/ Set 856$u=http://www.mrqe.com/lookup?talented+mr.+ripley
2/ Enable the pref HTML5Media
3/ Go on the detail page
It should not explode.
Signed-off-by: Mirko Tietgen <mirko at abunchofthings.net>
Signed-off-by: Joonas Kylmälä <j.kylmala at gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 085d766a0524e399d0c9c9e807d8c0acd0da6a19)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 6bb191aab575dbd7b6a03d5c9da1fa547a03acf3
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Mon Jul 13 17:34:53 2015 +0100
Bug 13943: Prevent the deletion of items if the user cancels
On the edit items page, there is some weird JS code: if the user clicks
on the delete link and then cancel, the item is deleted anyway.
It's caused by the following JS code in browser.js
$('a[href*="biblionumber="]').click(function (ev) {
ev.preventDefault();
window.location = $(this).attr('href') + '&searchid=' + me.searchid;
});
Test plan:
- Do a search with multiple results
- Go to the detail page (make sure results browser shows up!)
- Use the "Edit items" link from the toolbar
- Delete an item (try both way)
- Choose "cancel"
- Delete an item (try both way) and confirm the deletion
You should see the browser after the deletion and the item should have
been deleted correctly.
- Edit an item (try both way)
You should see the browser (did not work before this patch)
Note: Before this patch, the 2 first columns didn't contain the
edit/delete item links, now it's only the 1st one.
Signed-off-by: Nick Clemens <nick at quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Much better!
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit f7214859df15abfe874141bcc1a32b57067f7c54)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 643af3350915f375f1e60bfe5935d0827ef35b8c
Author: Srdjan <srdjan at catalyst.net.nz>
Date: Thu Nov 14 19:10:30 2013 +1300
Bug 11247: Fix calls of TransformHtmlToXml
The ind_tag of TransformHtmlToXml is unused.
Some calls to this function incorrectly revert indicator and ind_tag (which
is not a problem when both are empty..)
Patch of Srdjan Jankovic, amended and signed off by Marcel de Rooy.
The following calls are fixed:
call in acqui/addorder.pl: switched indicator with ind_tag
call in acqui/addorderiso2709.pl replaced too
acqui/finishreceive.pl replaced too
These calls are fine:
two calls in cataloguing/additem.pl are fine
call in serials/serials-edit.pl is fine
call in tools/batchMod.pl is fine
The folllow-up patch adds a simple unit test.
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
With AcqCreateItem=='placing an order', tested if adding an order still
worked (covered both addorder.pl and addorderiso2709.pl).
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 22b41063981de608402d1dd87f6aa9e2010245dd)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 62c341301f3745b48bdee6363e258819e60b29e5
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date: Wed Aug 19 16:24:32 2015 +0100
Bug 14696: useless use of String::Random in catalogue/search.pl
Bug 10404 adds the use of String::Random to catalogue/search.pl but bug
11369 removes it without removing the import line.
Test plan:
git grep String::Random catalogue/search.pl
should not return anything
Signed-off-by: Joonas Kylmälä <j.kylmala at gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen at unc.edu.ar>
(cherry picked from commit 90285259e898f4734684edf10a64c252a180fdf6)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit f365143c184dfd96fb4bd98dd1873ac3feb26794
Author: Jonathan Druart <jonathan.druart at biblibre.com>
Date: Fri Apr 24 10:02:19 2015 +0200
Bug 11880: Select what has been selected before
The previous patch wants to select the barcode option when the user is
on the item search for label, in all cases.
So even if 'title' is selected, a search done, and there is no result,
the barcode index is selected anyway.
In this case, the title option should be kept.
Test plan:
Confirm that the barcode option is the default choice, but other values
are kept if the search does not return any result.
Followed test plan, behaves as expected. Tested with all choices.
Signed-off-by: Marc Veron <veron at veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
(cherry picked from commit 1f0ff90360c21e5e24df9f455681b1bf4ae92031)
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 2e87354a74948e494965ee21e3ab6160c6467b2b
Author: Frédérick <frederick.capovilla at libeo.com>
Date: Fri Feb 28 16:21:46 2014 -0500
Bug 11880: Select the barcode index by default then searching for label items.
Test case:
* Go to "Tools -> Label creator -> Manage batches"
* Click on the "New batch" button
* Click on the "Add item(s)" button
* A search window should open. The "Barcode" value should be selected in the the selectbox.
Followed test case. Patch behaves as expected.
Signed-off-by: Marc Veron <veron at veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 7ef68ea59d1f30529645bb24fbd73082354dd833
Author: Joonas Kylmälä <j.kylmala at gmail.com>
Date: Tue Aug 25 07:24:54 2015 +0000
Bug 14703: Holidays description shows \r\n for every new line
Adds a new line for the holiday's description instead of the string
\r\n.
Test plan:
1. In tools -> Calendar look at some holiday's description
(Do a new holiday with description of multiple lines if
there is not already)
2. Notice that there is characters \r\n if someone has put
a newline in the holiday's description
3. Apply patch
4. See that the new lines show there now nicely
Sponsored-by: Vaara-kirjastot
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Amended slightly: no need to replace title.
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
commit 22fa695d598a8f3345a883d15079f1021cbc0161
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date: Fri Aug 22 13:29:28 2014 -0400
Bug 12632: Hold limits ignored for record level holds with item level itemtypes
The crux of the issue is that if you are using item level itemtypes, but
are allowing biblio levels holds, those holds do not have items.
So, in CanItemBeReserved, when Koha counts the number of holds to
compare against the given rule, it will always give 0 ( except of course
for found holds, and the occasional item-level hold ).
So the query is saying "link each of these reserves to the reserved
item, and count the number of reserves this patron where the itemtype is
DVD". However, since these are all record level reserves, there are no
items to link to, and so when it looks for all reserves this and item
whose itemtype is DVD, it finds zero reserves!
This patch solves the problem by looking first at the item level
itemtype, and if it does not exist, then it looks at the record
level itemtype. For installations using record level itemtypes, the
behavior remains unchanged.
Test plan:
1) Enable item level itemtypes
2) Create two records with one item each of a given itemtype
3) Create a single issuing rule and limit the holds allowed for that
itemtype to 1
4) Place a record level hold on your first record
5) Attempt to place a record level hold for the same patron on your
second record. You should not be able to but you can!
6) Apply this patch
7) Repeat step 5, note you can no longer place the hold!
Signed-off-by: Paola Rossi <paola.rossi at cineca.it>
Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
Signed-off-by: Liz Rea <wizzyrea at gmail.com>
-----------------------------------------------------------------------
Summary of changes:
C4/Barcodes/ValueBuilder.pm | 10 ++-
C4/Biblio.pm | 2 +
C4/HTML5Media.pm | 2 +-
C4/Members/Messaging.pm | 3 +
C4/Reserves.pm | 10 ++-
Koha/Template/Plugin/Koha.pm | 3 +-
acqui/addorder.pl | 2 +-
acqui/addorderiso2709.pl | 2 +-
acqui/finishreceive.pl | 3 +-
admin/itemtypes.pl | 38 ++++++----
catalogue/detail.pl | 9 ++-
catalogue/search.pl | 1 -
cataloguing/value_builder/unimarc_field_4XX.pl | 18 +++++
.../prog/en/modules/admin/itemtypes.tt | 16 ++++
.../prog/en/modules/catalogue/detail.tt | 7 +-
.../prog/en/modules/cataloguing/additem.tt | 52 +++++++------
.../cataloguing/value_builder/unimarc_field_4XX.tt | 9 +++
.../intranet-tmpl/prog/en/modules/labels/search.tt | 28 +++----
.../prog/en/modules/tools/holidays.tt | 2 +-
.../opac-tmpl/bootstrap/en/modules/opac-detail.tt | 18 +++--
labels/label-item-search.pl | 3 +-
members/memberentry.pl | 14 ++--
opac/oai.pl | 16 ++++
opac/opac-messaging.pl | 10 +--
reports/guided_reports.pl | 7 +-
t/Biblio/TransformHtmlToXml.t | 80 ++++++++++++++++++++
t/Creators.t | 11 +--
27 files changed, 277 insertions(+), 99 deletions(-)
create mode 100644 t/Biblio/TransformHtmlToXml.t
hooks/post-receive
--
main Koha release repository
More information about the koha-commits
mailing list