It's caused by a version mismatch of Test::MockModule with D10,
which does not have this commit: fef9e742e4
We should remove the chaining here.
Test plan:
Confirm that Auth.t still pass, and is fixed on D10
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit d3b4edf009)
Signed-off-by: Jacob O'Mara <jacob.omara@ptfs-europe.com>
(cherry picked from commit b36b7d5751)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 3622b51abb)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
When there is no item, you cannot safely delete it :)
Resolve this warning:
Can't call method "safe_delete" on an undefined value at /usr/share/koha/cataloguing/additem.pl line 379
(Line numbers may vary across versions.)
Test plan:
Open item editor.
Add a new item.
Add another tab with same form. Delete new item.
Go back to former tab. Try to delete again.
You should see an alert now on top of the form.
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: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 7d8a35585b)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 65d267dd90)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
The authentication.t selenium tests (and a couple of others) were
failing with:
Error while executing command: element not interactable: Element <input class="btn btn-primary" type="submit"> could not be scrolled into view at /usr/local/share/perl/5.32.1/Selenium/Remote/Driver.pm line 411. at /usr/local/share/perl/5.32.1/Selenium/Remote/Driver.pm line 356.
We changed the other of the form, and t::lib::Selenium::submit_form was
not getting the correct (first) form. The one from the auth modal was
retrieved and submit button was clicked. Selenium raised an error as it
is not displayed.
The ->is_displayed selenium method does not work, as per the doc
"""
Note: This does *not* tell you an element's 'visibility' property; as it still takes up space in the DOM and is therefore considered 'displayed'.
"""
https://metacpan.org/pod/Selenium::Remote::WebElement#is_displayed
"The internet" is saying we should be able to use the following in our
xpath expression: not(ancestor::div[contains(@style,'display:none')]
but it actually only works if the display:none rule is defined on the
node (not from .css). Which does not work for us.
The only solution I found is to check for the size of the element, which
is (0,0) if not effectively displayed.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 5520b8fb84)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
If a second login on top of a current session fails on
permissions, we should not grant access without context.
Test plan:
[1] Run t/db../Auth.t, it should pass now.
[2] Test interface with/without this patch:
Pick two users: A has perms, B has not.
Put two staff login forms in two tabs.
Login as A in tab1. Login as B in tab2.
Without this patch, B gets in and crashes.
With this patch, B does not get in ('no perms').
Bonus: Go to opac if on same domain. You are still
logged in as B.
NOTE: I added a FIXME here, since you could argue about filling
the session info or otoh deleting the session. We present an
authorization failure; people may not realize that they are
still logged in (see test plan - bonus).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 0cc7c4991c)
Test plan:
Without follow-up patch, Auth.t should fail:
not ok 5 - No permission response
not ok 6 - checkauth returned failure
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit a1134bfd8a)
Somewhere the line undef $userid got removed.
We need it to resolve the second login situation.
Test plan:
Login in staff with user missing privileges.
On the login form login again with another staff user.
Note that you do no longer crash.
Run t/db../Auth.t
Run t/db../Koha/Auth/TwoFactorAuth.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 2d0a2c44e7)
Test plan:
Without next patch, run Auth.t.
Should fail now before next patch resolves problem:
not ok 2 - Login of patron2 approved
ok 3 - Did not return previous session ID
not ok 4 - New session ID not empty
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit d916250d31)
No change in user experience. But since we can mock safe_exit,
we can enhance test results.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 7373a1e414)
If a second login on top of a current session fails on
permissions, we should not grant access without context.
Test plan:
[1] Run t/db../Auth.t, it should pass now.
[2] Test interface with/without this patch:
Pick two users: A has perms, B has not.
Put two staff login forms in two tabs.
Login as A in tab1. Login as B in tab2.
Without this patch, B gets in and crashes.
With this patch, B does not get in ('no perms').
Bonus: Go to opac if on same domain. You are still
logged in as B.
NOTE: I added a FIXME here, since you could argue about filling
the session info or otoh deleting the session. We present an
authorization failure; people may not realize that they are
still logged in (see test plan - bonus).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 0cc7c4991c)
Test plan:
Without follow-up patch, Auth.t should fail:
not ok 5 - No permission response
not ok 6 - checkauth returned failure
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit a1134bfd8a)
Somewhere the line undef $userid got removed.
We need it to resolve the second login situation.
Test plan:
Login in staff with user missing privileges.
On the login form login again with another staff user.
Note that you do no longer crash.
Run t/db../Auth.t
Run t/db../Koha/Auth/TwoFactorAuth.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 2d0a2c44e7)
Test plan:
Without next patch, run Auth.t.
Should fail now before next patch resolves problem:
not ok 2 - Login of patron2 approved
ok 3 - Did not return previous session ID
not ok 4 - New session ID not empty
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit d916250d31)
No change in user experience. But since we can mock safe_exit,
we can enhance test results.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 7373a1e414)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit ae986b992d)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 2438b04076)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.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 a39ecfd7f7)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 6132f9708d)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
It would be nice to be able to combine several types in a single run,
but exclude others, without having to have multiple cron lines
Test Plan:
1) Apply this patch
2) Run process_message_queue.pl with a single -c parameter
3) Note behavior is unchanged
4) Run process_message_queue.pl with multiple -c parameters
5) Note all the codes specified are processed
6) Repeat 2-5 with -t for type limits
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit da7bcc2252)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit b51e6cd465)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
This patch makes a minor modification to the OPAC
search results RSS template so that an error isn't
triggered. The html_helpers include was missing.
To test, apply the patch and perform a catalog
search in the OPAC which will return results.
At the end of the "Your search results" heading
you should see an orange RSS icon. Clicking on it
should take you to an RSS feed instead of an
error page.
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>
(cherry picked from commit 2621f28376)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 5e6d1a10bb)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
This patch removes some obsolete code for selecting a default authorized
value category to be shown when the user first arrives on the authorized
values page. This has not been necessary since we switched to an
interface which lists all categories.
NOTE: This bug will not be reproducible if your first authorized value,
alphabetically, has no values associated with it. For instance, if you
delete all authorized values in the AR_CANCELLATION category.
To test, apply the patch and go to Administration -> Authorized values.
In the breadcrumbs menu you should see "Home -> Administration ->
Authorized values."
Clicking any of the authorized value categories in the list should take
you to a view of that category's values.
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 0ec29e5d4e)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 0b0dcefd5a)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
We are seeing the following lines several times in the codebase
$cache->clear_from_cache("default_value_for_mod_marc-");
But values are never set for this key.
Test plan:
Ask you, "Is the above correct?"
Use the correct 'git grep' and 'git log' and confirm the assertion.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 93d44d1875)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 867c03bf6a)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
The test
$MARCfrom->field('1..', '2..'))[0]->tag ne ($MARCto->field('1..', '2..'))[0]->tag
is not completely consistent with following code in sub merge.
I decided to get the authtype code from the old record that comes
from Koha and should include the type.
Remaining changes refer to indentation/comments.
Test plan:
Run t/db_dependent/Authority/Merge.t
Note: The test actually could be extended a bit for mocking MARC
flavor, but needs some additional framework support to work.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit d7d33744ba)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 90e4cdb752)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
In those rare cases when authorities are updated by an external agency (or
even internally, by reviewing and correcting an exported authority file)
when the heading tag will be changed (seems odd but happens:
111 Congress ==> 110 Corporate body.Congress ;
100 Person ==> 110 Corporate body (a company named with person's name ;
151 City--object ==> 150 Object (city) etc.)
and then the authority record in Koha database will be updated with
bulkmarcimport or by calling directly ModAuthority from a custom script,
the merge function "doesn't know" that the change to the authority type
has been made and, consequently, doesn't adequately change the tag in
related fields in biblio records (as it would if two different records
with different authtypecode were merged with Koha interface).
This is because at the moment when merge function is being called
by ModAuthority:
Koha::Authority::Types->find($autfrom->authtypecode)
Koha::Authority::Types->find($authto->authtypecode)
both have the same value (because $mergefrom == $mergeto).
Therefore in case when $mergefrom == $mergeto and the heading tag changes,
$authtypefrom and $authfrom calculated in merge in the ordinar way are
misleading and should not be taken unto consideration.
Test plan:
==========
1. run t/db_dependent/Authority/Merge.t
2. you should see problems in "Test update A with modified heading tag
(changing authtype)"
3. apply the patch
4. run t/db_dependent/Authority/Merge.t again
5. the test should pass
Alternatively:
1. have an authority record used in biblio;
export it to file;
change 1XX heading tag to a different (but reasonable) value
and possibly change also the content of the heading
(one can delete also 942 but it doesn't matter);
make bulkmarcimport.pl -a -update -file <modified_auth_file> and
see that the tag in biblio record has not been changed (whereas
the type of authority record did change);
2. make orders in database (so that the authority type and the tag of
the field in biblio record correspond); apply the patch;
3. repeat the test from 1.
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>
(cherry picked from commit 03da66ce20)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 3cf8c3881d)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
In those rare cases when authorities are updated by an external agency (or
even internally, by reviewing and correcting an exported authority file)
when the heading tag will be changed (seems odd but happens:
111 Congress ==> 110 Corporate body.Congress ;
100 Person ==> 110 Corporate body (a company named with person's name ;
151 City--object ==> 150 Object (city) etc.)
and then the authority record in Koha database will be updated with
bulkmarcimport or by calling directly ModAuthority from a custom script,
the merge function "doesn't know" that the change to the authority type
has been made and, consequently, doesn't adequately change the tag in
related fields in biblio records (as it would if two different records
with different authtypecode were merged with Koha interface).
This is because at the moment when merge function is being called
by ModAuthority:
Koha::Authority::Types->find($autfrom->authtypecode)
Koha::Authority::Types->find($authto->authtypecode)
both have the same value (because $mergefrom == $mergeto).
Therefore in case when $mergefrom == $mergeto and the heading tag changes,
$authtypefrom and $authfrom calculated in merge in the ordinar way are
misleading and should not be taken unto consideration.
Test plan:
==========
1. run t/db_dependent/Authority/Merge.t
2. you should see problems in "Test update A with modified heading tag
(changing authtype)"
3. apply the patch
4. run t/db_dependent/Authority/Merge.t again
5. the test should pass
Alternatively:
1. have an authority record used in biblio;
export it to file;
change 1XX heading tag to a different (but reasonable) value
and possibly change also the content of the heading
(one can delete also 942 but it doesn't matter);
make bulkmarcimport.pl -a -update -file <modified_auth_file> and
see that the tag in biblio record has not been changed (whereas
the type of authority record did change);
2. make orders in database (so that the authority type and the tag of
the field in biblio record correspond); apply the patch;
3. repeat the test from 1.
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>
(cherry picked from commit 4d75a9b3b7)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 1ac516addb)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=31559
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 6cc3a85eb1)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 246ee24210)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
This patch restores the option to keep current budget, in the case that receiver can receive, but cannot order on current budget
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=31559
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit b86e5b5423)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit c005ef2108)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
This patch adds a level to the budget_loops and displays the budgets
as optgroups for the funds
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=31559
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 2a22c13cf3)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 63a5684020)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Current order receive code loops over each budget period and gets the hierarchy, this
is slow when systems have many budgets. Additionally, the list includes inactive items
by default
We can switch to a single call, and add consistency by adopting the same dropdown as used
when placing an order
To test:
1 - Add some budgets with funds - ensure you have at least one inactive budget and fund
2 - Place an order, observe the fund selection menu
3 - Close basket, receive order, observe the fund menu
4 - Apply patch
5 - Cancel receipt
6 - Receive again
7 - Observe fund menu, confirm it matches the order placing menu
8 - Confirm inactive are not displayed by default, but are when button is checked
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=31559
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 24e7703aef)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 382e80b737)
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Jonathan Druart
Marcel de Rooy
Arthur Suzuki
Tomas Cohen Arazi
Martin Renvoize
Koha translators
Nick Clemens
Kyle M Hall
Owen Leonard
Janusz Kaczmarek
Katrin Fischer