The code from scripts and subroutines using this subroutine was not very
elegant. Most of the time the code was unnecessarily complex.
This patch removes this subroutine and adapt the code to use
Koha::Items instead.
1. C4::Items::get_hostitemnumbers_of
I did not understand why the code was so complicated, it seems that we
only want to know if a given item has a given biblionumber
2. cataloguing/merge.pl
We want to retrieve the itemnumber for a given biblio.
We could also have done that with:
Koha::Biblios->find( $biblionumber )->items;
3. labels/label-item-search.pl
We want to loop over the items for a given biblio, no need to use
get_itemnumbers_of and GetItemInfosOf.
We just need to use:
Koha::Items->search({ biblionumber => $biblionumber })
4. reserve/request.pl
We want to retrieve the itemnumbers of the biblio's items
We could also have done that with:
Koha::Biblios->find( $biblionumber )->items->get_column('itemnumber');
Test plan:
1.You need to create analytical record relationships (
EasyAnalyticalRecords needs to be set). Link an item to a biblio using
the 'Edit > Link to host item' menu from the biblio detail page.
From the staff interface place a hold on the biblio. You should see the
items from the biblio and the one you just linked
2. Merge two bibliographic records (with items), the resulting record
should contain items from both original records
3. Create a new label batch, edit it.
Add items to this batch ('Add items' button).
Fill the input with a barcode.
You should see all the items of a biblio.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This subroutine is no longer in used.
It was previously call from serials/serials-recieve.pl, which was not used and has been removed by
commit 65b7ad030c
Bug 13423: Remove unused serials-recieve
Test plan:
git grep GetItemLocation
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Save a csv of biblionumber from MS/Excel
2 - Attempt to export records using this file
3 - It fails (mimetype is appliction/vnd.ms-excel)
4 - Apply patch
5 - Try again
6 - It succeeds!
Signed-off-by: Jason Palmer <jpalmer@switchinc.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Load http://localhost:8081/cgi-bin/koha/acqui/booksellers.pl?booksellerid=1
2 - Should get internal server erro
3 - Apply patch
4 - Reload
5 - Should not get error
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch updates the existing occurrences of ->find called in a list
context.
There are certainly others that are not easy to catch with git grep.
Test plan:
Confirm that the 4 modified scripts still works as expected.
We need this one ASAP in master to make sure we will not get other
side-effects of this kind and to catch possible uncaught occurrences
before the release.
Tested scripts changed by this patch, they work as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comparing the perldoc to the function:
- basketname
- basketgroupname
- budget_id
Were missing. This adds them.
Also, a description of ordernumber and search were
added, as they are not self-evident by their name
alone.
There are no code changes, so all tests should pass
or fail identically before and after patch.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Fixed typo basetgroupname
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
One of the RewriteCond directives in koha-httpd.conf was affecting
the wrong RewriteRule after its original RewriteRule was commented out
years ago.
_TEST PLAN_
0) Before applying patch, build Koha from source
*) make
*) make install (or make upgrade)
*) Copy or symlink etc/koha-httpd.conf to your Apache vhost directory
(and enable if you're on a Debian based system)
*) Restart Apache
1) Make sure that you have at least 1 bibliographic record in Koha
(URL like this http://server:port/cgi-bin/koha/opac-detail.pl?biblionumber=1)
2) Go to http://server:port/bib/1
3) Note that you get a 404 error
4) Apply the patch
5) Rebuild Koha from source as per step 0
6) Go to http://server:port/bib/1
7) Note that you now see the same page as you would if you went to
http://server:port/cgi-bin/koha/opac-detail.pl?biblionumber=1
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Problem raised by bug 17762: IssueSlip should return if the params are
not valid.
The tests contain 2 FIXME to highlight this problem already, it's time
to fix them.
Note that, theoretically, this change may produce software error. Indeed
the caller expecting a hashref (letter) will access the "content" key.
But that should not happen.
Test plan:
Tests must return green
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Once again, after bug 16154 and bug 16259 we need to remove more
occurrence of CGi->param called in list context.
Refer to bug 15809 for more information.
Test plan:
Make sure you do not see the error on the modified scripts.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
Run t/db_dependent/ImportBatch.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Make it more explicit by adding join statements.
Test plan:
See next patch for adding a unit test.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Import a batch with some items
2 - Delete one of the imported items
3 - Browse to Tools->Staged MARC record management
4 - Click (Create label batch) for the batch you imported
5 - Recieve an error
6 - Apply patch
7 - Click (Create label batch)
8 - Batch is created with remaning items from the import
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The new subtest in Reserves.t does not need its own transaction.
Move the original rollback to the very end of the test.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
https://bugs.koha-community.org/show_bug.cgi?id=18478
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Make sure to build necessary letters
Fix awkward construction
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This method was not previously covered, we don't change it , but
no reason to throw away these tests to ensure messages are created
as expected
To test:
1 - Apply this patch first
2 - Prove t/db_dependent/Reserves.t
3 - Last tests fail
4 - Apply other patch
5 - All tests should pass
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
It seems that for HOLD and DUE (and maybe more) notices we rely on
C4::Letters::SendQueuedMessages
to populate the correct address.
This patch adjust that subroutine to correctly populate the field and/or
fail messages if no SMS provider available
To test:
1 - Define a messaging prefs for a patron to recieve hold notices via
SMS
2 - Ensure you have defined an SMS message for 'HOLD' letter
3 - Set an SMS alert number for patron
4 - Set the SMS::Send driver to 'Email'
5 - Fill a hold for the patron
6 - Check the db and note the address is null
7 - run process_message_queue.pl
8 - Check db - address is null and message pending
9 - Apply patch
10 - run process_message_queue
11 - Message to_address should be populated and message sent
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Set SMSSenDriver to 'Email'
2 - prove t/db_dependent/Letters.t
3 - Tests fail
4 - Apply patch
5 - prove t/db_dependent/Letters.t
6 - Less tests fail (should be 2 sms test failures)
7 - Set SMSSendDriver to another value or blank
8 - prove t/db_dependent/Letters.t
9 - Tests pass
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When you search an authority in Authority search, this search is not saved in Search history.
EnableOpacSearchHistory is enabled
Steps to test:
1- Login your account (opac)
2- Search an authority in Authority search
3- Go to Search history -> Authority
4- It says "Your authority search history is empty"
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
There was a typo in the permission code
Test plan:
Try to access the marc modification templates admin page with the
marc_modification_templates permission (and not all tools permissions)
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Sounds like it is caused by bug 13726.
It is not possible to delete a currency, even if not used by any vendors
Test plan:
Try and delete currencies used or not by vendors.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
1. Run: debian/scripts/koha-create --request-db
-> Without patch you see the getent error message
-> With patch you see usage and "Missing instance name" message
Signed-off-by: Dilan Johnpulle <dilan@calyx.net.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Followed test plan and the city value updates in the quick add form correctly.
Signed-off-by: Dilan Johnpulle <dilan@calyx.net.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Fill out some fields in quick add
2 - Switch to full form and clear fields
3 - Switch back and fields are still populated
4 - Fill a field in long form
5 - Switch to quick add and clear it
6 - Save
7 - Value set in 4 is saved
8 - Apply patch
9 - Repeat 1-6 - values should be cleared and not saved
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Add password to BorrowerMandatoryField
2 - View quick add form
3 - See confirm password twice
4 - Apply patch
5 - See confirm password once
6 - Add password to QuickAddFields
7 - Confirm one confirm field
8 - Remove password form BorrowerMandatory field
9 - Confirm there is one confirm field and password fields are not
required
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
0) Apply the patch
1) git grep Data::Printer
-> should return no results
2) Go to Reports -> Use saved - should work fine
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
See bug 18552. When we resolved the housebound_role bug, the hash got
filled correctly again. And this revealed that the (second) call to
Koha::Patrons->find was not appropriate. It can be removed, as Jonathan
explained on the report.
Note: Commit 95429af685 added this call, but
it was hidden until the template variable hash got fixed.
Test plan:
Restart Plack and go to patron details again.
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>
Bug 17196 move the marcxml out of the biblioitems table.
That will break SQL reports using it.
It would be handy to propose an automagically way to convert the SQL
reports.
We do not want to update the reports automatically without user inputs,
it will be too hasardous.
However we can lead the user to convert them.
In this patchset I suggest to warn the user if a report is subject to be
updated.
TODO: Add a way to mark this job done (using a pref?) to remove the
check and not to display false positives.
Test plan:
- Create some SQL reports (see https://wiki.koha-community.org/wiki/SQL_Reports_Library)
- Go on the report list page (/reports/guided_reports.pl?phase=Use saved)
- For the reports using biblioitems.marcxml you will see a new column
warning you that it is obsolete
- Click on update link
=> that will open a modal with the converted SQL query
- Click on the update button
=> you will be informed that the query has been updated
If all the reports are updated, the new column "Update" will no longer
be displayed.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
The same as first patch, but also with advanced search form in header hidden
on page load - see comment 4
Issue with advanced search form is gone.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Philippe <philippe.audet-fortin@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In member search page, the result table is in Ajax so fully managed by Javascript. There is also a yellow dialog message prepared in HTML.
Thoses elements are hidden by JS code : ie $("#patron_list_dialog").hide().
The problem is that the static page is first loaded an displayed then the JS code runs an hides the elements.
On a low performance computer, this action is visible and looks like there is a blinking yellow message.
I propose to hide with CSS so that thoses elements are not displayed in static page and are there shown in dynamic JS code.
Test plan :
Check display is unchanged :
- Go to home page /cgi-bin/koha/members/members-home.pl
- Perform patron search from header search box
- Perform patron search by clicking on a letter
- Perform patron search from filters (left of results table)
- Select a patron and add it to a list => you see the yellow message
Yellow message does no longer appear with this patch.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Philippe <philippe.audet-fortin@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Apply the change from bug 15553 to InstallAuth.pm too.
Test plan:
[1] Remove all cgisess_* files from your /tmp directory.
[2] Remove directory /tmp/cgisess_koha_[your instance], if there.
[3] Run the webinstaller
/cgi-bin/koha/installer/install.pl?step=1&op=updatestructure
[4] Check if you have cgisess_ files in /tmp/cgisess_koha_[your instance].
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Simplify regex for removing table name.
No need to escape a dot between the square brackets. No need to specify a
number of 1 between parentheses.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Description on editing csv profiles says:
"You can also use your own headers (instead of the ones from Koha) by
prefixing the field name with an header, followed by the equal sign."
So the header should be optional, but in fact it's mandatory. Also the
regular expression to cut table name from beginning of db column is not
right.
Test plan:
0. Don't apply the patch
1. Make two CSV profiles for exporting late issues
a) SUPPLIER=aqbooksellers.name|TITLE=subscription.title|ISSUENUMBER=serial.serialseq|LATE SINCE=serial.planneddate
b) aqbooksellers.name|TITLE=subscription.title|ISSUE NUMBER=serial.serialseq|LATE SINCE=serial.planneddate
2. Export late issues, profile a) works as expected, profile b) doesn't
3. Apply the patch
4. Both profiles should work
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The function that switches between quick add/fulll form assumes labels
are followed by values - patron_attr don't follow this pattern. This
patch just moves the hidden input field
To test:
1 - Have some patron attributes (with/without auth values set)
2 - Add them to QuickAddFields (patron_attr2 for example)
3 - view quick add form and set some values
4 - Switch to full form, values not transferred
5 - Switch to quick add, view values, save
6 - Values are not saved :-(
7 - Apply patch
8 - Repeat 3 - 5
9 - Values are transferred and saved :-)
Signed-off-by: Peggy Thrasher <p.thrasher@dover.nh.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Like:
Problem = a value of AutoResumeSuspendedHolds has been passed to param without key at /usr/share/koha/masterclone/C4/Templates.pm line 137.
Problem = a value of relatives_borrowernumbers has been passed to param without key at /usr/share/koha/masterclone/C4/Templates.pm line 137.
Problem is functions returning undef in list context (in this case
housebound_role).
No need to call Patrons::find a second time.
Note: The call of GetDebarments in the first patch suffered from this too.
It is in a fine place now too. But strictly speaking, should not have been
moved.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to a borrowers details page and create a manual restriction
2) Notice the restriction shows at the top of the page but the
restriction tab says the member is currently unrestricted
3) Apply patch and refresh page
4) Restrictions tab should now correctly show debarments and correct
number is shown
5) Confirming deleting and adding restrictions still works as expected
Sponsored-by: Catalyst IT
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: Kyle M Hall <kyle@bywatersolutions.com>
To recreate:
1 - Place a hold for pickup at Midway
2 - Enable independentbranches
3 - Login to staff interface as admin without superlibrarian status from
a different branch
4 - View the holds for the title you placed a hold on
5 - The hold placed in step 1 should show a dropdown with current branch
as pickup location, current branch is the only in that dropdown
6 - Verify it displays correctly for superlibrarian
7 - Apply patch
8 - The correct pickup location should show and not be editable
9 - Verify it is a dropdown
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If a record has any holds on it, the SIP2 item information response will
return a value of 08 "waiting on hold shelf" even if the item is not
actually a waiting hold. This is clearly a bug.
Test Plan:
1) Find an item that is not a waiting hold, but whose record has one or
more holds.
2) Issue a SIP2 item information request
3) Note in the response, the circulation status field is '08'
4) Apply this patch
5) Repeat the item informationr request
6) Note the code is now '03' ( available )
7) Check the item in to fill the hold
8) Repeat the item information request
9) Verify the circulation status is now '08'
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: Kyle M Hall <kyle@bywatersolutions.com>
