Jonathan Druart [Tue, 22 Sep 2015 10:55:55 +0000 (11:55 +0100)]
Bug 14141: Fix copy action
Test plan:
Try to copy a letter to a library which already have this letter (same
letter_code) defined.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 51aad946c6411a484ffde6934d541b9bb1dd2aa3) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 2943112a2844f7106de0139bb449c3b3ef27fb02) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 14 Jul 2015 11:00:33 +0000 (12:00 +0100)]
Bug 14141: Do not let edit the branch when updating/copying notice
If a user modify the library when he's updating a notice, the notice
will be duplicated, instead of modified.
To reproduce:
1/ Go on the notice & slips tools (tools/letter.pl)
2/ Create a notice A for library L1
3/ Edit this notice and update the library with L2
4/ On the list view, you will observe that 2 notices A now exist, one
for L1 and one for L2.
The code in tools/letters.pl should be rebuilt completely, it becomes a
house of cards. To prevent this bug, I suggest to not let the user
modify the library value on editing a notice.
It cans be done by copying the notice to another library and remove the
original one.
Counter patch welcomed.
Test plan:
1/ Go on the notice & slips tools (tools/letter.pl).
2/ Create a notice A for library L1.
3/ Edit this notice: you are not able to modify the library anymore.
4/ Copy the notice to library L2. You are not able to modify the library
neither.
Works ok.
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com> Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 605f42a721b3a534d01b8f7c73502cfa810147ad) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 54cf2cc340e7f2abe96cdcfcb8aa4bb82031df79) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Mon, 14 Sep 2015 15:01:48 +0000 (16:01 +0100)]
Bug 14811: Don't update permanent_location with CART or PROC
The permanent_location should not be set to CART or PROC when the item
is edited.
Otherwise we lost an important info.
Test plan:
0/ Set the ReturnToShelvingCart pref
1/ Create an item with location "on_my_shelf"
2/ Check the item in and out
3/ Look at the DB values, location should be "CART" and
permanent_location unchanged (on_my_shelf)
4/ Edit the item, add a note for instance
5/ Without this patch, the permanent_location is erased with 'CART' and
you have definitely lost the info.
With this patch, the permanent_location is unchanged.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 2a319e7ae2a7e0d10450a6ca791eabbee01c0787) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Conflicts:
t/db_dependent/Items.t
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit b8f0a595344d28d85383007138715d7db131f136) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Conflicts:
Koha.pm (3.18 does not have)
installer/data/mysql/updatedatabase.pl (routine version updates)
Jonathan Druart [Tue, 15 Sep 2015 09:36:44 +0000 (10:36 +0100)]
Bug 14820: Add missing prefs SMSSendUsername and SMSSendPassword
These 2 system preferences are missing from the sysprefs.sql file.
Test plan:
Execute the updatedatabase script and confirm that the 2 prefs are now
in the systempreferences table.
Search for "sms" in the system preferences search box, you should see
the 3 prefs.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 39dc8b5a9da902f9f90850421dc2815e448222e5) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(cherry picked from commit 27e58d8a204b5977d6ca64567a79f1ee90df9e6f) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Mon, 28 Sep 2015 09:58:16 +0000 (10:58 +0100)]
Bug 14910: Redirect to the circulation module after a renew
iIf a patron is renewed from the circulation module, the librarian
should be redirected to the circulation module.
This works correctly if the renew is done from the patron module
(members).
This is caused by a typo in the template: desintation vs destination.
This patch also removes the cardnumber parameter to the setstatus.pl
script, it is not needed given that borrowernumber is always passed.
This has a good side-effect, it will fix bug 14691. The cardnumber does
not exist anymore, so no need to escape it :)
Test plan:
0/ Do not apply this patch
1/ Create a patron with a cardnumber with a quote (rm'me) and another
one without a quote (rmme)
2/ Go on the checkouts page (circ/circulation.pl)
3/ Renew the 2 patrons
=> With rm'me you are redirected to the circ module - ok
=> With rmme you are redirected to the member module - nok
4/ Go on the patron detail page (members/moremember.pl)
5/ Renew the 2 patrons
=> you are redirected to the member module - ok
6/ Delete the patrons
=> Nothing happend with rm'me, there is a JS error on the page - nok
=> rmme is deleted - ok
7/ Apply the patch and recreate rmme
8/ Repeat 2, 3, 4, 5
=> You are redirected to the correct module
9/ Delete the patrons
=> They are successfully deleted
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Followed the test plan, works as advertised. (I did have some problems
initially, but that was caused by me not using the interface in
English...)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 653d305452a27d19d929e2acff71643845686af3) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(cherry picked from commit dcd54915d0ce56acd900de313715be416ddc9c7e) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Marc Véron [Thu, 1 Oct 2015 08:51:18 +0000 (10:51 +0200)]
Bug 14929: Fix missing display of help page in contract management
This patch renames / moves the file
koha-tmpl/intranet-tmpl/prog/en/modules/help/acqui/acqcontract.tt
to
koha-tmpl/intranet-tmpl/prog/en/modules/help/admin/aqcontract.tt
To test:
- Go to Home > Acquisition > [Vendor] > Contracts
(/cgi-bin/koha/admin/aqcontract.pl?booksellerid=XXXX)
- Verify that Help displays as appropriate.
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised. All the tabs similar to "Contracts" have
working help pages.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 4a43c3820555574ad7c83807b6b7a7db2032d340) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(cherry picked from commit 7f1efe089871ab23f8fc4a738fb79601786b907d) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 15 Sep 2015 10:44:32 +0000 (11:44 +0100)]
Bug 12311: Do not return a lost item if modified in a batch
If a item is lost and issued, and you modify it in a batch, the item
will be marked as returned. It should only be returned if the item is
marked as lost.
Test plan:
1/ Check an item out and mark it as lost
2/ Edit it in a batch (tools/batchMod.pl) and edit a field (notes for
instance)
3/ The item should still be issued to the patron
4/ Edit it in a batch and edit the lost value, marked it as not lost
5/ The item should still be issued to the patron
6/ Edit it in a batch and edit the lost value, marked it as lost
7/ The item should have been returned.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Just one comment, lost status can be changed only if you change default framework to another framework then edit the item. If you change it in Item menu at left side of screen this will remove the item from patron’s checkouts and patron charged for lost item.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
For testing purposes the lost item field can be set to visible
in the framework used. That will allow changing it without
returning it at the same time.
The other option is using the longoverdues.pl script. Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit ca268ad877a6712aa07cb7c873c918d6fdfac52d) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(cherry picked from commit 6709813a022de5e2cc53730e0299259ed9dc53bd) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Test plan:
Set the cardnumber of one of the patron to an empty string
Do a patron search and use filters
The search will redirect to the patron detail page of the patron with
the empty string
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Kyle M Hall [Wed, 26 Aug 2015 15:42:14 +0000 (11:42 -0400)]
Bug 14733: Unit Tests
Signed-off-by: Heather Braum <hbraum@nekls.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Conflicts:
t/db_dependent/Holds.t Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Mon, 21 Sep 2015 15:46:00 +0000 (16:46 +0100)]
Bug 14733: Replace 'priority' with 'estimated priority'
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 8ef69e473b1f1a0daac559bf19818fd04b2c5313) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Kyle M Hall [Wed, 26 Aug 2015 15:43:08 +0000 (11:43 -0400)]
Bug 14733: Prevent a record from having holds with duplicate priorities
It is possible to create holds with duplicate priorities.
The reason for this is that typically the priority is calculated before
placing the hold. When the hold is placed the priority is calculated.
This can easily be shown by opening up two browser windows and starting
to place a hold for a record in each one. You'll see that both list the
same priority. If you than place the hold in each window, both holds
will have the same priority!
Test Plan:
1) Run unit tests pre-patch, note they fail
2) Run unit tests post-patch, note they succeed
Signed-off-by: Heather Braum <hbraum@nekls.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 37ad2d78679fc8487811ff9cd1679eecac30faa5) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Fri, 6 Feb 2015 15:19:14 +0000 (16:19 +0100)]
Bug 13675: Do not set aqorders.budget_id to NULL
C4::Acquisition::ModReceiveOrder updates the aqorders with
budget_id=NULL if no budget_id given in parameter.
Actually the same budget_id should be used.
In tests (especially t/db_dependent/Acquisition/TransferOrder.t),
ModReceiveOrder is not called with a budget_id param and set to NULL the
budget_id value.
test plan:
prove t/db_dependent/Acquisition/TransferOrder.t
should return green
Note that this bug should not appear using the interface.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The fix makes sense, and running
$ prove t/db_dependent/Acq*
returns all green. koha-qa.pl also likes it.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 2df541712fd691ee817568ed9d14e94bba13424e) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 14 Jul 2015 14:33:34 +0000 (15:33 +0100)]
Bug 14509: Reject invalid passwords
Bug 10177 rejects password with leading or trailing whitespaces, but
only on the member-password page.
It's not consistent to only do this check on 1 place.
This patch adds the check for the 2 other places: memberentry and at the
OPAC.
Test plan:
1/ Edit a patron and set a password with leading and/or trailing
whitespaces. You should not be allowed to do it (no server side check).
2/ Same at the OPAC ("Change you password" tab). Here there is a server
side check.
Followed test plan. Works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 1b8f3194e9f616f46260c849eda5a9f6c717d5fa) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(cherry picked from commit a19c1257eb9a91426b42b7bad94f211cd9f046a4) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Brandon [Thu, 15 Jan 2015 22:42:52 +0000 (22:42 +0000)]
Bug 10177 - Whitespace is accepted within the password but leading and trailing spaces are not.
Test plan:
1: Go to your patron
2: Go to change username and/or password.
3: Change password to something with spaces in the middle. Notice it is invalid.
4: Apply this patch.
5: Change password again using spaces in the middle. Notice it is accepted.
6: Change password with leading and/or trailing spaces, notice they are not accepted.
Applied bothe patches. Followed test plan. Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Brandon [Wed, 14 Jan 2015 22:30:01 +0000 (22:30 +0000)]
Bug 10177 - whitespace is a valid password causing pernicious perturbations.
Test plan:
Go to your patron, go to change username and/or password. change
password to whitespace, notice it is accepted, apply this patch,
change password again, to whitespace, notice password is not valid.
Followed test plan. Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Jonathan Druart [Mon, 14 Sep 2015 09:50:12 +0000 (10:50 +0100)]
Bug 14298: Add perms for other languages
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit cf098649a80ee9ee5fe7f505828b0eec56bef93d) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Wed, 2 Sep 2015 15:30:15 +0000 (16:30 +0100)]
Bug 14298: Add warning to the about page if the sco user does not have correct permissions
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Note: Made a little change, changed He should have, to They should have
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit f2663af7d1ead6efd7ccc121492a9f264e08b9fc) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Wed, 2 Sep 2015 15:10:45 +0000 (16:10 +0100)]
Bug 14298: Use the new permission in the sco scripts
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Note without this patch, you won't be able to access the SCO side.
So don't panic if you cant use SCO with just the first patch
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 047f0a486b8db459b0be20e052b9b3cdbf37a584) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Wed, 2 Sep 2015 15:09:35 +0000 (16:09 +0100)]
Bug 14298: Add the new 'self_checkout' permissions
There is a security issue in the self checkout module.
The user used to check items out must have the circulate =>
circulate_remaining_permissions permissions.
So even if a user does not have a login/password or a barcode he cans
access to the circulation module of the intranet.
Imagine if the sco patron used is a superlibrarian...
This patch set will change the behavior and adds a new permission to
access to the sco module (circulate => self_checkout).
This permission should be the only one defined for this patron.
IMPORTANT NOTE: Hopefully, this only works if both interfaces use the
same domains (but different ports).
Test plan:
0/ Does not apply this patch set
1/ Create a patron with the circulate => circulate_remaining_permissions
and some others. Note his userid/pwd (later 'sco/sco').
Turn on WebBasedSelfCheck and AutoSelfCheckAllowed
Fill the AutoSelfCheckID and AutoSelfCheckPass wich 'sco' and 'sco'
2/ Log you out from the OPAC and the intranet
3/ Go on the sco page
4/ Note that your are automatically logged in
5/ Go on the circulation module on the intranet side
6/ Oops
7/ Apply this patch
8/ Execute the updatedatabase
9/ Note that the sco user only has the new permission circulate =>
self_checkout, others have been removed
10/ Try to reproduce the issue, it should not access anything on the
intranet side
11/ Confirm that there is no regression in the sco module
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Works well no regressions, changes the permissions appropriately.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 08c7606c36f4383b402480ddab8a01dfa9acdccf) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
1) Go to home page of staff client and click the Help
2) Notice: 'you should now 'got to' Koha'
'settings found in 'a'dministration.' (should be capitalized)
'Once that user is set you should use that user to log in rather than the root user set up as part of installation.' (could be worded better)
3) Apply patch, close Help, reload page, reopen Help
4) Notice: 'got to' --> 'go to'
'administration' --> 'Administration'
'Once that user is set you should use that user to log in rather than the root user set up as part of installation.'
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit d810fd1094541ee4c95289df3f18bf765047335b) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 14e3841f5104480842eba9848d9bf662647b2413) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Bug 13781: Fix missing heading columns for relative's checkouts table in check out patron page
Theres was two missing heading columns Location and Fines in the Check out section of a Patron
Tested both patches together. Works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit bcb6e9ea39dce065e8c7ff80b4d1b7b49e1735f4) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit b73c432887734ae2bd8de87b0c0d6fec1f6a1d4c) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Variable $itype is used an all C4/Ris.pm to switch
between marc falvors, but is local and not passed along
as argument.
As a quick solution, is defined as global
To test:
1) On UNIMARC setup, export a record as RIS,
check that author (and other fields) are displayed
incorrectly
2) Apply the patch
3) Export again, improved results
4) Run t/Ris.t
There are other problems in this script, needs maintenance
(e.g. no Modern::Perl friendly)
Signed-off-by: Victor do Rosário <jvr@fct.unl.pt> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit e15621fee2693059cce67882691ad8eae9a5c9b7) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 4c7bd247ef456190199f941f5a4479e948341d70) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Kyle M Hall [Tue, 25 Aug 2015 14:35:28 +0000 (10:35 -0400)]
Bug 14640: 'Cancel Hold' check box on check-out confirmation does not cancel the hold when item is checked out.
This bug is dealing with the situation where an item is checked out to a
patron that is not the next in line hold-wise for an item. In this case,
Koha will warn the librarian that there are holds on the item and
show the first person in line. Again, I want to stress that this
is the case where the item *is not waiting* for a patron. The
hold for the patron listed will just have a priority of 1.
The only situation where the "Cancel hold" checkbox will function
is when the priority 1 hold is an item level hold. This is due to
the fact that CancelReserve is being passed the trio of
biblionumber, borrowernumber, and itemnumber rather than the
singular reserve_id.
1) place biblio level hold on a book to borrower A.
2) check out an item of the book to borrower B.
3) When confirming checkout, check the 'Cancel hold' check-box, and
click the "Yes, check out" button.
4) Note the hold was not canceled
5) Apply this patch
6) Repeat steps 1 through 3
7) Note the hold was indeed canceled
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit a37b3bb7f76b5ddea7400f5268c592c0cc578a8c) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit b565d3a62a0ae7980ac58f653182e0e6c0ccf914) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 14 Jul 2015 14:02:42 +0000 (15:02 +0100)]
Bug 10005: Inventory - Add an option to not check in items
The inventory tools automatically check in items, this patch adds it as
an option.
Test plan:
1/ Check an item out, fill a file with its barcode, and use this file in
the inventory tools.
2/ Check the new checkbox and confirm that the item is not checked in
3/ Repeat again and don't check it, the behavior should be the same as before
this patch.
Signed-off-by: Jason Robb <jrobb@sekls.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Added a missing </li>.
Patch works as expected. Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit e5f604378a45d62e8b454cd390abb18b34ef53f8) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 1b03fc78a1ac9f84464752c5f35e0ff54ffbbb14) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Wed, 2 Sep 2015 13:28:52 +0000 (14:28 +0100)]
Bug 7634: Prevent permanent_location to be set to NULL if not defined
The permanent_location is correctly filled when an item is added from
the cataloguing module (routine set_item_default_location from
cataloguing/additem.pl).
But when records are imported, this filled is not managed. It's only on
editing (_do_column_fixes_for_mod called from ModItem).
This patch set the permanent_location item fields to the location value for all
items created, even the imported ones.
Test plan:
0/ Do not apply this patch
1/ Import a record with items using the "Stage MARC for import" tool
2/ Check the values for the permanent_location in the items table.
They are set to NULL
3/ Apply this patch
4/ Repeat 2 and confirm that now the permanent_location values are set
to the location values.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit a2ca59efb877945f7b2ebc92e7643d4cdaf9d4e1) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 3d74a820b23b7b912dea969f88a865bc714be50c) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 14 Jul 2015 10:38:41 +0000 (11:38 +0100)]
Bug 6756: Add info messages
NOTE: Before patch "./misc/cronjobs/batch_anonymise.pl --help" had no
message, and neither did the anonymizing tool in the staff client.
After the patch, both had informative messages.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 1acddd0f1b41e9e5f75b75d9d101c8b0879c00c5) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 715a7bf4f5ff7c05e310a5e98f7cdc177afd3e8f) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 14 Jul 2015 10:30:51 +0000 (11:30 +0100)]
Bug 6756: Fix bad behaviors if AnonymousPatron is not defined
There are at least 2 wrong behaviors if the AnonymousPatron pref is not
defined (0 or empty string).
1/ If you use the clean borrower tools, you will get a successful
message when the nothing happened (the history has not been anonymised).
2/ At the OPAC, if a patron ask for delete his reading history, he will
get an error message "The deletion of your reading history failed,
because there is a problem with the configuration of this feature.
Please help to fix the system by informing your libr ary of this
error". IMO this should not happen, the history should be anonymised.
With this patch, the old_issues.borrowernumber field will be set to NULL
if the AnonymousPatron pref if not defined.
Test plan:
1/ Fill the pref with "" or 0
2/ At the OPAC, go on the privacy tab and click on the "Immedia deletion" button.
You should get a green and friendly message. Confirm that the history
has been anonymised.
3/ Use the "Batch patron anonymization" tools (tools/cleanborrowers.pl)
to anonymize the checkout history.
Confirm that a) it works and b) you get a message.
Try again with AnonymousPatron set to a valid patron. You should not see
any changes with the current behaviors.
NOTE: This patch tweaks C4/Circulation.pm and provides tests.
applying just this, and running prove success. Reverting just
C4/Circulation.pm fails, as expected.
Tested OPAC stuff with both patches applied.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 224b1c7976567511f1d6715784274169e006edcf) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 085272aec0af72e3178f2c6e6ae53f6ea1d48bf1) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Mon, 14 Sep 2015 09:28:01 +0000 (10:28 +0100)]
Bug 14813: Fix encoding issues on editing help pages
It has been introduced by bug 11944.
Test plan:
1/ Install and set the fr-FR language (or ar-Arab).
2/ Go on the help page and edit it.
3/ The textarea should not contain encoding issues with this patch.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit d671b8661cf02d8b039eb5230ab732fd1fde2301) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Conflicts:
edithelp.pl
Jonathan Druart [Fri, 10 Jul 2015 14:18:48 +0000 (15:18 +0100)]
Bug 8723: Update hold_fill_targets, tmp_holdsqueue and linktracker tables
Same as previous patch for 3 other tables.
Test plan:
Same as before but the hold should exist to the 3 tables before the
move.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit c7a6745bc0e0241e5f39a12e2ff4e17678288b14) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 74e6691cf84e51b20832b45cf7520aec85788771) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Fri, 10 Jul 2015 14:04:55 +0000 (15:04 +0100)]
Bug 8723: Update the reserves table for item-level holds
If an item is moved from a biblio to another, the holds should be
updated too.
See discussion on the bug report for more information.
Test plan:
1/ Place a item-level hold on biblio1
2/ Move the item to biblio2
3/ Confirm that the hold still exists and point to the biblio2
This patch should not change the existing behavior for bib-level holds.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 9f8f33e351e1ae5810441a0c9ff7226aafb63c8b) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 0a0f8b09d947aabef21c6cb79e796786ce3be7d5) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Fri, 10 Jul 2015 13:15:42 +0000 (14:15 +0100)]
Bug 8723: Cover the existing behavior
This patch cover the MoveItemFromBiblio subroutine
Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit cb4ce631c316a41ac47a17bfdaa4e5591e0e37df) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 3caa3703c272be52b6cf161a086271ca9be3eb01) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Marc Véron [Sat, 5 Sep 2015 14:41:58 +0000 (16:41 +0200)]
Bug 14782: Add possibility to search patrons using the username (userid)
This patch makes it possible to search for users using the username (userid / login name).
To test:
- Apply patch
- Do searches from Home > Patrons
- Search after a full username or parts of a username with Search fields = Standard and Search fields = Userid
- Perform the searches from the top bar (expand with [+]) and from the "Filters" part at the left
- Make sure that other searches behave as before
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit a71cc14a52589f45bc30dad81b8c7fc0ac35d9fc) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 04319600c32fc3145cfd2457258e97174e4f2cd6) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 18 Aug 2015 17:10:37 +0000 (18:10 +0100)]
Bug 14655: Add a warning if the checkin will fail
On the checkin and checkout page, the checkin will fail if the patron
has requested the privacy and the AnonymousPatron is not correctly set.
This patch adds a warning message on both pages.
Test plan:
0/ Be sure you don't have any patron with privacy=2 (Never)
1/ Set OPACPrivacy, not AnonymousPatron
2/ Go on the checkin, you should a warning (same as before this patch).
3/ Set the privacy=2 for a patron
4/ Go on the circulation page, a warning should appear (for this
specific patron)
5/ Check an item out to this patron
6/ Check the item in on the checkin page.
The item is not checked in and you get a specific message for this
patron.
Confirm other/correct situations don't trigger the messages.
Followed test plan. Works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit cb2151529e0c2d031a01e68bd5deab26d2ffbaff) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 625aec5b8541f8e83fa3bbea473616f90ab1396d) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
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@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit bdf4894c507f4bac6b2b79c7ca3b7a556d246ed5) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit c323e07c0c7ec403af15e40da7d82b997cb3eefc) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Marcel de Rooy [Fri, 28 Aug 2015 07:13:09 +0000 (09:13 +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@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 9b8d7168beb27342c4c483a0812e3a6789fabced) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit bc720464216eca9d5283596af23d2c2c926e7093) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Joonas Kylmälä [Wed, 19 Aug 2015 11:42:50 +0000 (11:42 +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@rijksmuseum.nl>
Adding a follow-up.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 5b1c7e4c359e974e5aca801579db72b356741a0f) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 227d7b950e682300a7697ada4f6837a950f098e6) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
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@catalyst.net.nz> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 46ac35f8e11c06a784ca309b0dc876aff9469edb) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 6c44d1f4645b4c98577d6af23b05b9608b421253) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Kyle M Hall [Mon, 31 Aug 2015 13:36:02 +0000 (09:36 -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@veron.ch> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 73e9dcb70fcf24dc87af7c5af6f38102206863ae) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 9c31f1af9bb7b87dd794f40dd2bc7673b720c674) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 4 Aug 2015 09:38:29 +0000 (10:38 +0100)]
Bug 14470: Do not allow renew for on-site checkouts
At the opac, the renew checkbox should not be displayed if it's an
on-site checkout (same on the intranet).
On the way, this patch adds a specific message to the intranet if the
librarian try to renew an on-site checkout.
Indeed before this patch a renew was allowed if the barcode was scanned.
Test plan:
1/ Create an on-site checkout for a patron
2/ Confirm that the checkbox 'renew' is not displayed on the checkout
list tables
3/ At the OPAC, the renew should not be allowed (no checkbox)
4/ Try to check the item out to the same patron, confirm that you get a
specifig message to inform you the renew is not allowed for on-site
checkouts.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Changed 'issue' to 'item' in the error message. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit ea92a92f5384c3256de55b770d31342f796edc47) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Conflicts:
t/db_dependent/Circulation.t
Jonathan Druart [Wed, 15 Jul 2015 10:50:18 +0000 (11:50 +0100)]
Bug 12525: Prevent adding several patron lists with the same name
If you add patron to a patron list, from the patron search result, a
list is created when you click on "Save".
The list is considered as new each time.
To reproduce:
1/ Launch a patron search
2/ Select 1 patron, and create a new list 'aaa'
3/ Select another patron and click Save again
2 lists are created
Test plan:
1/ Launch a patron search
2/ Select 1 patron, and create a new list 'aaa'
The dropdown list should be populated with this new list, and should be
selected
3/ Select another patron and click Save again
Only 1 list should be created
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 7f65aaac748833b57f9f1c8ae754d66c7e144d81) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit faab5c4c2445b8a3454c17d2ab29fb65b601c0c9) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Right after checking out, a small box appear with "Checkout out: Some Title (32154001669305). Due on 24/09/2015".
The title doesn't appear anymore (since the move to db schemas). This fixes it.
Test:
1) checkout ANY item, for ANY user
2) Look at summary right below the checkout input box. The title doesn't show up.
3) apply patch, reproduce same steps (after checkin if same item). Title appears.
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Todo: You need to track what are the queries generated here. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 658e787834784dec7d7782f45061b66e22211423) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 6648417079eb9aa04d9283e55f3e9f263ef13d64) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Conflicts:
koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt
Fridolin Somers [Tue, 25 Aug 2015 09:33:04 +0000 (11:33 +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@abunchofthings.net> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 64992a05ce87af7bf595c8d6f0b9d528887a2e44) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 3d8e059513db08f2070e33ea1562d7cdd915797c) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Julian Maurice [Fri, 4 Sep 2015 06:57:08 +0000 (08:57 +0200)]
Bug 14766: unimarc_field_4XX: escape ', ", \n, \r
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit abd71d017ea68f4209e41b34282e8fce8170e175) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit c7dfbfedd3d298753b4d96d5ce50363c2cfc65fc) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Add subfields l, n and o for better UNIMARC compliance
Signed-off-by: Chris Cormack <chrisc@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@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 503dd6036974b4208bd5cd60a87bb28599987f45) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 84ee44110a934632ddcc8da59aa805c45a79786e) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 14 Jul 2015 12:12:46 +0000 (13:12 +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@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 5b521eb394771ee305777f0b44098be5fdd11cc7) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 272650cb3f1e2d3ac24559ede0049b263b829762) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 14 Jul 2015 17:07:37 +0000 (18:07 +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@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit bcab2416399e93f5ce9b1083395c052046d5d02a) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 28fe340ea75475903a1063f734dec45781d35f90) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Marcel de Rooy [Wed, 26 Aug 2015 12:09:53 +0000 (14:09 +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@rijksmuseum.nl> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit d1335a766d7b54c470701b0055fc99be2e7e7628) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 74e46b7467aa69e5a77d0b7689ddd2d24d76805d) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 18 Aug 2015 17:40:31 +0000 (18:40 +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@theke.io>
Works as expected.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 813a047e236947a815c4be3c3dde38f19844b962) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 270187404e87bdae985e70a590834ed2dc5d49c7) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Fri, 10 Jul 2015 15:11:48 +0000 (16:11 +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@informaticsglobal.com> Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Warning message is triggered.
Adding, editing and deleting item types still works. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit eb12ee1e223b662cd1e89c0a56a5d1c083ba1ddc) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Mon, 13 Jul 2015 16:34:53 +0000 (17:34 +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@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Much better! Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit f7214859df15abfe874141bcc1a32b57067f7c54) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Srdjan [Thu, 14 Nov 2013 06:10:30 +0000 (19:10 +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@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@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 22b41063981de608402d1dd87f6aa9e2010245dd) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Wed, 19 Aug 2015 15:24:32 +0000 (16:24 +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@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 90285259e898f4734684edf10a64c252a180fdf6) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Fri, 24 Apr 2015 08:02:19 +0000 (10:02 +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@veron.ch> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 1f0ff90360c21e5e24df9f455681b1bf4ae92031) Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Frédérick [Fri, 28 Feb 2014 21:21:46 +0000 (16:21 -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@veron.ch> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Joonas Kylmälä [Wed, 19 Aug 2015 11:00:27 +0000 (11:00 +0000)]
Bug 14579: 'You are not logged in' should link to log in page
To test:
1) Go to any page on the staff client and make sure you are not logged in (ie an error page, cgi-bin/koha/errors/400.pl)
2) Try click on 'You are not logged in |'
3) Notice it is not really a link and doesn't take you anywhere
4) Apply patch
5) Refresh page
6) Click on what now says 'Log in |'
7) Confirm that you are redirected to the intranet log in page
Signed-off-by: Aleisha <aleishaamohia@hotmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Joonas Kylmälä [Tue, 25 Aug 2015 07:24:54 +0000 (07:24 +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@rijksmuseum.nl>
Amended slightly: no need to replace title. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Aleisha [Mon, 3 Aug 2015 02:23:29 +0000 (02:23 +0000)]
Bug 14634: Warns when placing hold on record with no items
To test:
1) Create a new record in Cataloguing
2) When done, instead of adding an item to the record, click on the Holds tab in the left nav
3) Notice warns
4) Apply patch and refresh page
5) Click on Holds tab again
6) Notice warns are gone and page still works
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Warns disappear; note that the display of the error message is still ugly.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Bug 14361: koha-restart-zebra fails and probably breaks upgrade
This patch fixes the koha-restart-zebra and koha-stop-zebra scripts
by adding pidfiles folder to the test is_zebra_running.
It also adds pidfiles to the test is_indexer_running so that
koha-rebuild-zebra will work properly.
Test plan:
1) check if zebrasrv is running, get pid of zebrasrv
ps ax | grep zebrasrv
2) In my case, there was also a warning on the about.pl page on a fresh
install: Error message from Zebra: 1011 (bad credentials)
3) try to restart zebra
koha-restart-zebra instancename
You will get a msg :
Zebra does not appear to have been running for instancename
Starting Zebra server for instancename
4) check again if zebrasrv is running
ps ax | grep zebrasrv
and see that pid has not changed, thus it is not restarted
5) Apply patch
6) repeat 4) and watch now how pid has changed
If there was a warning on about.pl it should now be gone
Signed-off-by: Mason James <mtj@kohaaloha.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Good catch Benjamin! It works as expected with the patch.
Kyle M Hall [Fri, 22 Aug 2014 17:29:28 +0000 (13:29 -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@cineca.it> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Tue, 4 Aug 2015 09:00:51 +0000 (10:00 +0100)]
Bug 14205: Deleting an Item/Record does not remove link to course reserve
A constraint is missing on the course_reserves.ci_id field.
This patch adds it and removes orphan rows.
Test plan:
0/ Don't apply the patch
1/ Login to Staff Site.
2/ Go to Course Reserves
3/ Create Course
4/ Add Reserve
5/ Go to item added (delete item/record)
6/ Refresh Course (see no items attached)
7/ Delete Course
8/ See course still listed in the courses (Not deleted)
9/ Apply the patch and execute the updatedatabase entry.
10/ Delete the Course
Note that the course has correctly been removed.
NOTE: Make sure to set the UseCourseReserves system preference to test.
Tested before (problem existed) and after (problem solved) update.
Dropped DB, web installed, and put in dummy data and retested.
Problem solved.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Galen Charlton [Tue, 4 Aug 2015 15:59:39 +0000 (15:59 +0000)]
Bug 14644: unbreak SIP2 terminal login when using telnet transport
This patch fixes breakage introduced by the patch for bug 13506
that prevented SIP2 clients from authenticating themselves over
the telnet transport. Attempts to do so would manifest by the
SIPServer backend crashing and the connection getting closed.
To test:
[1] Use the stock SIPServer config, etc/SIPconfig.xml, and ensure
that the database contains a staff user whose username is 'term1'
and password is 'term1' that has the circulate permission.
[2] Start SIPServer, telnet to port 8023, and attempt to log in. The
connection will be aborted:
$ telnet localhost 8023
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: term1
password: term1
Connection closed by foreign host.
[3] Apply the patch and restart SIPSever, then repeat step 2. This time,
the login should succeed:
$ telnet localhost 8023
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: term1
password: term1
Login OK. Initiating SIP
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 3ec8b27185f0c8600bc931c5284a5d73d0a42aac) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
To test, apply the patch and navigate to the Patrons home page. Expand
the hidden search fields in the search header and confirm that the
layout looks correct. Perform some searches and check that the results
are correct and that the modified search fields retain their state.
Also please be sure to check the patron import page.
Owen is listed as the author of this, because that's mostly true - I just resolved the conflict for 3.18.x (LR)
Bug 14534: Stop overdue_notices.pl from issuing the warning: Use of uninitialized value $borrowernumber
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
To test:
1/ Run the overdue_notices.pl script (don't do this on production
obviously :))
2/ Notice the warns
3/ Apply patch
4/ Run again
5/ Notice no warns, but notices are still generated ok
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit d873ed3b5d97f825c52dc53c2f72bd5a1ef03647) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Alex Arnaud [Thu, 11 Jun 2015 08:55:35 +0000 (10:55 +0200)]
Bug 13663: Fix permissions in upload-file.pl and upload-file-progress.pl
Test plan:
Verify that the circulate_remaining_permissions perm is enough to upload
.koc file.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 2fcc02321f0f56760cfdbd67a29917e4f0ba278b) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Bug 10961: (followup) Make query fields explicit and add regression tests
add correct frameworkcode to _koha_marc_update_bib_ids parameters
add test, prove with : prove t/db_dependent/Biblio.t
TEST PLAN
---------
1) git checkout -b bug_10961 origin/master
2) git bz apply 10961
3) git checkout origin/master -- C4/Biblio.pm
4) prove t/db_dependent/Biblio.t
-- was expecting failure, got failure.
5) git reset --hard origin/master
6) git bz apply 10961
7) prove t/db_dependent/Biblio.t
-- success as expected.
8) Read over code.
-- Noted it also grabs the framework code for the biblio, rather than uses default.
And it also corrects an indentation issue.
Test case looks like it attempts to cover the biblionumber!=biblioitemnumber case
by adding 1.
9) run koha qa test tools.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 62dc6b0ca15a9de99a1cb41809e6c9c016e6b0d0) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Kyle M Hall [Fri, 27 Sep 2013 16:53:39 +0000 (12:53 -0400)]
Bug 10961: Error in GetMarcBiblio can cause severe data loss
A bug in GetMarcBiblio can cause severe data loss if your database has
records where the biblionumber and biblioitemnumber do not match and the
script misc/batchRebuildBiblioTables.pl is run.
The Biblio::GetMarcBiblio makes a kall to
C4::Biblio::_koha_marc_update_bib_ids which passes the biblionumber as
both the biblionumber *and the biblioitemnumber*.
Thus, if your biblio and biblioitem numbers are not always equal, you
will end up with a record where the biblioitemnumber is incorrect in the
record!
This is usually not a severe issue, but since batchRebuildBiblioTables
uses that record to update the database tables, it ends up updating the
wrong biblioitem row!
NOTE: What a horrible, horrible typo that was. Tested this with the
second patch.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 298c4c76a5f231d9cc0935b6f14a5f191b727804) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Mark Tompsett [Fri, 3 Jul 2015 22:04:04 +0000 (18:04 -0400)]
Bug 14487: Noise best detected under Debian 8
The first error is caused by the fact that
$messages->{'IsPermanent'} is undefined.
The second error is caused by querying the CGI
parameter 'barcode' inside a function call. This is not required.
There is a variable $barcode set with the parameter. Changed to
use the variable.
TEST PLAN
----------
1) Test first patch.
2) Clear the log
3) Put in a barcode which is not checked out.
4) Check the log.
-- should be two errors. One about a hash,
the other will only be detectable under Debian 8.
5) Apply this second patch
6) Clear the log
7) Put in a barcode which is not checked out.
8) Check the log.
-- should be empty.
9) run koha qa test tools
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com> Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit beef8534724900e5777fc7b6d163763712decb1f) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
1/ check out an item and then check it back in.
1/ check the logs after the check-in to see the warns from
returns.pl line 623 of :
(a) Use of uninitialized value $holdingBranch
(b) Use of uninitialized value $collectionBranch
2/ apply patch
3/ check out and check-in again. no warns are recorded this time.
NOTE: Under Debian Jessie, there are other messages.
Additionally, this only corrects the line 623 ones.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 0d632a606f499c31afb8a08f81625c4dfbddb445) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
mxbeaulieu [Mon, 15 Jun 2015 15:05:51 +0000 (11:05 -0400)]
Bug 14387: Merge reference selection has no effect when merging authorities.
This patch swaps the authority records according to the refenrece record selection.
To TEST:
Merge two authority records, select the second as merge reference.
The reference authority is always the first.
Apply the patch.
Repeat previous steps, the authority is now merged using the selected reference record.
modified: authorities/merge.pl
Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit ee7666a5fdd1b04f1bf50aa89900488e1a01402b) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Bug 11693: Default emailing preferences not loaded for self registering patron
The call to AddMember_Opac does not take care of the messaging prefs
when enhanced messaging is enabled.
This patch adds the call to handle_form_action to do that.
Test plan:
Enable self registering patrons and enhanced messaging.
Check the (default) message prefs for the relevant patron category. At least
enable email for one notice.
Self-register a user with and without verification email enabled.
Check in both cases that the message prefs of the user conform to
those in the patron category. (So at least one enabled.)
Followed test plan, works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit f7ed250d618c57a3fc00728bbb93460b25ceda52) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jacek Ablewicz [Wed, 24 Jun 2015 17:43:05 +0000 (19:43 +0200)]
Bug 14456: EmbedSeeFromHeadings record filter shouldn't process MARC holding fields
If the system preference IncludeSeeFromInSearches is enabled, records
exported for zebra indexing are being additionally processed by
EmbedSeeFromHeadings record filter (right now used only in rebuild_zebra.pl
script). This filter embeds 'see from' fields (extracted from authority
records linked with the given biblio via $9 subfields) into target MARC
record, which is then subsequently indexed in zebra.
Currently all fields containing $9 are getting the same exact treatment
by this filter. But on the export stage when the filter is applied, MARC
record being processed already does have holdings data fields added in
the previous stage (usually 952 / 995, depending on the MARC format).
Problem is that holdings data fields use to have $9 subfields in them
as well (mapped to item.itemnumber by default). As a consequence, some
(great many in the typical setup) records exported for zebra indexing
may have surplus "see from" fields added erroneously in semi-random
fashion, so biblio searches would often return some completely
unexpected additional results.
EmbedSeeFromHeadings record filter should not process holdings fields
when dealing with MARC records intended for zebra indexing.
To reproduce:
1) database with as many sample or real-world biblio, item and authority
records as possible is recommended for testing purposes
2) enable IncludeSeeFromInSearches
3) export a bunch of biblio records for zebra (e.g.:
misc/migration_tools/rebuild_zebra.pl -I -b -x -k -length=1000),
inspect the result xml records in /tmp/<whatever> file; observe that at
the end of many records, here and there some extra "see from" (= 1st
indicator: 'z') fields tend to appear, which shouldn't be there ;)
To test:
4) apply patch
5) redo 3)
6) compare results from 3) and 5) with diff
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I introduced a regression test for this. You should run the tests
without/with the patch and verify that the patch actually fixes the problem.
Good job Jacek! I'm sure writing the regression test would take less time
than such a detailed commit message!
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit f3a8b7a0e1e1bf112628c6215105ab80f25ed94f) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Test plan:
Run git grep -E "borroewr|borow". You should not find anything now.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Typos in comments corrected.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 7d4e7e4e525fc99cb4452de135e161a0e0866753) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Thu, 9 Jul 2015 09:31:07 +0000 (10:31 +0100)]
Bug 14404: Rename class no-show to noshow for consistency with nosort
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 0183cc0223678f6b3f0885213c7223ddb31acf5d) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Kyle M Hall [Tue, 16 Jun 2015 23:05:10 +0000 (19:05 -0400)]
Bug 14404: Checkouts default sort order for Self Checkout (SCO) confusing for patrons
Libraries are reporting that patrons are very confused during
self-checkout. The problem is they are expecting the list of checkouts
to be in the order they checked out the items ( first checkout on the
bottom, last item checked out on top ). However, the checkouts
table is sorted by title ( ascending ) then due date ( descending ).
This is not intuitive.
Test Plan:
1) Enable Koha's self checkout
2) Use the SCO to check out a random assortment of items,
make sure you don't check them out in alphabetical order
3) Note the order of the items in the list is not based on the order
you checked them out in
4) Apply this patch
5) Refresh the page
6) Note the items are now in the order you checked them out
with the last on top and the first on bottom
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit e9061028c1ba95b310be5e9333b224e735e64f40) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
When creating a new notice, warn is triggered "Argument "" isn't numeric in numeric gt (>) at line 400". Same warn is triggered when changing Koha module option to any other module.
To test:
1) Go to Tools, then Notices & Slips
2) Click 'new notice'. Notice warn in intranet-error.log
3) Change Koha module to another module. Notice warn is triggered for every change
4) Apply patch and reload page
5) Change Koha module to another module. Notice there are no longer warns
6) Go back to Notices & Slips and click 'new notice' again. Notice there are no warns
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 7098a36b19c35a06a51361bd381416a1204de38d) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Aleisha [Wed, 24 Jun 2015 01:15:32 +0000 (01:15 +0000)]
Bug 14445: Silences warn in letter.pl
When changing Koha module to 'Circulation', there is a warn saying that $code is uninitialized. This patch sets $code to an empty string to silence the warn.
To test:
1) Go to Tools, the Notices & Slips
2) Click 'new notice' (This will trigger warns, but ignore these as they will be corrected in the next patch)
3) Change Koha module to 'Circulation'
4) Notice warn about uninitialized $code variable
5) Apply patch and reload page, change Koha module to 'Circulation'
6) Notice page still works and warns are gone
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit fe3a49e61133e1e66d0075f3300cd3a99e691890) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Sun, 24 May 2015 16:00:57 +0000 (18:00 +0200)]
Bug 14263: Fix export of item search results when translated
This csv does not use the correct way to display headers.
They should be put in a separate file to get a correct display.
Without this patch, the first line of the generated file contains the
headers + data
Test plan:
1/ choose a language and update + translate the templates
for instance:
cd misc/translate;
./translate update es-ES; ./translate install es-ES
2/ Go to the item search form using this language
3/ Launch a search and select CSV to display the results.
The CSV headers should be correct
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Seen the bug. Works as described.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit ece2b02a57fdb692c02f00540df436af1f5ba971) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Bug 14494: Terribly slow checkout caused by DateTime->new in far future
An expiry date like 9999-12-31 in the local timezone will make DateTime
spend a lot of time (maybe 60 seconds) on date calculation. See the
DateTime documention on CPAN.
A calculation in floating (or alternatively in UTC) would only take
a few milliseconds.
This patch makes two changes in this regard:
[1] The compare between expiry date and today in CanBookBeIssued has been
adjusted in Jonathan's patch. I am moving the compare to the floating
timezone (as was done in my original patch). This removes a hardcoded
9999.
[2] If ReturnBeforeExpiry is enabled, CalcDateDue compares the normal due
date with the expiry date. The comparison is now done in the floating
timezone. If the expiry date is before the due date, it is
returned in the user context's timezone.
NOTE: The calls to set_time_zone moving to or from floating do not adjust
the local time.
TEST PLAN:
First without this patch (and the one from Jonathan):
[1] Set expiry date to 9999-12-31 for a patron.
[2] Enable ReturnBeforeExpiry.
[3] Checkout a book to this patron. This will be (very) slow.
Continue now with this patch applied:
[4] Check in the same book.
[5] Check it out again. Should be much faster.
Bonus test:
[6] Set borrower expiry date to today. Change relevant circulation rule
to loan period of 21 hours. Test checking out with a manual due date
/time just before today 23:59 and after that. In the second case the
due date/time should become today 23:59 (note that 23:59 is not
shown on the checkout form).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 17d04c46190880d3031adbc02553f82234d70fc1) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Jonathan Druart [Thu, 9 Jul 2015 08:52:28 +0000 (09:52 +0100)]
Bug 14494: Prevent slow checkout if the patron does not have an expiry date
If a patron has a expiry date set to 9999-12-31 (for organizations for
instance), the checkouts are very slow.
It's caused by 2 different calls to DateTime in CanBookBeIssued:
1/
DateTime->new( year => 9999, month => 12, day => 31, time_zone => C4::Context->tz );
The time_zone should not be set (as it's done in Koha::DateUtils), set to UTC or floating tz.
2/
DateTime->compare($today, $expiry_dt)
The comparaison of 2 DT with 1 related to 9999 is very slow, as you can
imagine.
For 1/ we need to call Koha::DateUtils::dt_from_string (actually, we
should never call DateTime directly).
For 2/ we just need to test if the date is != 9999, no need to compare
it in this case.
Test plan:
Before this patch, confirm that the checkouts are slow if the patron has a
dateexpiry set to 9999-12-31.
update borrowers set dateexpiry="9999-12-31" where borrowernumber=42;
After this patch, you should not see any regression when checking out
items to an expired patron and to a valid patron.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 8d58acc565c8500d4b9d55cacb3d6d21628a899b) Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
projects / koha.git / log