Uninitialized value warning on /tools/export.pl when $record_type is undef
Use of uninitialized value $record_type in string eq
at /home/vagrant/kohaclone/tools/export.pl line 43.
This warning in koha-testing-docker appears in:
/var/log/koha/kohadev/intranet-error.log
This patch fixes it by working when $record_type is Undef.
The functionality still remains the same but warning doesn't flood
error log.
To reproduce:
1. Go to export data tool page (/tools/export.pl).
2. Check the error log and find the upper mentioned warning,
check the timestamp to ensure that it was added when you loaded the page.
3. Apply the patch.
4. Load the page again, ensure that the same warning doesn't get added
to the log file again.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
MARC::Record and MARC::File::* modules sometimes use the position 09 of
the leader to detect encoding. A blank character means 'MARC-8' while an
'a' means 'UTF-8'.
In a UNIMARC authority this position is used to store the authority type
(see https://www.transition-bibliographique.fr/wp-content/uploads/2021/02/AIntroLabel-2004.pdf [FR]).
In this case, 'a' means 'Personal Name'.
The result is that the import will succeed for a Personal Name
authority, but it will fail for all other authority types.
Steps to reproduce:
0. Be sure to have a Koha UNIMARC instance.
1. Download the MARCXML for "Honoré de Balzac"
curl -o balzac.marcxml https://www.idref.fr/02670305X.xml
2. Verify that it's encoded in UTF-8
file balzac.marcxml
(should output "balzac.marcxml: XML 1.0 document, UTF-8 Unicode
text")
3. Go to Tools » Stage MARC for import and import balzac.marcxml with
the following settings:
Record type: Authority
Character encoding: UTF-8
Format: MARCXML
Do not touch the other settings
4. Once imported, go to the staged MARC management tool and find your
batch. Click on the authority title "Balzac Honoré de 1799-1850" to
show the MARC inside a modal window. There should be no encoding
issue.
5. Write down the imported record id (the number in column '#') and go
to the MARC authority editor. Replace all URL parameters by
'breedingid=THE_ID_YOU_WROTE_DOWN'
The URL should look like this:
/cgi-bin/koha/authorities/authorities.pl?breedingid=198
You should see no encoding issues. Do not save the record.
6. Import the batch into the catalog. Verify that the authority record
has no encoding issue.
7. Now download the MARCXML for "Athènes (Grèce)"
curl -o athènes.marcxml https://www.idref.fr/027290530.xml
8. Repeat steps 2 to 6 using athènes.marcxml file. At steps 4 and 5 you
should see encoding issues and that the position 9 of the leader was
rewritten from 'c' to 'a'. Strangely, importing this batch fix the
encoding issue, but we still lose the information in position 09 of
the leader
This patch makes use of the MARCXML representation of the record instead
of the ISO2709 representation, because, unlike
MARC::Record::new_from_usmarc, MARC::Record::new_from_xml allows us to
pass directly the encoding and the format, which prevents data to be
double encoded when position 09 of the leader is different that 'a'
Test plan:
- Follow the "steps to reproduce" above and verify that you have no
encoding issues.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If the letter has been removed, fall back to itemnumber/due date. (Title is
no longer fetched.) We may assume that the notice is present.
Note: The option to 'protect' a notice may need some more thought. Perhaps
it needs to be an attribute on itself.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested by deleting notice, running fines again.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It would be great if we could customize what information was added to the "Description of charges" field when a fine was made so data could be stored even when the item is deleted.
Test Plan:
1) Create an overdue checkout that will get a fine
2) Run fines.pl
3) Note the description for the fine
4) Delete the fine from the database
5) Apply this patch
6) Run updatedatabase.pl
7) Restart all the things!
8) Run fines.pl
9) Note the description of the fine is unchanged
10) Delete the fine again
11) Browse to Slips & Notices
12) Edit the new notice OVERDUE_FINE_DESC
You will have access to the objects checkout, item, and borrower
13) Run fines.pl
14) Note your new description was used
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch and restart everything
2. Go to Tools > News and create some new additional content.
3. Notice a Save and continue button
4. Try saving and contining.
5. Make sure if you are using the CodeMirror editor that you are still in the CodeMirror editor
6. Try 2 - 5 again but with the wysiwyg editor, make sure when you save and continue you remain in the wysiwyg editor.
7. If you are saving and contining from News make sure you remain in News, when you are saving and contining from HTML customizations make sure you remain there.
8. Turn on the NewsLog system preference
9. With the NewsLog on make sure your content is being logged correctly when you sabe and continue.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
tools/manage-marc-import.pl: sub commit_batch does no longer need $schema
tools/manage-marc-import.pl: sub revert_batch: calling BatchRevertRecords which has no interval and callback
misc/commit_file.pl: sub print_progress_and_commit does no longer commit, renamed
misc/commit_file.pl: sub print_progress does no longer have a schema parameter
misc/commit_file.pl: sub revert_batch reported deleted items as added
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch fixes the broken commit_file.pl script.
It doesn't deal with commiting the import from the UI.
To test:
1. Pick a file for staging:
$ kshell
k$ misc/stage_file.pl --file TestDataImportKoha.mrc
=> SUCCESS: All good
2. Commit!
k$ misc/commit_file.pl --batch-number 1
=> FAIL: You see
DBIx::Class::Storage::DBI::_exec_txn_begin(): DBI Exception: DBD::mysql::db begin_work failed: Already in a transaction at /kohadevbox/koha/C4/Biblio.pm line 303
3. Apply this patch
4. Repeat 2
=> SUCCESS: Commit succeeds
5. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: (QA follow-up) Remove unexisting parameters of BatchRevertRecords
There is no interval and callback as in BatchCommitRecords.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: Call progress callback one last time to confirm comppletion
Previously after finishing the loop we were still in a transaction that never completed - we should report progress when done
one final time to commit the last records
To test:
1 - Stage a file with > 100 records
2 - Commit file
3 - Confirm batch is imported and no records left as staged
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: Fix import from staff client
same test as before, but via the staff client
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: Handle the transaction in BatchCommitRecords
Requiring the callback to commit was breaking reversion, and likely elsewhere
Let's simplify and say that the routine iteself will handle the txn and commit
TO test:
1 - Stage a file
2 - Import a file
3 - Revert a file
4 - Test staff client and command line
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When attaching a new cover image to an item we should not replace cover
images attached to the bibliographic record if "Replace existing covers"
is ticked.
Test plan:
Attach 1+ image to a bibliographic record
Attach 1 image to an item of this biblio
Attach another image to the item and seect "replace existing covers"
=> Without this patch the images attached to the biblio are removed
=> With this patch applied only the images attached to the image are
removed
Same if you tick the checkbox when attaching an image to the biblio
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Modifying an existing element of additional content (News) by changing
the library causes a duplication of the entry on the Additional contents
(News) list. A subsequent attempt of deleting one of the entries results
in deleting both of them. This is due to the fact that after
the unwanted duplication all the entries share the same
additional_contents.code.
Test plan
=========
1. Create a piece of news under Tools > News.
2. After having saved it make a modification by changing the library.
It should result in two rows in the table.
3. Delete one of the lines with Delete button. Both lines will
disappear.
4. Apply the patch.
5. Repeat the steps 1 and 2. Only the one (the modified) entry should be
present in the table.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This change logs warnings from the CGI background MARC import.
Test plan:
0) Apply patch
1) Export a record with an item
2) Update the 952$f subfield to "Circulation" (any value over 10 chars)
3) Import the record and try to add the item
4) The import will stay stuck with "Importing" status and 0% job
progress
5) Check the /var/log/koha/kohadev/intranet-error.log file
and notice there's an error with the following text:
"Data too long for column 'coded_location_qualifier' at row 1"
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1 - Sign in as a superlibrarian
2 - Tools->Batch patron modification
3 - Add patrons with and without pasword expiration set
4 - Confirm dates display correctly on modification page, or show never
5 - Check the box to delete all dates
6 - Confirm patrons now show 'Never'
7 - Edit patrons again, set a date
8 - Confirm date is set correctly
9 - Sign in as a user with catalogue/tools/borrowers permissions, but not superlibrarian
10 - Confirm y9ou do not see, and cannnot edit password expiration dates
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patchset adds the display of all matches found during import to the import management screen
A staff member with the permission to manage batches will be able to select for any individual record which match, or none, should be used during import
To test:
1 - Import a batch of records or export existing records from your catalog
2 - Import the file (again) and select a matching rule that will find matches
3 - Note that you now have radio buttons allowing you to select a record, or none
4 - Test scenarios:
I - When 'Action if matching record found' is 'Ignore'
a - Imported record ignored if match is selected
b - 'Action if no match found' followed if no match is selected (Ignore matches)
II - When 'Action if matching record found' is 'Replace'
a - The chosen record is the one overlayed (you can edit the chosen record before importing to confirm)
b - 'Action if no match found' followed if no match is selected (Ignore matches)
III - When 'Action if matching record found' is 'Add incoming record'
a - Record is added regardless of matches
5 - Confirm 'Diff' 'View' links work as expected
6 - Confirm that after records are imported the radio buttons to choose are disabled
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Bug 22785: API files
Signed-off-by: Ben Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates the notices edit interface in order to replace
jQueryUI accordion and tabs widgets with Bootstrap collapse and tabs.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- Set the TranslateNotices system preference to "Don't allow."
- Go to Tools -> Notices and edit any notice.
- On the "Modify notice" page you should see three collapsed sections:
Email, Print, and SMS.
- Clicking the section headings should expand and collapse the panels.
- With one of the panels open, click Save -> Save and continue editing.
- When the page reloads the same panel should be expanded.
- Enable the TranslateNotices system preference.
- Return to the edit interface for one of your notices.
- You should now see at least two tabs: Default and English.
- The sections under each tab should continue to work correctly.
- Test the "Save and continue" functionality again. When redirected you
should return to both the correct tab and the correct panel, e.g. the
"Print" section under the "English (en)" tab.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch modifies instances in the code which try to get cookies
using:
my %cookies = parse CGI::Cookie($cookie);
In some cases the relevant lines can be removed because they are unused.
In others it can be replaced with:
my %cookies = CGI::Cookie->fetch();
To test, apply the patch and restart_all. Test the following pages to
confirm they load without errors:
- Circulation -> Offline circulation file upload
- Circulation -> Offline circulation -> Add to queue
- Tools -> Batch item modification
- Tools -> Stage MARC for import
- Tools -> Staged MARC management
- Tools -> Batch patron modification
- Tools -> Upload local cover image
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds the ability to send the ACCTDETAILS notice for new users
added using the patron import tool.
Test plan
1. Create a valid csv for patron import that includes some new users,
ensuring you add a valid email address for which you have access.
2. Import the users using the patron import tool and select the new
'Send email to new patrons' checkbox.
3. Check that the notice appears in the new patrons notices
4. Check that you received a welcome email for the user.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Same as the previous patch but for the inventory.
Test plan:
Same as before but test the inventory tool
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
C4::Templates::GetColumnDefs can easily be replaced using the new
Koha::Database::Columns module.
Test plan:
Go to the import patron tool and confirm that you see the same list of
patron's attribute on the import patron form.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds the ability to do inventory by collection.
_TEST PLAN_
Before applying:
1) Go to "Tools > Inventory/stocktaking"
2) Note that there is no "Collection code:" option
Optionally:
2b) You can create a Barcode file with a single barcode
2c) Don't select anything from "Select items you want to check" (or filter if you know
how to filter to make it faster... doesn't matter)
2d) Click "Submit" at the bottom of the screen
2e) Note that there is no "Collection code" column in the screen output or CSV output
(ie with/without the "Export to CSV file" box ticked before submitting)
Apply the patch.
After applying:
3) Note that there is a "Collection code" filter on the main inventory screen
4) Create a Barcode file with a single barcode for an item with a collection
and upload it using the "Choose file" button.
5) Select that item's collection code from the "Collection code" filter
6) Click "Submit"
7) Note that the screen output and the CSV output contains a "Collection code" column
(ie with/without the "Export to CSV file" box ticked before submitting)
Signed-off-by: kelly mcelligott <kpmcelligott@gmail.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
A new agefield has been added to the 'Automatic item modifications by
age' tool. The options for the agefield are: replacementpricedate, datelastborrowed,
datelastseen, damaged_on, itemlost_on, withdrawn_on
If no option is selected then Koha will default to saving 'agefield' =
items.dateaccessioned
Similarly, if a Koha instance has an old item rule without 'agefield'
defined then Koha will default to using 'items.dateaccessioned'.
This is confirmed by the AutomaticItemModificationByAge.t unit test.
Test plan:
1. Go to: Tools > Catalog > Automatic item modifications by age
2. Observe there is a new 'Age field' dropdown in the rule form.
3. Create a rule, set the values:
- 'Age in days' = 20
- Leave 'Age field' = 'Choose an age field'
- 'Substitutions': 'items.barcode' = 'test'
- Save the rule
4. Confirm the 'List of rules' page displays 'items.dateaccessioned in the 'Age field' column
5. Add another rule:
- 'Age in days' = 2
- 'Age field' = 'items.datelastseen'
- 'Substitutions': 'items.barcode' = 'test2'
- Save the rule
6. Confirm the 'List of rules' page displays 'items.datelastseen' in
the 'Age field' column for that second rule
7. Add some more rules and confirm you can delete them
8. Edit a record:
- Make the items.dateaccessioned = 3 day ago (so rule 1 is false)
- Make the items.datelastseen = 3 days ago (so rule 2 is true)
9. Run the automatic_items_modification_by_age.pl:
- sudo koha-shell <instance>
- cd misc/cronjobs
- ./automatic_item_modification_by_age.pl -v -c
10. Confirm the item has it's barcode set to 'test2'
11. Run unit tests:
- sudo koha-shell <instance>
- prove t/db_dependent/Items/AutomaticItemModificationByAge.t -v
Sponsored-By: Catalyst IT
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch builds on a patch by Mark Tompsett, adding the option to take
a patron's picture using the computer's webcam. The photo can then be
saved to the patron's account.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- Go to Administration -> System preferences and enable the
'patronimages' preference.
- View a patron record. In the sidebar, hover your mouse over the blank
patron image. Click the "Edit" button which appears.
- A modal window should appear with two sections, "Upload patron photo"
and "Take patron photo."
- If your computer has a webcam, your browser should ask permission to
access it. Grant access.
- You should see the view of your webcam shown under the "Take photo"
button.
- Click the "Take photo" button. The captured photo should be shown in
place of the live video from the webcam.
- You should now see three buttons: "Retake photo," "Download photo,"
and "Upload photo."
- Clicking "Retake photo" should hide those buttons and return you
to a live video view.
- Clicking "Download" should make your browser download the image.
- Clicking "Upload" should cause the page to redirect back to the
patron detail page where you should see the new patron image
displayed in the sidebar.
- Trigger the modal again and click the "cancel" button. The
modal should disappear and camera access should stop.
- If your computer has no webcam the modal should appear correctly but
there should be a banner at the bottom indicating that a camera is not
available.
- Try the test again but this time deny your browser access to the
webcam. You may need to reset the camera permissions in your browser's
settings. When the modal appears you should see a message saying
access to the camera is denied.
- The patron image edit modal should be available on all pages which
show the patron image in the sidebar: Check out, Batch check out,
Details, Accounting, Routing lists, Circulation history, Holds
history, Modification log, Notices, Statistics, Files, Purchase
suggestions, Discharges, Housebound, and ILL requests history.
- Test adding an image to a patron record using the "Upload photo"
option. It should still work correctly.
- If the patron has an image attached, the "Upload photo" section should
have a "Delete" button. Test that it works correctly.
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When system preference is off, call no code related to Koha::Recalls.
Also add some missing module import.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
See recalls on Intranet
- old recalls (all inactive recalls)
- recalls queue (all active recalls) - cancel, expire, revert waiting status, multiple cancel, mark overdue
- recalls to pull (available but not yet waiting) - cancel
- recalls awaiting pickup (awaiting pickup, awaiting pickup more than RecallMaxPickUpDelay days) - expire, revert waiting status
- overdue recalls (overdue to be returned) - cancel, multiple cancel
- biblio recalls tab (all active recalls relevant to this bib) - cancel, expire, revert waiting status, mark overdue
- patron recalls tab (all active recalls relevant to this patron) - cancel, expire, revert waiting status, mark overdue
- patron recalls history tab (all recalls relevant to this patron) - cancel, expire, revert waiting status, mark overdue
- log viewer
and the general circulation of recalls
== TEST PLAN FOR RECALLS ==
ADMINISTRATION
1. Apply all patches
2. Run database updates, update schema files and confirm everything applies cleanly
3. Run tests and confirm everything passes:
t/db_dependent/Koha/Recall.t
t/db_dependent/Koha/Recalls.t
t/db_dependent/Stats.t
t/db_dependent/Circulation/CalcFine.t
t/db_dependent/Koha/Item.t
t/db_dependent/Koha/Biblio.t
t/db_dependent/Koha/Patron.t
t/db_dependent/XSLT.t
t/db_dependent/Search.t
t/db_dependent/Holds.t
t/db_dependent/Circulation/transferbook.t
t/db_dependent/Circulation.t
4. Go to Administration -> system preferences. Find the UseRecalls system preference. It should be DISABLED. Confirm RecallsMaxPickUpDelay is set to 7 by default.
5. Go to Administration -> circulation rules. Confirm there are no recalls circulation rules showing.
6. Test a few circulation flows: checking out, placing a reserve, checking in, fulfilling a reserve, etc. Confirm everything works as normal.
7. Go to Administration -> system preferences. Enable the UseRecalls system preference.
8. Go to Administration -> circulation rules. Set the following rules:
Recalls allowed (count) = 0
Recalls per record (count) = 0
On shelf recalls allowed ( If any unavailable / If all unavailable ) = If any unavailable
Recall due date interval (days) = 3
Recall overdue fine amount = (something different to your normal fine amount)
Recall pickup period (days) = 1
Throughout your testing, try with different combinations of these rules and itemtype / branchcode / categorycode. Also try with null values. Keep the circulation rules open in another tab so you can refer to and update these easily. You should also have at least one other tab open for the staff client, and a third tab open for the OPAC, for ease of testing.
9. Go to your account -> More -> Set permissions. Confirm the recalls permission is checked.
10. Set up a test user with OPAC login details (Borrower A). This could also be your own user, as long as you have OPAC login access.
11. Set up a test record (Biblio A) with at least two items (Item A and Item B) of the same item type (or an item type with the same recall circ rules).
PLACING A RECALL
12. Log in to the OPAC as Borrower A. Do a catalogue search with a term that will return multiple results, including Biblio A.
13. Click on Biblio A.
14. Notice there is a 'Place recall' button on the sidebar menu. Click this button. There will be a message saying that there are no items to recall - this is because all items are available.
15. Check out Item A to another borrower (Borrower B).
16. Refresh the 'Place recall' page. You will still NOT be able to place a recall - this is because Recalls allowed = 0 and Recalls per record = 0.
17. Edit the circulation rules to have the following values:
Recalls allowed (count) = 1
Recalls per record (count) = 1
18. Refresh the 'Place recall' page. You will now see the form to place a recall.
BIBLIO-LEVEL RECALL, NO TRANSFER
19. Place a biblio-level recall.
Pickup location: Branch A, the set branch when you are logged into the staff client
Recall not needed after (expiration date): whatever you want
Select 'recall next available item'
Click confirm
20. Confirm the recall is placed successfully. Confirm that the new due date displayed is correctly calculated to be today's date, plus 3 days (taken from the 'recall due date interval' circ rule)
21. In the staff client, look at Borrower B's account, and go to their Notices tab. Confirm they have received a 'Notification to return recalled item' notice.
22. Look at Borrower B's checkouts table. Notice the due date for their checkout has been adjusted, and there is now a note to say that the item was recalled and the due date adjusted.
23. Log in to the OPAC as Borrower B and go to your summary tab. Notice there is a note under their checkout to say the item had been recalled.
24. Log out of the OPAC and log back in as Borrower A.
25. Go to your summary tab. Confirm there is a Recalls tab with a count of 1.
26. Cancel the recall using the button. Confirm it cancels and the Recalls tab disappears.
27. Do a catalogue search with a term that will return multiple results, including Biblio A.
28. When the results load, notice there is a 'Place recall' button next to the 'Place hold' button. Click this 'Place recall' button.
29. Notice you are redirected straight to the form to place a recall.
30. Place a biblio-level recall again, following the steps in Step 19.
31. Go to your recalls history tab. Notice your first cancelled recall shows here.
32. Cancel the recall you just created, using the button. Confirm it cancels and you are redirected to your summary tab.
33. In the staff client, enable the UseCourseReserves system preference.
34. Go to the main menu, click Course Reserves.
35. Add a new course. (You may also have to define an authorised value for DEPARTMENT.)
36. Add Item A as a reserve to this course.
37. View Course Reserves in the OPAC. Click the course you just created.
38. Notice the reserve has a Recall button underneath it's 'Checked out' status. Click this button.
39. Place a biblio-level recall again, following the steps in Step 19.
40. Click the 'Place recall' link in the breadcrumbs.
41. Notice there is a message saying that you have reached the max number of recalls on this record. This is because Recalls allowed = 1 and Recalls per record = 1.
42. Edit the circulation rules to have the following values:
Recalls allowed (count) = 10
Recalls per record (count) = 5
43. Refresh the 'Place recall' page. You will now see the form to place a recall.
44. Create another test record (Biblio B) with at least one item (Item C).
45. Find this record on the OPAC and place a biblio-level recall again, following the steps in Step 19.
46. In the staff client, go to Circulation -> Old recalls. You should be able to see your two cancelled recalls.
47. Go to Circulation -> Recalls queue. Your current recalls should show here.
48. Use the 'Select all' checkbox to select all recalls.
49. Cancel the recalls using the 'Cancel selected recalls' button.
50. Go to the OPAC and place a biblio-level recall on Biblio A again, following the steps in Step 19.
51. In the staff client, check in Item A, which should still be checked out to Borrower B.
52. A box should pop-up asking you to confirm Borrower A's recall. Click ignore.
53. Click the link to go view Biblio A's details in the catalogue.
54. Click the recalls tab. Notice Borrower A's recall is displayed, and shows it is still Requested (has not been confirmed waiting).
55. Check in Item A again. This time, confirm the recall as waiting using the "Confirm recall" button.
56. Go to Borrower A's Notices tab. Confirm there is a notice "Recalled item awaiting pickup".
57. Go to Borrower A's checkouts. Notice there is a recalls tab. Confirm the recall is showing as "Ready for pickup".
58. Click the 'Actions' dropdown. Click the "Revert waiting" button. The page should show a message that the waiting status has been reverted, without reloading.
59. This time, check in Item B. The recall confirmation box should show again, because this a biblio-level recall that any recallable item under Biblio A can fill. Click the "Print slip and confirm" button.
60. Check the slip that is generated. Confirm it contains Borrower A's correct details, and the details of the recall are correct.
61. Go to Circulation -> Recalls awaiting pickup. Confirm the recall is now waiting and shows in this list.
(You could also try this with Item B having a different item type to Item A, and circ rules not allowing Item B's item type to have recalls. When checking in Item A, it should not trigger the recall box).
62. Go to Borrower A's checkouts. Check out Item B.
63. Confirm the checkout is successful and the recall is removed from the Recalls tab.
64. Go to Circulation -> Old recalls. The fulfilled recall should show.
65. Check in Item B.
BIBLIO-LEVEL RECALL, TRANSFER REQUIRED
66. Check out Item A to Borrower B.
67. Log in to the OPAC as Borrower A.
68. Find Biblio A and place a biblio-level recall.
Pickup location: Branch B, a different branch from your logged in branch. This recall will require a transfer.
Recall not needed after (expiration date): whatever you want
Select 'recall next available item'
Click confirm
69. In the staff client, check in Item A at Branch A. Notice the box that pops up shows that a transfer is required.
70. Click "confirm recall and transfer" and confirm the transfer.
71. Go to your account and click the Recalls tab.
72. Confirm the recall status now shows the item is in transit to Branch B.
73. In the drop-down top-right of your window, select 'Set library'.
74. Set your library to Branch B.
75. Go to Circulation -> Transfers to receive. Notice that the recall is showing here.
76. Click 'Cancel transfer'.
77. Go to Circulation -> Recalls queue
78. Confirm the recall status has been reverted to Requested.
79. Set your library back to Branch A.
80. Check in Item A and trigger the transfer.
81. Set your library back to Branch B.
82. Check in Item A at Branch B.
83. When the 'Recall found' box pops up, click Ignore.
84. Go to Circulation -> Recalls to pull. The recall should show here, with a button to "Cancel recall and return to: Branch A"
85. Click the button to cancel the recall.
86. Repeat Steps 66-70.
87. Check in Item A at Branch B. Confirm the recall as waiting.
88. Check out Item A to Borrower A to fulfill the recall.
89. Set your library back to Branch A and check in Item A.
ITEM-LEVEL RECALL, NO TRANSFER
90. Go to Administration -> circulation rules. Set the following rules:
On shelf recalls allowed ( If any unavailable / If all unavailable ) = If all unavailable
91. Check out Item A to Borrower B.
92. Log in to the OPAC as Borrower A and go to Biblio A.
93. Click the 'Place recall' button. Confirm there is a message that there are no items to recall. This is because On shelf recalls allowed = If all unavailable, and there is still one item (Item B) available.
94. In the staff client, edit Item B to have a withdrawn, item lost or not for loan status.
95. Refresh the 'Place recall' page. Confirm you can now see the form to place a recall.
96. Place an item-level recall.
Pickup location: Branch A.
Recall not needed after (expiration date): whatever you want
Select 'recall a specific item'
Item B will not be selectable, and Item A should be selected by default.
Click confirm
97. In the staff client, edit Item B and remove the lost or missing status.
98. Check in Item B. Confirm the recall box does not pop up, because it cannot fill the item-level recall.
99. Check in Item A. Confirm the recall as waiting.
100. Go to Circulation -> Recalls awaiting pickup
101. Expire the recall. Confirm it expires as expected.
ITEM-LEVEL RECALL, TRANSFER REQUIRED
102. Repeat steps 91 to 95.
103. Place an item-level recall.
Pickup location: Branch B, we will require a transfer.
Recall not needed after (expiration date): whatever you want
Select 'recall a specific item'
Item B will not be selectable, and Item A should be selected by default.
Click confirm
104. In the staff client, check in Item A. Confirm the recall and trigger the transfer.
105. Set your library to Branch B and check in Item A.
106. Confirm the recall as waiting.
107. Check out Item A to Borrower A and fulfill the recall.
108. Set your library back to Branch A and check in Item A.
CRONJOBS: EXPIRING RECALL
109. Check out Item A to Borrower B.
110. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
111. In your terminal, enter mysql and edit the expiration date of your recall to be before today
UPDATE recalls SET expirationdate = NOW()-2 WHERE recall_id = X;
112. Run the expiry cronjob from within your shell
perl misc/cronjobs/recalls/expire_recalls.pl
113. Go to Borrower A's account and go to the Recalls history tab
114. Confirm the recall has been expired because the current date surpassed the specified expiration date
115. Check out Item A to Borrower B.
116. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
117. In the staff client, check in Item A and confirm the recall as waiting.
118. In your terminal, enter mysql and edit the waiting date of your recall to be before today
UPDATE recalls SET waitingdate = NOW() - interval 5 day WHERE recall_id = X;
119. Run the expiry cronjob from within your shell
perl misc/cronjobs/recalls/expire_recalls.pl
120. Go to Borrower A's account and go to the Recalls history tab
121. Confirm the recall has been expired because the recall had been waiting for more days than the Recall pickup period
122. Go to Administration -> circulation rules. Set the following rules:
Recall pickup period (days) = 0
123. Set the RecallsMaxPickUpDelay system preference = 1.
124. Check out Item A to Borrower B.
125. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
126. In the staff client, check in Item A and confirm the recall as waiting.
127. In your terminal, enter mysql and edit the waiting date of your recall to be before today
UPDATE recalls SET waitingdate = NOW()-2 WHERE recall_id = X;
128. Run the expiry cronjob from within your shell
perl misc/cronjobs/recalls/expire_recalls.pl
129. Go to Borrower A's account and go to the Recalls history tab
130. Confirm the recall has been expired because the recall had been waiting for more days than the RecallsMaxPickUpDelay syspref
CRONJOBS: OVERDUE RECALL
131. Check out Item A to Borrower B
132. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
133. In your terminal, enter mysql and edit the due date of the checkout to Borrower B to be before today
UPDATE issues SET date_due = NOW()-2 WHERE issue_id = X;
134. Run the overdue cronjob from within your shell
perl misc/cronjobs/recall/overdue_recalls.pl
135. Go to Circulation -> Overdue recalls
136. Confirm your recall is showing here now as the recall has been marked Overdue
CIRCULATION
137. Check in Item A.
138. When the recall box pops up, click Ignore.
139. Check out Item A to Borrower B. You should see a yellow confirmation box, saying that another borrower has recalled the item you are trying to check out.
140. Click "No don't check out" and confirm the item isn't checked out and the recall remains.
141. Repeat Step 139.
142. Click "Yes check out" and confirm the item is checked out and the recall remains.
143. When Borrower B's checkout table loads, confirm that you cannot renew or check in the item from the Checkouts table because there is a 'Recalled' link which takes you to the recalls tab for that biblio.
144. Repeat Steps 137-139.
145. Select "Cancel recall" and click "Yes check out" and confirm the item is checked out and the recall has been cancelled.
146. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
147. Check in Item A. Confirm the recall as waiting.
148. Check out Item A to Borrower B. You should see a yellow confirmation box, saying that that another borrower has recalled the item that you are trying to check out.
149. Select "Revert waiting status" and click "Yes check out" and confirm the item is checked out and the recall status has reverted to requested.
OTHER
150. In your terminal, enter mysql and edit the due date of the checkout to Borrower B to be before today
UPDATE issues SET date_due = NOW()-2 WHERE issue_id = X;
151. Go to Borrower A's recalls and click the Actions dropdown.
152. Click "Mark as overdue" and confirm the recall is marked as overdue manually.
153. Go to Tools -> Log Viewer. Check only the Recalls module, and leave all other parameters, and click Submit.
154. Confirm all of the recalls actions that have been made are correctly logged.
Note: recalls messaging preferences are introduced in Bug 23781.
The recall feature is fully documented at: https://wiki.koha-community.org/wiki/Catalyst_IT_Recalls
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch tackles a very specific scenario. Calling split(...,
CGI::param) makes it be called in list context. The split docs say:
split /PATTERN/,EXPR,LIMIT
this means the first CGI param will be used as EXPR and the second one
as LIMIT, which is wrong anyway. So the fix is to just force scalar
context.
To test:
1. Not sure, just make sure nothing breaks when using the scripts in the
browser.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
I squashed the patches because they are too trivial to have a test plan.
Or it is too much work to write the test plan for such trivial cases. I
leave the original commit messages just in case.
Generally, this are all cases in which CGI::param is being called in a
trivially identifiable _list context_. i.e. they are assigned to a
@variable.
I left one case out on purpose: admin/auth_subfields_structure.pl
Paul introduced this:
my @kohafield = ''.$input->param('kohafield');
and then:
my $kohafield = $kohafield[$i];
My intuition says it is forcing scalar context on the first assignment
so the list contains a single element and then inside the loop some
$kohafield assignments should lead to undef, and even warnings. I leave
it for a separate patch because it is not that easy testable and is a
sensible area.
Bug 29771: Remove warning from acqui/finishreceive.pl
This patch removes a warning that shows when receiving.
To test:
1. Do the acq workflow up to the receive step.
2. Once you choose the items and click on Finish
=> FAIL: There's a warning in the logs
3. Revert receipt
4. Apply this patch
5. Receive
=> SUCCESS: No more warnings
6. Sign off :-D
Bug 29771: Remove warning from svc/members/add_to_list
To test:
1. Run:
$ tail -f /var/log/koha/kohadev/*-error.log
2. Generate a patron list
3. Perform a patron search that gives you a few
4. Select some, and choose to add them to the list
=> FAIL: The logs show the infamous warn:
CGI::param called in list context from /kohadevbox/koha/svc/members/add_to_list
5. Apply this patch
6. Restart plack and repeat 4
=> SUCCESS: No warn!
7. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates the Upload local cover image page so that the user
has the option of dragging a file from a folder on their computer
instead of using a file upload button.
The patch also adds a preview of uploaded single images and display of
existing images on the record you're adding to.
To test, apply the patch and make sure the LocalCoverImages system
preference is enabled.
- Go to Tools -> Upload local cover image and test the following
processes:
- Upload single cover image, specifying a biblionumber
- Test dragging an image from a file on your computer
- Test clicking the "Drop files here or click..." link.
- You should see a preview of the image file on the screen, with
information about the file: file name, image type, file size.
- Click "Process images"
- with "Existing covers will be replaced" checked
- with "Existing covers will be replaced" unchecked
When the upload process completes you should see information about the
title in the page heading and a thumbnail of the cover in the sidebar.
- Test that the image can be deleted from this page. You should be
redirected back to this page with the same title still selected.
- Upload a zip file of images
- Test dragging an image from a file on your computer
- Test clicking the "Drop files here or click..." link.
- A zip file can't be previewed onscreen but you should see the same
file information and a Font Awesome "zip file" icon.
- Click "Process images"
From the bibliographic detail page, click the "Images" tab, and click
"Upload." With this workflow the field asking for a biblionumber should
not appear.
From the bibliographic detail page, in the holdings table, choose Edit
-> Upload image. This process should be the same as above but should
provide item information on the screen. Confirm that images are uploaded
correctly to the specific item.
Test with AllowMultipleCovers enabled and disabled to confirm that the
"Existing covers will be replaced" checkbox is enabled only when
multiple covers are possible.
Signed-off-by: Solène Desvaux <solene.desvaux@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If a cardnumber, SMS number, or borrower number is inputted multiple times then the batch patron
modification page should not display that patron multiple times.
Test plan:
1. Create three text files that list card numbers, SMS numbers, and borrower numbers for three patrons. Example lists are below, notice in each there is one number duplicated:
Card numbers:
23529000035676
23529000651225
23529000080862
23529000035676
Borrower numbers:
19
49
7
49
SMS numbers:
2125551212
2125551212
2125551213
2125551214
2. Enable sending of SMS messages:
* Set SMSSendDriver system preference to Email
3. Make sure the cardnumbers, borrower numbers, and SMS numbers listed
above belong to patrons in your Koha
4. Go to Tools > Batch patron modification
5. Upload lists of cardnumbers, SMS numbers, and borrower numbers above, and confirm the following is happening in the batch patron modification page:
- Upload the text file of cardnumbers. Notice one patron is displayed twice
- Paste in the list of cardnumbers. Notice one patron is displayed twice
- Upload the text file of SMS numbers. Notice one patron is displayed twice
- Paste in the list of SMS numbers. Notice one patron is displayed twice
- Upload the text file of borrower numbers. Notice one patron is displayed twice
- Paste in the list of borrower numbers. Notice one patron is displayed twice
6. Apply patch and restart services
7. Repeat step 5 and this time observe that the patron record is not duplicated in the batch patron modification page
Sponsored-By: Catalyst IT
Signed-off-by: David Nind <david@davidnind.com>
JD Amended patch: adjust commit title
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch modifies the maximum size of a patron's image, from 500KB to
2MB. Also, in Home/Patrons/anyPatron, when you try to add an image to a
patron, you can now see the supported file types AND the maximum size.
The following places are affected by this patch:
- Home/Patrons/anyPatron
- Home/Tools/Upload patron images
- Home/Tools/Patron card creator/Images
To test:
1)Search for any patron and go to his page.
2)Hover over the image area on the left and click on the "Add" button.
3)Notice that the message above the choose file button only specifies
file types without the maximum size.
4)Add an image bigger than 500KB.
5)Nothing happens. (This is because the maximum size is 5KB)
6)Apply the patch.
7)Repeat steps from 1 to 3.
8)Notice that the message now includes the maximum size.
9)Add an image bigger than 500KB, but smaller than 2MB.
10)The image is succesfully uploaded.
11)Add an image bigger than 2MB.
12)Nothing happens. (The maximum size is now 2MB)
13)Repeat the steps 9 to 12 in "Home/Tools/Upload patron images" and
"Home/Tools/Patron card creator/Images".
14)Notice that the maximum size is updated.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes tools/cleanborrowers.pl use the new methods.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
DBIC handles DateTime correctly, no need for this output_pref call.
Test plan:
Create a new content, set the dates, confirm they are set correctly
Modify the content, modify the dates, confirm they are stored correctly
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When deleting a content, only the main one (lang="default") is removed,
which leads to orphan contents in the DB that are still displayed on the
UI.
Test plan:
0. Don't apply this patch
1. Create some contents, translate them in different languages
2. Delete some of them
=> Note that they are still displayed on the UI and that the entries
with lang!="default" are still in the DB
3. Apply this patch
4. Repeat 1
5. Run updatedatabase
6. Delete from of the contents
=> Note that the orphan entries created before you applied the patch
have been removed and that the "delete" behaviour is now working
correnctly.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Add a column "Subscriptions" to the batch deletion tools
Add a link on the number of subscription to the search page with all the subscriptions of the record
Add a button in the toolbar to select only biblio record without subscriptions
The changes are only on display
It is still possible to delete records that are attached to subscriptions from this tool (as it is possible for records with attached items)
To test:
1) Go to the batch record deletion (in tools)
2) Select a list of record numbers (select some with one or more subscription)
3) Click on Continue
4) Check that there is no column named "Subscription" and that there is no button "Select without subscription" in the toolbar
5) Apply patch
6) Repeat steps 1 to 3
7a) Check that there is a column named "Subscription" fill with the number of subscriptions attached to the record
7b) Check that the link in the subscriptions column send you to the search page with the subscriptions linked to this record
7c) Check that there is a button "Select without subscription" in the toolbar that selects record with no subscription attached
8) Sign off
Signed-off-by: Frank Hansen <frank.hansen@ub.lu.se>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
additional_contents.code is used to group DB rows together. Each row
represent one content in a given language, and the code is used to know
they are translation of the lang='default' one.
It's not really useful for the end user and we could hide it and
generate it.
Test plan:
Create/Edit/Delete additional contents (news and HTML customizations)
and confirm that they are correctly grouped together.
You need several languages installed to test this patch correctly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The commit "Bug 29290: Rename relationships borrower =>
patron" (d46492ac23) renamed the relation for the borrowers table from
'borrower' to 'patron' but the joins were not updated accordingly so a
few scripts got broken.
To test:
1) Notice that
$ perl misc/cronjobs/automatic_renewals.pl -c -s -v
returns 255 error code on exit
2) Apply patch
3) Notice the automatic_renewals.pl works now and exit code is 0
4) Make sure /cgi-bin/koha/tools/batch_extend_due_dates.pl works.
5) Try to grep for 'borrower' in Koha source code and see if there
are any other join done using the Koha::Checkout or
Koha::Old::Checkout objects.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29380: (follow-up) Fix renewal feature in staff interface
The commit "Bug 29290: Rename relationships borrower =>
patron" (d46492ac23) renamed the relation for the borrowers table from
'borrower' to 'patron' but the usage in the renew.pl script was not
updated.
To test:
1) Try to renew a book in intranet through the renewal tab
2) Notice it gives error
3) Apply patch
4) Notice the error is now gone
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
No method count found for Koha::Virtualshelves DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'category' in 'where clause' at /kohadevbox/koha/Koha/Objects.pm line 601 at /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/modules/tools/batch_record_modification.tt line 80.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch renames the (passed through) 'context' param for
'overlay_context'. I propose doing so, because in Koha-land 'context'
has a special meaning, related to C4::Context and it reads ambigous.
The patch itself is pretty trivial.
Tests should pass:
1. Run:
$ kshell
k$ prove t/db_dependent/Biblio/MarcOverlayRules.t
=> SUCCESS: Tests pass
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests still pass!
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 14957: (follow-up) Clarify 'context' param
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add a rule based system for merging MARC records to for example
prevent field data from being overwritten.
To test:
1. Apply this patch.
2. Log in to staff client.
3. Enable new syspref MARCMergeRules.
4. Click the new link "MARC merge rules" in the "Catalog"
section of the Koha administration page.
5. Create a new rule:
Module: source, Filter: *, Tag: 245, Preset: Protect.
6. Clicking "Edit" should allow you to edit corresponding rule.
7. Clicking "Delete" should remove corresponding rule after confirmation.
8. Selecting one or more rules followed by clicking "Delete
selected" should remove all selected rules after confirmation.
9. Try creating a rule with tag set to "**", the other options does
not matter. Verify that saving this rule produces an error
message complaining about invalid tag regular expression.
10. Try creating a rule with tag set to "008" (or other control
field) and set Appended: Append and Removed: Skip, the other
options does not matter. Verify that saving this rule produces
an error message complaining about invalid combination of actions
for control field.
11. With the 245 rule in step 5 in place, edit a bibliographic record,
change 245a for example (which should be Title for MARC21) and save.
12. Verify that the changes has not been saved.
13. Create a new rule:
Module: source, Filter: intranet, Tag: 245, Preset: Overwrite.
14. Repeat step 12, and verify that the changes has now been saved.
15. Run tests in t/db_dependent/Biblio/MarcMergeRules.t and very
that all tests pass.
Sponsored-by: Halland County Library
Sponsored-by: Catalyst IT
Sponsored-by: Gothenburg University Library
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The previous patch makes check_cookie_auth return the session instead of
$sessionID, so we are adjusting the different calls to prevent
confusion.
However they are mainly used to check the authentication status and
don't care about this second variable.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The value of the checkbox was not correct
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Here we go!
Disclaimer: this patch is huge and does many things, but splitting it in
several chunks would be time consuming and painful to rebase. However it
adds many tests and isolate/refactor code to make it way more reusable.
This patchset will make the "batch item modification" and "batch item
deletion" features use the task queue (reminder: Since bug 28158, and so
21.05.00, we do no longer use the old "background job" functionality and
the user does not get any info about the progress of the job).
More than that, more of the code to build an item form and a list of
items is now isolated in module (.pm) and include files (.inc)
We are reusing the changes made by bug 27526 that simplifies the way we
edit/create items (no more unecessary serialization Koha > MARC > MARCXML
> XML > HTML)
New module:
* Koha::BackgroundJob::BatchDeleteItem
Subclass for process item deletion in batch
* Koha::BackgroundJob::BatchUpdateItem
Subclass for process item modification in batch
* Koha::Item::Attributes
We needed an object to represent item's attributes that are not
mapped with a koha field (aka "more subfields xml")
This module will help us to create the marcxml from a hashref and the
reverse.
* Koha::UI::Form::Builder::Item
The code that was used to build the add/edit item form is
centralised in this module. In conjunction with the
subfields_for_item BLOCK (from html_helpers.inc) it will be really
easy to reuse this code in other places where the item form is used
(acquisition and serials modules)
* Koha::UI::Table::Builder::Items
Same as previously for the table. We are now using this table from 3
different places (batch item mod, batch item del, backgroung job
detail view) and the code is only in one place.
To use with items_table_batchmod BLOCK (still from html_helpers.inc)
This patch is fixing some bugs about repeatable subfields and regex. A UI
change will reflect the limitation: if you want to apply a regex on a
subfield you cannot add several subfields for the same subfield code.
Test plan:
Prepare the ground:
- Make sure you are always using a bibliographic/item record using the framework
you are modifying!
- Add some subfields for items that are not mapped with a koha field
(note that you can use 'é' for more fun, don't try more funny
characters)
- Make some subfields (mapped and not mapped with a kohafield)
repeatable
- Add default values to some of your subfields
There are 4 main screens to test:
1. Add/edit item form
The behaviour should be the same before and after this patch.
See test plan from bug 27526.
Those 2 prefs must be tested:
* SubfieldsToAllowForRestrictedEditing
* SubfieldsToUseWhenPrefill
2. Batch modification
a. Fill some values, play with repeatable and regex.
Note that the behaviour in master was buggy, only the first value was modified by the regex:
* With subfield = "a | b"
1 value added with "new"
=> "new | b"
* With subfield = "a | b"
2 new fields "new1","new2"
=> "new2 | b"
Important note: For repeatable subfields, a regex will apply on the subfields in
the "concatenated form". To apply the regex on all the different subfields of a given
subfield code you must use the "g" modifier.
This could be improved later, but keep in mind that it's not a regression or behaviour
change.
b. Play with the "Populate fields with default values from default framework" checkbox
c. Use this tool to modify items and play with the different sysprefs that
interfer with it:
* NewItemsDefaultLocation
* SubfieldsToAllowForRestrictedBatchmod
* MaxItemsToDisplayForBatchMod
* MaxItemsToProcessForBatchMod
3. Batch deletion
a. Batch delete some items
b. Check items out and try to delete them
c. Use the "Delete records if no items remain" checkbox to delete
bibliographic records without remaining items.
d. Play with the following sysprefs and confirm that it works as
expected:
* MaxItemsToDisplayForBatchDel
e. Stress the tool: Go to the confirmation screen with items that can be
deleted, don't request the job to be processed right away, but check the
item out before.
4. Background job detail view
You must have seen it already if you are curious and tested the above.
When a new modification or deletion batch is requested, the confirmation
screen will tell you that the job has enqueued. A link to the progress
of the job can be followed.
On this screen you will be able to see the result of the job once it's
fully processed.
QA notes:
* There are some FIXME's that are not blocker in my opinion. Feel free to
discuss them if you have suggestions.
* Do we still need MaxItemsToProcessForBatchMod?
* Prior to this patchset we had a "Return to the cataloging module" link
if we went from the cataloguing module and that the biblio was deleted.
We cannot longer know if the biblio will be deleted but we could display
a "Go to the cataloging module" link on the "job has been enqueued"
screen regardless from where we were coming from.
Signed-off-by: Nick Clemens <nick@bywatersolutions.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>
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>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
