When a booking is cancelled, patron received an email based on specific
letter.
Test plan:
1) Create a letter with code "BOOKING_CANCELLATION" on "Notices and
slips" tool.
2) Add booking or go on item already booked in advance.
3) Cancel it
4) Verify in message_queue table directly or go on patron page and click
on "Notices" tab section.
Sponsored by: Association de Gestion des Œuvres Sociales d'Inria (AGOS)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Just like with batch item modification, batch patron modification can accept
either a POST of a lot of data, which might be more than Apache's default
URL length limit, or a GET of a little data. Or at least it could, if both
the op 'cud-show' and the op 'show' were accepted. Show isn't doing any
creation or updating or deleting, it just has to be cud-show because it needs
to be able to accept large POSTs. So when it is only getting a little data, it
should be willing to take a GET with op=show just like batch item
modification does.
Test plan:
1. Without the patch, Tools - Patron lists - New patron list - give it a
name and Save
2. Type enough characters in the Patron search input to find a patron (I
like ace for poor often-used Henry Acevedo) and click on a patron in
the list of results
3. Click Add patrons
4. Click Patron lists, and in the Actions menu for your list, choose
Batch edit patrons. Note that the page that loads doesn't show any patrons
or UI to edit them, only a message about "No patron card numbers or
borrowernumbers given."
5. Apply patch, restart_all
6. Repeat step 4, but this time get a page with your patron listed, and a
form to change things about the patron record.
Sponsored-by: Chetco Community Public Library
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Since bug 37197 switched reports back to using a POST to send cardnumbers to
batch modification, we should also be using a single textarea rather than
multiple inputs.
Test plan:
1. Reports - Create from SQL - give it a name, and the SQL
select cardnumber from borrowers limit 3
2. Save report - Run report
3. Batch operations with 3 visible records - Batch patron modification
4. Verify that you have the same three cardnumbers in Batch patron modification
as were in the report.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This change validates the paths in datalink.txt/idlink.txt,
so that only images in the unpacked archive directory are allowed
Test plan:
0. Apply the patch
1. koha-plack --reload kohadev
2. Create a datalink.txt file with the following:
42,selfie.jpg
3. Create a jpeg at selfie.jpg
4. ZIP the datalink.txt and selfie.jpg files
5. Upload to the "Upload patron images" tool
(after enabling the "patronimages" system preference)
6. Note that the image uploads correctly
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 8fcb767fe2836c90ceacb5b5d8211524571eb8aa)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 579c28c764257a250c12aa11207772c074c1335e)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
0. Apply patch and restart/reload Koha
1. Test that uploading a patron image still works, in single file format and as a zip
Work as suggested
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 9bc0521493fbe2f9fe0dde051d0b2f52c8a14a9a)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To Test
1. Create a file name for example: test.zip`curl xxxxtesting.informaticsglobal.com`.zip
where the domain is one you can watch the logs from.
2. Go to Tools and click on Upload patron images choose option zip file and upload the file.
3. Check /var/log/apache2/access.log and see the curl with the IP
"xx.xxx.xx.xxx - - [11/Jul/2024:23:10:33 +0530] "GET / HTTP/1.1" 200 267 "-" "curl/7.68.0"
4. Apply the patch
5. Repeat 2 and 3 step and check no error is coming for the Remote execution error.
6. Test uploading actual zip file and images still works.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 5c931e00f73e91467581fd29721e5af8d7fa98ab)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If a notice doesn't already have any data in it we weren't able to use
the object to lookup the sample.. with this patch we now always load the
samples if they exist for each installed and enabled language,
regardless of whether there's already a notice stored in that language.
Test plan
1. Install Spanish by running koha-translate --install es-ES from inside
the kohashell
2. restart all
3. Set TranslateNotices to Allow
4. Verify that the Spanish-language sample_notices.yml exists
5. Open a notice that has at least one Spanish default notice defined
6. Confirm you see the 'View default' button for the spanish notice and
that the displayed notice is indeed the spanish translation
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a modal to preview the sample notices in the UI and
allow replacing the template content with that content of that modal.
Test plan
1) Apply patches and restart plack (Or just use a sandbox)
2) Login to the staff client and navigate to 'Tools > Notices and Slips'
3) 'Edit' a notice.
4) Note the new 'View default' button on some notices where we ship a
default in the 'sample_notices' file.
5) Click the button to view the sample notice
6) Confirm 'Close' just closes the modal
7) Confirm 'Copy' copies the sample notice into the editor field
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
1. In Administration - Patron attribute types verify you have the default
SHOW_BCODE using the YES_NO authorized value
2. Tools - Batch patron modification, add a patron card number or
borrowernumber and continue
3. For Patron attribute select Show barcode on the summary screen item
listings, and note that you get a blank text input rather than a select
menu with Yes and No choices
4. Apply patch, restart_all
5. Repeat step 2 and 3, but note that you now get a Yes/No select menu
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Same change.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Koha::Objects depends on Koha::DateUtils, which depends on C4::Context,
which depends on Koha::Config::SysPrefs, which depends on Koha::Objects
Apart from the circular dependency, the dependency on C4::Context alone
is problematic as it loads a bunch of modules that are not needed at all
in Koha::Objects (YAML::XS and ZOOM for instance).
As Koha::Objects is used as a base for a lot of modules, we should take
care to only load the minimum required.
This patch removes uses of Koha::DateUtils from Koha::Objects.
It was only used in Koha::Objects::filter_by_last_update
filter_by_last_update now requires that the 'from' and 'to' parameters
must be DateTime objects. Previously it would also allow date and
datetime strings. This possibility was only used in two places:
* misc/cronjobs/cleanup_database.pl
* tools/cleanborrowers.pl
Now they call dt_from_string first and pass a DateTime object to
filter_by_last_update
Test plan:
1. Run `perl -cw Koha/Objects.pm`. It should only say:
"Koha/Objects.pm syntax OK" without warnings
2. Run `prove t/db_dependent/Koha/Objects.t`
3. Verify that misc/cronjobs/cleanup_database.pl works as before,
especially with the options --pseudo-transactions,
--pseudo-transactions-from and --pseudo-transactions-to
4. Go to Tools » Batch patron deletion and anonymization, check "Verify
you want to anonymize patron checkout history" and enter a date in
the text input below. Then click Next and verify that the correct
count of borrowers is shown. Click on the "Finish" button and verify
that the circulation history has been correctly anonymized
See also bug 36432
Signed-off-by: Tadeusz Sośnierz <tadeusz@sosnierz.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the display of 'Default language' to the 'Default'
language in the notices editor tool.
This is so that librarians know which language they are expected to be
writing the notice in so we can remain consistent in both template and
include language used.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch ensures saving styles per notice still works as expected when the TranslateNotices system preference is enabled.
To test, enable the TranslateNotices system preference and attempt to save different CSS for each installed language for one notice. Confirm the correct CSS is saved for the correct language.
Confirm the CSS selector helpers are inserted into the textarea as expected.
Confirm the 'Apply format settings to all notices for this language' setting works, as in CSS is saved for all relevant language notices.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Save format settings for an individual notice, or for all notices
This patch implements a single style field for a slip to allow for advanced CSS customisation of printed notices. There are links to insert selectors as helpers. Styles can be applied for an individual notice, or all notices.
To test:
1. Apply the patches, install database updates, update schema if needed, and restart services
2. Go to Tools -> Notices and slips
3. Edit any notice
4. Go to the Format tab
5. Confirm there is a textarea for CSS, and links to insert helpful selectors for IDs like #receipt and #slip
6. Add some CSS and confirm it saves.
7. Test that 'apply these settings to all notices' option works. Test the confirmation box appears when this is checked.
8. Add a new notice and confirm CSS settings save successfully
9. The subsequent patches have specific testing plans for each printable notice. For each, confirm that SlipCSS stylesheet changes are applied first. Specific notice styles should be applied last.
10. Test with a non-HTML notice as well, such as RECALL_REQUESTER_DET. Plain (non_HTML) notices have always come with <pre> tags around them so the text is formatted slightly differently but any CSS from SlipCSS or the notice Format should still hold.
Sponsored-by: Colorado Library Consortium
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Create or modify an existing patron account so that they have a
value in their fax number field.
2. Go to Tools > Batch patron modification
1. Add the patron card number, or borrower number into the
modification tool and click on continue. There is no option for
modifying fax numbers, nor are fax numbers visible in the
modification table.
3. Apply the patch and restart_all
4. Repeat step 2
1. A column for ‘Fax’ is now visible after ‘Other phone’
2. Test the ‘Fax’ field by clearing out the field with the checkbox.
‘Checking the box right next to the label will disable the entry
and delete the values of that field on all selected patrons.’
3. Test the ‘Fax’ field by updating the value with a new number
5. Sign off and have a wonderful day :)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Go to Tools > Notices and slips
2. Pick any notice and try to copy it to another library using the 'Copy notice' column.
3. You are redirected to a blank screen and if you go back to the Notices and slips page the notice has not been copied.
4. APPLY PATCH
5. Try steps 1 - 3 again, but this time you should be correctly directed.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It's never used in the template anyway but for consistency it would be better to use "show" (it's not CUD)
No change expected.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If the user unchecks the skip checkbox (on by default), we must
make sure that order cancellation is done in background job.
Test plan:
Pick two biblios. One has linked open orders, the other not.
Go to batch delete records. Select 'Enter list of numbers'.
Enter both biblio numbers and check that only one is used on the
follow-up form.
Run the deletion without the skip open orders and verify
that linked order line is cancelled.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test Plan:
1) Test importing a patron with the "from the current membership expiry date" option,
note it does not work
2) Apply this patch
3) Restart all the things!
4) Re-test, note the expiration was renewed from the patron's current
expiration date!
Signed-off-by: David Nind <david@davidnind.com>
Rebased-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Allow both $op eq "show" and "cud-show".
We need to keep the POST when we upload a file, but we can simply allow
GET with "show".
Test plan:
Go to the biblio detail page, select an item and test both tools via the links
"Delete selected items" and "Modify selected items"
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Replacing a FIXME by TODO along the way.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We can use biblio.holds.count instead.
The main idea here is to make sure we are passing a Koha::Biblio object
as 'biblio' to all the templates including biblio-view-menu.inc
Test plan:
1. Go to the biblio detail view, click on the different entries in the menu
on the left. Confirm that the "Holds" tab always has the correct number
of Holds display in the parenthesis.
2. Run a search and confirm that the number of holds are still displayed
for each result.
QA:
git grep biblio-view-menu.inc
notice the tt list, open the corresponding perl controllers and confirm
that 'biblio' is passed and that it is a Koha::Biblio object.
The only missing place I found was in viewlog.
Note that we are not removing the TT method yet, we are marking it as
deprecated and also display a warning during the update DB process in
case one of the notice templates is using it.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch converts several delete links to POSTed forms and corrects
the op variable names in the script. The patch also simplifies the
deletion click handlers.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
- Get the CSRF token from the pop-up instead of from the parent window,
since that seems to work
- Remove some click handlers which were made obsolete
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes a number of changes to finish incomplete work in
668cd06e1960a3878ec1c976ce7f2e1f93688468
Initial submissions to batch biblio operations have to accommodate
POSTed file data, so this patch makes changes to instances where we were
submitting biblionumbers in a URL.
We could also choose to make a change in tools/batch_delete_records.pl
and tools/batch_record_modification.pl to handle different "list"
operations differently based on the method of submission. This patch
presents only the client-side option.
The cart presented a unique problem in that it requires that data be
passed from the pop-up window to the parent window, something which
can't as easily be done with a form as with a URL. The workaround I came
up with is to dynamically generate the form in the parent page and
trigger the submission from there.
Also changed:
- More updated CSS to handle buttons inside dropdowns inside toolbars.
- Correct op names for the "list" operation in batch modify and delete
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The "list" step (previewing records to be modified) is a post operation
so the op must be cud-list.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 34478: [TO SQUASH] tools/modborrowers
We actually want to POST here to not reach the limit of a GET request.
It also fixes the following warning in the console:
Form contains enctype=multipart/form-data, but does not contain method=post. Submitting normally with method=GET and no enctype instead.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Required some more changes for mode to op, and delete form.
Most forms did not need a POST.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
