Jonathan Druart [Fri, 5 Jan 2024 11:01:55 +0000 (12:01 +0100)]
Bug 35329: Move patron search to modal - edit-batch
Test plan:
Create new patron card batch
Keep the textarea empty and click "Add patron(s)" to open the modal
There is a special feature here, the "checkbox" column is displayed and
you can select several patrons and click "Add selected patrons".
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>
Jonathan Druart [Fri, 5 Jan 2024 11:10:33 +0000 (12:10 +0100)]
Bug 35329: Move patron search to modal - funds
This is a tricky one.
We can have several modals per page, patron-search.inc needs to be
adjusted to not use ids but classes. Also we need to declare JS
variables with 'var' instead of 'let' (which does not allow redefinition
of the same variable).
Test plan:
Create or modify a fund
"Select owner" and "Add users" to open the modals.
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>
Jonathan Druart [Fri, 5 Jan 2024 07:13:29 +0000 (08:13 +0100)]
Bug 35329: Move patron search to modal - basket
Add user to an acquisition basket
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>
Jonathan Druart [Thu, 4 Jan 2024 15:44:39 +0000 (16:44 +0100)]
Bug 35329: Move patron search to modal - neworderempty
Test plan:
Create a new acquisition order and add users.
FIXME:
Note that rules for .modal-dialog .dialog.message need to be adjusted.
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>
Jonathan Druart [Thu, 4 Jan 2024 15:13:49 +0000 (16:13 +0100)]
Bug 35329: move patron search to modal - Add guarantor
This is the first of many patches to come.
We will rewrite the patron search popup to convert it to a Bootstrap's modal.
I faced different problems on different pages, it is preferable to test
each page on top of the whole patchset, to make sure a futur change will
not break previous pages (and this is why they are all on the same bug
report).
For each page we will test that:
* the different filters work
* the "Clear" filters button work
* the "Add" or "Select" patron button works
* the nested modal to display patron's details (when clicking on their
name or cardnumber) works
On this patch we are testing the guarantor search:
Create a edit a patron and click "Add guarantor" to open the modal.
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>
Jonathan Druart [Mon, 26 Feb 2024 10:29:17 +0000 (11:29 +0100)]
Bug 36148: Do not deal with CSRF error in get_template_and_user
We deal with that in the middleware, we don't want 403.pl to early exit.
If we notice that we actually need it (for other scripts), we could
eventually add a new flag to get_template_and_user to skip the CSRF check,
or build the template without using get_template_and_user for errors/*
scripts.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
David Cook [Fri, 23 Feb 2024 05:05:30 +0000 (05:05 +0000)]
Bug 36148: Allow Koha::Middleware::CSRF to use error/exception middlewares
This change allows Koha::Middleware::CSRF to use the ErrorDocument and
HTTPExcetions middlewares to display the correct status codes and HTML
documents.
Leveraging Plack environmental variables, we're also able to pass along
data to the error page handlers to show warnings indicating that there
was a missing CSRF token.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Thu, 22 Feb 2024 14:16:08 +0000 (15:16 +0100)]
Bug 36148: Move CSRF check to a Plack middleware
The easiest here is to not empty 'op' but instead redirect to an error
page.
Minor changes: to keep the patch simple it removed the 'dev only' error and
display the error for non-dev installs. It should not be a problem
anyway and will prevent errors to be hidden in the log.
We could make KOHA_ERROR an arrayref, but later (we don't need it now
anyway).
Note that the OPAC still not benefit from a friendly specific error for
invalid token.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Fri, 23 Feb 2024 11:15:42 +0000 (12:15 +0100)]
Bug 36084: svc - renew
Material - The code that is supposed to replace the checkbox with a text
was not at the correct place. It should be with checkin, not renewal.
With the table refresh it does not make sense to keep it as we will
never see it.
Best is to replace the checkbox with the text directly.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Wed, 21 Feb 2024 10:46:42 +0000 (11:46 +0100)]
Bug 36084: svc - cover_images
Removing the ability to remove several cover images, it was not used.
FIXME - Note that I am getting randomly a failure when uploading an image and
seeing the following error in the log:
[Wed Feb 21 10:43:59.168934 2024] [cgi:error] [pid 24037] [client 172.18.0.1:45074] AH01215: Use of uninitialized value $fileID in bitwise and (&) at /kohadevbox/koha/tools/upload-cover-image.pl line 101.: /kohadevbox/koha/tools/upload-cover-image.pl, referer: http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=1
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
David Cook [Wed, 21 Feb 2024 06:17:50 +0000 (06:17 +0000)]
Bug 36084: Add CSRF token support to svc/authentication
GET svc/authentication will return a CSRF token in a response header
POST svc/authentication requires a CSRF token which can be sourced
from the response header of GET svc/authentication or some other
place like the meta element on a HTML page
Note: misc/migration_tools/koha-svc.pl is a simple script which
can be used to practically evaluate svc/authentication and svc/bib
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Tue, 20 Feb 2024 09:00:11 +0000 (10:00 +0100)]
Bug 36084: Fix is_ajax by setting X-Requested-With header
Some svc scripts (and controllers) are using using is_ajax to guess if
it's an AJAX request.
$.ajax is setting the (non standard) X-Requested-With header, but the
low level JS 'fetch' does not.
This patch set it in http-client.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Tue, 13 Feb 2024 14:08:25 +0000 (15:08 +0100)]
Bug 36084: Bring fetch for everywhere
We are retrieving the awesome fetch modules from Vue, so that it can be
used in other areas. Here we will use it to inject the CSRF token to the
header of every POST request.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Mon, 12 Feb 2024 16:36:44 +0000 (17:36 +0100)]
Bug 36084: C4::Auth+plack.psgi for svc?
Suggestion to move the CSRF check to CGI->new so that we will check it
for every request, and it will cover svc scripts as well (they are not
using get_template_and_user).
The token will be retrieve from the param list *or the csrf_token
header* (do we want to name it x-koha-csrf-token instead?).
This will be done for *every* request that are not GET: CSRF token is now
required everywhere CGI is used (side-effects possible?).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Tue, 20 Feb 2024 10:03:37 +0000 (11:03 +0100)]
Bug 36102: (follow-up) Add cud-login to the login form
Hum this didn't make sense. We are not checking credentials after
checkauth.
This patch is suggesting to rename "userid" and "password" parameters
from login forms to "login_userid" and "login_password" to not interfere
with other parameters with the same name.
This looks quite correct, however I am seeing
"The form submission failed (Wrong CSRF token)."
in the log after a successful login. Which feels wrong, what's
happening?
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Thu, 15 Feb 2024 13:06:33 +0000 (14:06 +0100)]
Bug 36102: Fix 01-installation.t
Something very weird is happening here.
There is a FIXME already, but the trick does not seem to work anymore
(?)
This patch contains some debug statements and take some screenshots.
We are reaching the cud-selectframeworks step then we are expecting the
form to submit the form with op=cud-addframeworks
BUT it seems that "op" is empty, and there is an unexpected warning from
Starman:
==> /var/log/koha/kohadev/plack-error.log <==
""
Use of uninitialized value in string ne at /usr/share/perl5/Starman/Server.pm line 304.
==> /var/log/koha/kohadev/plack-intranet-error.log <==
[2024/02/15 13:09:34] [WARN] Warning: something's wrong at /kohadevbox/koha/installer/install.pl line 89.
What's going on here??
UPDATE: This is fixed by "Bug 34478: Manual fix - Make Koha::Token use
session id not userenv id"
Bug 36102: [TO SQUASH] Fix 01-installation.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Fri, 23 Feb 2024 15:30:22 +0000 (15:30 +0000)]
Bug 34478: Fixes for MARC modification template management
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>
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>
Owen Leonard [Thu, 22 Feb 2024 12:10:16 +0000 (12:10 +0000)]
Bug 34478: Fix style and markup of forms within dropdowns
This patch adds some CSS for handling the style of form buttons inside
Bootstrap dropdowns and corrects related markup in two places: Authority
search results and Suggestion management.
Buttons should look correct if we avoid using <fieldset> inside
dropdowns and make sure the button has "btn btn-default" classes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
projects / koha.git / log