The unit tests were written to assume we always do a 'contains' search,
but the new system preference allows for 'starts_with' or 'contains'.
As such, for the tests to pass, we need to explicitly mock the
preference to 'contains'
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit b787e66fef)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 9f4e9f451b)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit dfed7f235d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
These are not needed: 942 and 200 have no subfields for
homebranch and holdingbranch.
The tests pass without these changes.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Items without a home and current library can cause errors in Koha.
On the bibliographic page, items appear without the "edit" drop-down
or the selection check box. On a bulk delete page, items without
a home library create a red error that says "Cannot delete".
Making the home and current library values mandatory
helps avoid these issues.
Test plan (using koha-testing-docker (KTD)):
1. Reset KTD so that the web installer is used to setup Koha.[1]
2. Setup Koha using the web installer
-> When setting up the default settings, don't add any of the
optional data.
3. Once setup and logged in, check the two frameworks (default and ACQ)
and note that $952$a and $952$b are not mandatory.
4. Apply the patch.
5. Repeat steps 1-2.
6. Once setup and logged in, check the two frameworks (default and ACQ)
and note that $952$a and $952$b are now mandatory.
[1] How to access the web installer to setup Koha in KTD:
1. Access the database server:
mysql -uroot -ppassword -hkoha-db-1
2. Drop the koha_kohadev database: drop database koha_kohadev;
3. Create the database: create database koha_kohadev;
4. Add privileges (for a real installation this would be limited):
grant all on koha_kohadev.* to koha_kohadev;
5. Restart everything (there may be some errors listed):
flush_memcached and then restart_all
6. Access the web installer: go to 127.0.0.1:8081
7. Use the database user name and password:
get from /etc/koha/sites/kohadev/koha-conf.xml
(default: koha_kohadev, password)
8. Continue through the installation process.
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>
The test was checking for the value of an input field.
But with this patch set, there is no longer an input, but
a link element with the title. This adjusts the patch to look
for the correct element.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a missing wait_for_ajax. After we click "next", we need to make
sure we are using the correct response.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We should not rely on existing data, and we should remove data at the end.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds a new Selenium test to automatically test the correct
behaviour when expanding/collapsing System preferences sections
after a System preferences search.
Test plan:
1) Apply the other patch from this bug report, then run the
new Selenium unit test which should pass without failures:
prove -v t/db_dependent/selenium/system_preferences_search.t
Signed-off-by: Fridolin <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This was for debugging purpose.
Test plan:
Run the tests and confirm that the screenshot is not generated when the
patch is applied
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If we are waiting for ajax (there is a sleep 1s) and the alert pops up
at the same time, Selenium is raising "unexpected alert open"
We should not wait for the ajax request, but better wait for the
alert actually.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There is a missing wait_for_ajax call at after we click but wait_for_ajax
is waiting for the return of success, and the alert is there.
22:01:57 koha_1 | STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...}
22:01:57 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try
22:01:57 koha_1 | (eval 541):1 in Selenium::Remote::Driver::__ANON__
22:01:57 koha_1 | (eval 543):2 in Selenium::Remote::Driver::__ANON__
22:01:57 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:654 in Selenium::Remote::Driver::_execute_command
22:01:57 koha_1 | t/db_dependent/selenium/authentication_2fa.t:282 in Selenium::Remote::Driver::get_alert_text
22:01:57 koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in main::__ANON__
22:01:57 koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in (eval)
22:01:57 koha_1 | /usr/share/perl/5.32/Test/More.pm:809 in Test::Builder::subtest
22:01:57 koha_1 | t/db_dependent/selenium/authentication_2fa.t:291 in Test::More::subtest
22:01:57 koha_1 |
22:01:57 koha_1 | # Looks like you planned 7 tests but ran 4.
22:01:57 koha_1 |
22:01:57 koha_1 | # Failed test 'Enforce 2FA setup on first login'
22:01:57 koha_1 | # at t/db_dependent/selenium/authentication_2fa.t line 291.
22:01:57 koha_1 | Error while executing command: no such alert at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
22:01:57 koha_1 | at /usr/share/perl5/Selenium/Remote/Driver.pm line 356.
22:01:57 koha_1 | # Looks like your test exited with 255 just after 4.
22:01:57 koha_1 | [20:59:37] t/db_dependent/selenium/authentication_2fa.t
Test plan:
Confirm that the test pass (execute it in a loop, hundreds of times)
Confirm that the behaviour of 2FA "enforced" (see bug 30588) is still
working as expected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Error while executing command: no such element: Unable to locate element: //*[@id="circ_returns_checkin"]/div[2]/div[1]/div[2]/button at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Cannot wait more for element '//input[@type="submit"]' to be visible at /kohadevbox/koha/t/lib/Selenium.pm line 189.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We need to replace 0 with 'disabled', and 1 with 'enabled'
Sponsored-by: Rijksmuseum, Netherlands
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is a deadlock I think. Any ideas how we could continue to test that
in any conditions?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Sponsored-by: Rijksmuseum, Netherlands
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 28786 let librarians enable a Two-factor authentication but force them to use
an application to generate the TOTP token.
This new enhancement add the ability to send an email containing the token to the
patron once it's authenticaed
The new notice template has the code '2FA_OTP_TOKEN'
Test plan:
- Setup the two-factor authentication (you need the config entry and the
syspref ON)
- Enable it for your logged in patron
- Logout
- Login and notice the new link "Send the code by email"
- Click on it and confirm that you received an email with the code
- Use the code to be fully logged in
QA question: Is 400 the correct error code to tell the email has not
been sent?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Sponsored-by: Rijksmuseum, Netherlands
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Now that we have made item.itype a required field, we need to ensure we
set it for the corresponding selenium test.. this wasn't entirely easy
as the html select is hidden by select2. I had to find the select2 span,
trigger a click event to open it and then find and click an option.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We need to create an itemtype for the biblio, then the item form will
have 942$c prefilled by default
STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...}
/usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try
(eval 1726):1 in Selenium::Remote::Driver::__ANON__
(eval 1728):2 in Selenium::Remote::Driver::__ANON__
/usr/share/perl5/Selenium/Remote/Driver.pm:953 in Selenium::Remote::Driver::_execute_command
t/db_dependent/selenium/basic_workflow.t:224 in Selenium::Remote::Driver::get_title
Error while executing command: unexpected alert open: Dismissed user prompt dialog: Form not submitted because of the following problem(s)
------------------------------------------------------------------------------------
- 1 mandatory fields empty (highlighted) at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Error while executing command: element not interactable: Element <input id="tag_952_subfield_w_810691" class="input_marceditor items.replacementpricedate noEnterSubmit flatpickr-input" name="items.replacementpricedate" type="hidden"> is not reachable by keyboard at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
Not sure if it's coming from bug 30717 or not. git bisect told me it was the culprit but we released 22.05 and it seems that we got basic_workflow.t green since then.
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>
Change of text from "pin" to "PIN" in the 2FA setup interface.
This slight changes clarifies that "PIN" is an acronym,
and increases user comprehension
To test:
1) Log in as an Administrator
2) Enable TwoFactorAuthentication
3) Log in to a user with superlibrarian permissions.
4) On the user profile page, click the "More" dropdown button,
click "Manage Two-Factor
5) Check that "pin" is displayed in lowercase, in both instances.
6) Apply patch.
7) Refresh the page and observe that "pin" has changed to "PIN"
8) Sign off.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Run:
$ kshell
k$ prove t/db_dependent/selenium/regressions.t
=> FAIL: You see several
item-level_itypes set but no itemtype set for item (985) at /kohadevbox/koha/Koha/Schema/Result/Item.pm line 905.
2. Apply this patch
3. Repeat 1
=> SUCCESS: No more item type warnings
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The tab title words were re-ordered and we forgot to update the
corresponding selenium test.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If several terms are passed we should split them.
Test plan:
Search for "edna acosta" (without quotes) in the filters from the left
side of the main patron search
Do some regression tests
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
Run t/db_dependent/selenium/authentication_2fa.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The unit tests highlighted my original patch didn't cover the full
preference description.
We now replace the 'standard' option with the fields from the preference
and we also add those fields as options to the field selection in
advanced searches.
This patch also adjusts the tests to test for that and reflects the
expected changes to the number of options displayed in the select boxes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
t/db_dependent/selenium/update_child_to_adult.t .. # Looks like you planned 3 tests but ran 2.
# Failed test 'Update child to adult'
# at t/db_dependent/selenium/update_child_to_adult.t line 132.
# Looks like you planned 3 tests but ran 2.
# Looks like you failed 1 test of 2 run.
t/db_dependent/selenium/update_child_to_adult.t .. 1/1
# Failed test 'Update child to patron'
# at t/db_dependent/selenium/update_child_to_adult.t line 153.
Cannot wait more for element '//input[@type="submit"]' to be visible at /kohadevbox/koha/t/lib/Selenium.pm line 189.
It happens when there are too many patron's categories and the submit
button is not in the viewport.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patchset introduces the Two-factor authentication (2FA) idea in
Koha.
It is far for complete, and only implement one way of doing it, but at
least it's a first step.
The idea here is to offer the librarian user the ability to
enable/disable 2FA when logging in to Koha.
It will use time-based, one-time passwords (TOTP) as the second factor,
an application to handle that will be required.
https://en.wikipedia.org/wiki/Time-based_One-Time_Password
More developements are possible on top of this:
* Send a notice (sms or email) with the code
* Force 2FA for librarians
* Implementation for OPAC
* WebAuthn, FIDO2, etc. - https://fidoalliance.org/category/intro-fido/
Test plan:
0.
a. % apt install -y libauth-googleauth-perl && updatedatabase && restart_all
b. To test this you will need an app to generate the TOTP token, you can
use FreeOTP that is open source and easy to use.
1. Turn on TwoFactorAuthentication
2. Go to your account, click 'More' > 'Manage Two-Factor authentication'
3. Click Enable, scan the QR code with the app, insert the pin code and
register
4. Your account now requires 2FA to login!
5. Notice that you can browse until you logout
6. Logout
7. Enter the credential and the pincode provided by the app
8. Logout
9. Enter the credential, no pincode
10. Confirm that you are stuck on the second auth form (ie. you cannot
access other Koha pages)
11. Click logout => First login form
12. Enter the credential and the pincode provided by the app
Sponsored-by: Orex Digital
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>
Some selenium tests are not correctly written and they fail is
Selenium::Remote::Driver is missing.
Test plan:
1. Remove the lib rm `pmpath Selenium::Remote::Driver`
2. prove t/db_dependent/selenium/
should return green
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Run prove t/db_dependent/selenium/regressions.t on KTD with selenium
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Recreated the problem after run #47
Error while executing command: no such element: Unable to locate element: //*[@id="userid"] at /usr/local/share/perl/5.28.1/Selenium/Remote/Driver.pm line 411.
With this patch I do not longer recreate the failure. It's ugly but,
well, I don't have any other solutions. It seems that the accept_alert
is taking too long and is async (??)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
