Test plan:
Run t/db_dependent/Virtualshelves.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This 'bug' existed long enough now to finally remove it ;)
We do so by deleting the invitation if the borrower already has a share
on this list. Actually not that hard.
We still need: a unit test and a db revision.
Test plan:
[1] Share a list. Let user B accept.
[2] Without this patch: Share again and let B accept again.
[3] Verify that you have two shares for this list in virtualshelfshares.
[4] With this patch: Share another list, let B accept.
[5] Share this other list again, let B accept again.
[6] Verify that virtualshelfshares does not contain double entries now.
(Note: This pertains to the second list only.)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should check the invitekey in show_accept by passing it along in the
search call.
On the way I fixed some error checking: if the list number is invalid, or
the list is public or you are the owner, or if the key is not found, we
should set the right error code; the template contains those messages.
Test plan:
[1] Share a list and accept a correct invitation with another user.
[2] Try to accept some invalid proposals: wrong key, wrong list.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested invalid key, wrong list, owner, public list, expiry.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch gets all the shares for a list and iterates through to find
the correct one when accepting from a link
To test:
1 - Create a private list in the opac
2 - Invite 2 patrons to the list
3 - Try to accept from the patron you first shared to
4 - You will get a failure message about expiration of the link
5 - Apply patch
6 - Now try to accept the first share
7 - It works! Success!
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The aqorders.subscriptionid info is not sent to the template when the
order is edited. Which means we lose this link.
Test plan:
Create an order from a subscription
Edit the order
=> Without this patch, the aqorders.subscriptionid value is set to NULL
and items are created when receiving serial.
=> With this patch applied the link is preserved and expected behaviors
are preserved during all the acquisition workflow
You should also try and create several orders from the same subscription
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When marking a request as complete, the status is updated internally
then the user to redirected to the view of the request.
Although the redirect header is sent, there is no exit to indicate that
the program flow should stop. As a result, an attempt is made to render
the template, which fails.
This patch simply adds the missing exit.
TEST PLAN
---------
- Create an ILL request
- "Manage request" > "Confirm request"
- "Mark completed"
- TEST: Ensure that no error is written to the error log upon clicking
"Mark completed"
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We do not need to pass all those parameters, just the checkout object is
enough.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Apply this patch
2) Assign a charge to an item type
3) Checkout an item of that type to a patron
4) View the accountlines table for that patron
SELECT * FROM accountlines WHERE accounttype='Rent' and borrowernumber=##;
5) Note there is an issue_id
Or
1) Apply this patch
2) prove t/db_dependent/Circulation/issue.t
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Moving the status to the invalid 'processing' might well have unwanted
side-effects. (The status column will be set to empty string and we have
a problem if it is not processed.)
This patch allows pass-through of DBIX's make_column_dirty in
Koha::Object (simple tests included) and uses it to force an update.
If the update does not return true, it still exits.
Test plan:
[1] Read the changes.
[2] Run t/db_dependent/Koha/Object.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Conflicts:
Koha/Object.pm
Last week, we had a database server whose disk filled, causing database writes to fail.
This meant that messages in message_queue marked 'pending' were not marked as 'sent' when they were added to the postfix mail queue; messages were sent every 15 minutes (as specified in the cron job) until the disk space issues were cleared.
I would suggest adding a token write to the start of process_message_queue.pl as a 'canary in the coal mine'. If the database write fails, process_message_queue should stop, because it's not safe to proceed sending emails that may not be marked 'sent'.
Test Plan:
1) Apply this patch
2) Make the message_queue table unwriteable somehow
3) Run process_message_queue.pl
4) Script should die with error
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Trivial and hypothetical fix.
If you create /root/AA B (space in dirname), the quotes added here will
help you to get back where you came from.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes koha-plack jump into the instance's home directory to
run.
It is required because Perl 5.18 introduced a breaking change that
makes perl die if @INC includes directories for which the user doesn't
have read permission, and need to be traversed when querying for a lib.
This is the case of '.', which is introduced automatically into @INC
until Perl 5.26 (which removes the 'feature').
The Mojolicious::Plugins lib prefixes the plugin names with
'Mojolicious::Plugin' so it first looks (for example) for
Mojolicious::Plugin::Koha::REST::Plugin::Pagination (Pagination is just
the first one on the list). When it looks for it at '.' it dies (because
of Perl's behaviour) so it doesn't query for the right namespace (the
following to try).
I only reproduced it in koha-testing-docker. To test, you just need to
try this patched koha-plack and make sure it doesn't break due to this
permissions issue.
To test:
- In your koha-testing-docker clone, run:
$ docker-compose up -p test
- Open a shell inside the container (on a separate terminal):
$ docker exec -it test_koha_1 bash
- From within the /root directory, restart plack:
$ cd /root
$ koha-plack --restart kohadev
=> FAIL: Logs show plack is broken due to permissions problems trying to
find Mojolicious::Plugin::Koha::REST::Plugin::Pagination
- Use the patched script from this patch:
$ /kohadevbox/koha/debian/scripts/koha-plack --restart kohadev
=> SUCCESS: Plack runs fine, no error in the logs
- Sign off :-D
Note: people who has environments in which the problems is reproducible,
please test this version of koha-plack and stamp your sign-off,
PLEASE.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
If items.restricted == 1, CanBookBeIssued will not returned what we are
testing.
The easiest and global fix is to define a default value at TestBuilder
package level
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
A new bug has been highlighted since:
commit b830349f45
Bug 19453: Incorrect jQuery selector for fund drop down validation
Prior to bug 19453 the check on the existence of the fund did not work
as expected, no select with name='budget_code' existed and the error was
never raised.
Now it works but expect a fund to be selected for every record to
import.
This check must only be done if there is no default value selected.
Test plan:
- Create an order from a staged file
- Do not select any funds
=> You must get a warning
- Select a specific fund for some of the records
=> You must get a warning
- Select a default fund in the last tab
=> You must not get a warning and the records must be imported and
inserted with the correct fund
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Conflicts:
koha-tmpl/intranet-tmpl/prog/en/modules/acqui/addorderiso2709.tt
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
* koha/opac-illrequest.pl - Added explicit setting of authnotrequired
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The tags for home library and holding library in the 'refine your
search' list should be h5.
This patch changes the html tag for the availability, holding library and home library
facets.
To test:
- Search for an item in the OPAC where the relevant facet appears
- Use 'Inspect element' to check the tag
- Apply patch
- Confirm the facet now has the h5 tag
- Confirm spacing is improved
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
No idea why I missed pl-PL!
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Stolen from bug 20244
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes a few changes to the tests to take into account the
change to indexing.
To test:
prove t/db_dependent/Koha_Elasticsearch_Indexer.t
Should return green
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This option in combination with append seems to add null entries in the indexes
for fields that don't exist. These fields then affect sorting. Removing it solves
the issue
To test:
1 - Have an ES setup
2 - Catalog and index some records
3 - View a record in ES:
curl 'localhost:9200/koha_kohadev_biblios/data/4?pretty=yes'
4 - Note there are 'null' entries in the indexes, save this result for
comparison
5 - Apply patch
6 - Reindex, amking sure to delete existing indexes
perl misc/search_tools/rebuild_elastic_search.pl -d
7 - View the record again
8 - Note the null entries are removed
9 - Note indices are otherwise intact
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This is caused by bib_list not being deleted.
The path was not explicitly set.
This patch adds path=/ explicitly to ensure it
does get deleted.
TEST PLAN
---------
1) search for 'the' in OPAC
2) add several items to cart.
3) look at your cart.
4) empty and close the cart, select all->remove
-- either way window closes and it looks empty.
5) refresh the page
-- cart comes back.
-- in chromium inspecting the page, specifically
the "Application" area, bib_list is shown as
a cookie still.
6) apply patch
7) restart_all and empty cache forcing JS reload
8) repeat steps 1-5
-- this time cart stays empty.
-- and the bib_list cookie is gone
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com> using firefox 59.0.2
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is part of the tests, to make sure they have not been deleted
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Conflicts:
t/db_dependent/Accounts.t
purge_zero_balance_fees is used in cleanup_database.pl to determine which fees can be cleaned up.
It uses a simple SQL query to determine which rows in accountlines need to be removed:
463 my $sth = $dbh->prepare(
464 q{
465 DELETE FROM accountlines
466 WHERE date < date_sub(curdate(), INTERVAL ? DAY)
467 AND ( amountoutstanding = 0 or amountoutstanding IS NULL );
468 }
The function comes with the following warning:
451 B<Warning:> Because fines and payments are not linked in accountlines, it is
452 possible for a fine to be deleted without the accompanying payment,
453 or vise versa. This won't affect the account balance, but might be
454 confusing to staff.
This was a reasonable solution prior to the addition of account_offsets in 17.11. The problem now is that rows in accountlines which are linked as credits in accountlines will *always* have amountoutstanding marked as 0. These are linked to debits via account_offsets. purge_zero_balance_fees will delete credits and leave rows in account_offsets which link to deleted credits.
Sites using the --fees option cleanup_database.pl which upgrade to 17.11 may have all of their credits removed without warning.
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Conflicts:
t/db_dependent/Accounts.t
To test:
1 - Open the advanced editor
2 - Make some changes to a record
3 - Click on 'Patrons' or leave the page in some way
4 - Note there is no warning and changes are not saved
5 - Apply patch
6 - Open the advanced editor
7 - Make some changes
8 - Leave the page
9 - Note you get a warning of unsaved changes and can stay on the page
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In acqui/parcel.pl both the "Pending orders" and "Already received" tables show how many holds there are for the given record. However, the count of holds in the "Pending orders" table confuses librarians because it only lists holds for the particular items in the orderline. Due to that, the holds column may show 0 holds even if there are a dozen record level holds for that bib! This is not what librarians seem to expect, instead it seems that the same total holds in the "Pending orders" table would be preferred.
Test Plan:
1) Find an invoice with an item in the "Already received" table
2) Add one or more record level holds to the record
3) Note the holds column does not count those holds
4) Apply this patch
5) Note the holds column now shows total holds and holds for just those ordered items
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nancy Keener <nkeener@washoecounty.us>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 19812: (QA follow-up) Swap sides for total and item holds
Bug 19812: (QA follow-up) If 0 holds show '0' not '0 / 0'
Bug 19812: (QA follow-up) Remove unnecessary line
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Set delimiter syspref to anything but comma
2 - Download report results as comma separated text
3 - They actually follow the syspref
4 - Apply patch
5 - Download link should now match pref selection
6 - Change pref, note link changes
7 - Verify things still work as expected
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset <victor.grousset@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jenkins fails (run 287) on a test in t/db_dependent/Letters/TemplateToolkit.t:
With the historical syntax:
# Your request for an article from tQYRS (c3Av58O0P5xkkIGu) has been canceled for the following reason:
With the TT syntax:
# Your request for an article from tQYRS_ (c3Av58O0P5xkkIGu) has been canceled for the following reason:
The last character of the biblio's title has been removed because it's a punctuation character.
It comes from: C4::Letters::_parseletter
893 $val =~ s/\p{P}$// if $val && $table=~/biblio/;
The same replacement is done for patron's attributes too.
Test plan:
- Confirm that the new tests pass. That should be enough to confirm this change make sense.
Test plan (manual):
- Create a biblio with a title ending with a punctuation (like "with_punctuation_"), or any other fields of biblio/biblioitem
- Generate a notice which will display this field (CHECKIN for instance)
Use the historical syntax and the TT syntax, both should display the title without the punctuation character at the end
CHECKIN historical:
The following items have been checked in:
----
<<biblio.title>>
----
CHECKIN TT syntax:
The following items have been checked in:
----
[% biblio.title %]
----
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch introduces two methods to be used by plugin authors:
->output
->output_html
They are basically wrappers for the helper methods from C4::Output
(output_html_with_http_headers and output_with_http_headers).
Plugin authors can use them, or keep the current flexibility of handling
the headers themselves in their code.
The KitchenSink plugin should be updated to highlight this.
To test:
- Run:
$ kshell
k$ prove t/db_dependent/Plugins.t
=> FAIL: The methods are not implemented
- Apply this patch
- Run:
k$ prove t/db_dependent/Plugins.t
=> SUCCESS: Tests pass, and they are meaningful
- Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch replaces one more instance of [% IF ( numbersphr ) %].
To test, apply the patch and view the source of the OPAC home page.
With the OPACNumbersPreferPhrase system preference set to 'use,' you
should find this in the HTML source:
<option value="callnum,phr">Call number</option>
With the preference set to 'don't use,' you should find this:
<option value="callnum">Call number</option>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Case
1) Check that the following files have been changed properly.
opac/opac-search.pl
opac/opac-main.pl
koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-advsearch.tt
2)Apply bug
3) Check that there are no differences in behaviour as a result of the patch.
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Add a course (Course Reserves)
2 - Add an item to the course
3 - Ensure to change the holding branch for the course reserve
4 - Modify the course item
5 - Note the dropdwn for holding branch is unset
6 - Apply patch
7 - Modify the course item
8 - Dropdown should be correctly populated
Signed-off-by: Maksim Sen <maksim.sen@inlibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Enable EasyAnalytics
2) Disable QueryAutoTruncate
3) Create an analytic record, add some host items to it
4) Browser to the analytics tab for the record
5) Click the link in the 'used in' column of the table
6) No search results
7) Apply this patch
8) Reload the page, now you get the analytic record!
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
0) Confirm that email validation is not working in add/edit patron form
1) Apply the patch
2) Edit/add patron, the e-mail validation should be working now
3) Ensure the password validation is still working (use test plan from
bug 19908)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Conflicts:
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt
This has been done on bug 9509 when barcodes are scaned, but not when using a text file.
Test plan (stolen from Barton on the bug report):
1) Create a text file containing duplicate barcodes
Here's a quick way to do that, substitute INSTANCE for the instance name of your test server:
sudo koha-mysql INSTANCE <<< "select barcode from items where barcode is not null limit 3" | sed '1d;p' > /tmp/dup_barcodes.txt
2) Go to Home › Tools › Batch item deletion
3) Click 'Choose File', select the file you created in step 1.
4) Click 'Continue'
5) Note that duplicate items appear in the list of items to batch delete
6) Check 'Delete records if no items remain'
7) This will trigger a software error
Note that entering the barcodes via the 'scan items one by one' text box removes duplicates in the list, so this only causes problems when uploading a file.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When you want to merge invoices you have a page with a non editable
field 'Invoice number:' it shows the content of the first invoice to be
merged.
But if you validate by clicking the 'merge' button you arrive on the
next page which says that 'Invoice has been modified' and if you quit
this page without saving you have now a merged invoice without Invoice
number.
This tiny patch just prevents this issue to occur.
Test plan :
1° go to the acqui/invoices.pl page and search invoices to merge.
You must have at least 2 invoices on the same vendor
2° check boxes to select invoices to merge and click on 'merge selected
invoices' button
3° next page you see the non editable field 'Invoice number:'
4° click on the 'merge' button
5° next page you see 'Invoice has been modified'
6° leave this page i.e click on the left link 'Invoices'
7° search invoices you'll see the merged invoice without invoice number.
Apply the patch, replay the steps 1 to 3
4° on this page you can enter your invoice number and click on the
'merge' button.
If you leave this field empty and click merge, a message informs you
that it is required and you can not merge.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Conflicts:
koha-tmpl/intranet-tmpl/prog/en/modules/acqui/invoices.tt
We lost the ability to place multiple holds when we are searching for
patrons. The multi_holds parameter is lost and not handled correctly in
the template.
Test plan:
- Make sure you can place multiple holds for a patron you will search for
- Same for simple hold
TODO the multiple holds view should not be displayed if only 1 record
has been selected from the search result.
Signed-off-by: claude brayer <claude.brayer@cea.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TO test:
0 - Have a koha with ES enabled and some auth records
1 - backup your db
2 - sudo koha-mysql <<instance>>
3 - UPDATE auth_types SET authtypecode="PERSO_NAMB" WHERE
authtypecode="PERSO_NAME" (or adjust as necessary)
4 - Search for some authorities where a PERSO_NAME record will be
returned
5 - KA_BOOM!
6 - Apply patch
7 - Results are returned, they do not display a code, viewing record you
won't see code
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
category_type must be != "X"
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Conflicts:
t/db_dependent/Patron/Borrower_PrevCheckout.t
Marcel de Rooy
Nick Clemens
Jonathan Druart
Andrew Isherwood
Kyle M Hall
Tomas Cohen Arazi
Martin Renvoize
Claire Gravely
Mark Tompsett
Kyle M Hall
Jesse Weaver
Tomas Cohen Arazi
Owen Leonard
Charlotte Cordwell
Josef Moravec
Christophe Croullebois