Test plan:
= Koha =
Apply the first patch, prove xt/vue_tidy.t and notice the failure
Apply this patch, now it passes
= QA test =
Apply the change to the merge request linked with this qa-test-tools' issue:
https://gitlab.com/koha-community/qa-test-tools/-/issues/62
inside your ktd container (at /kohadevbox/qa-test-tools/)
Edit a .js within koha-tmpl/intranet-tmpl/prog/js/vue and a .ts file
(cypress test) with something not pretty
Commit and run the QA script
=> It's failing!
Pretty the change, commit again, run the QA script
=> It's happy!
= KTD - git hook =
Go to the merge request linked with this ktd's issue:
https://gitlab.com/koha-community/koha-testing-docker/-/issues/374
Copy the modified git hook to .git/hooks/ktd/pre-commit
Edit a .js within koha-tmpl/intranet-tmpl/prog/js/vue and a .ts file
(cypress test) with something not pretty
Commit
=> Notice that the commit content is pretty!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes ModItemTransfer trigger record indexing only on the
last call (in $transfer->transit). And extra parameter is added to
->transit to effectively honour the ModItemTransfer parameter.
I wanted to mention that bug 31212 highlighted an existing issue, not
catched by the current tests before its inclussion, because of the DT truncation
taking place.
To test:
1. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/SearchEngine/Indexer.t
=> FAIL: Indexing is requested twice, should only be once
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass! Indexing is requested only once!
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Search.t is failing if run after Filter_MARC_ViewPolicy.t because of a
missing flush
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
koha_1 | # Failed test 'Expected permissions generated for superlibrarian'
koha_1 | # at t/Koha/Auth/Permissions.t line 283.
koha_1 | # Structures begin differing at:
koha_1 | # $got->{CAN_user_lists_edit_public_list_contents} = '1'
koha_1 | # $expected->{CAN_user_lists_edit_public_list_contents} = Does not exist
koha_1 | # Looks like you failed 1 test of 1.
koha_1 |
koha_1 | # Failed test 'superlibrarian tests'
koha_1 | # at t/Koha/Auth/Permissions.t line 284.
koha_1 | # Looks like you failed 1 test of 3.
koha_1 | [23:34:42] t/Koha/Auth/Permissions.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
With this patch the new status Circulating, Out for binding and
Bound can be set for any issue, if the current status is not "Expected".
This is to keep the list a little shorter when the issue hasn't even
arrived in the library yet.
These new status will be especially helpful if the library has
opted to not create items for all their subscriptions as a lot
of libraries will only lend bound volumes, but not the singular
issues.
* Circulating: this will be useful if the library is using
routing lists and the items are not available at the library
for a longer time.
* Out for binding: if you send out issues for binding this will
help to track these.
* Bound: this will help users to know that the issue is now
available as a bound volume.
To test:
* If you haven't yet:
* Create a subscription
* From the serial collection page:
* Receive or create several issues and set different status
* Make sure you have at least 2 late and claim one of them
* Make sure you have several Arrived issues
* Edit Arrived serial issues and others
* Verify that the status pull down no also shows the new status
if the issue has a different status than "Expected"
* Set the new status
* Verify they save and show correctly
* Edit again and verify the pull downs are pre-set correctly
to the saved status
* Verify they show everywhere else (see previous test plans :) )
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test with the next patch that allows to set the new status.
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This moves the identical code used to display the serial status
from the different templates into one common include.
To test:
* Add a subscription
* Receive several issues, make sure 2 are late
* Claim one of the late issues
* Verify the status displays nicely on these pages:
* Subscription detail page > issues tab
* Catalog detail page > subscription tab
* Serial claims page
* Serial collection page of your subscription
Note: there was some code for the subscription detail page
that should have displayed the claim date, but didn't work.
To keep things simpler and identical to before, I have left
that bit out for now.
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This moves the existing status in the OPAC into an include.
To test:
* Add a subscription with issues in different status
* View the OPAC detail page of the record
* Verify that in the subscription tab the status display nicely
* Veriy that More details > Full history displays the status nicely too
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds another list item to match the preference description
for the results page:
* Empty. No XSLT will be applied (default)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Atomic updated fixed : intranet => OPAC
Changed to be more like the one adding AuthorityXSLTOpacResultsDisplay
New preference moved to opac.pref
Signed-off-by: Thibault <thibault.keromnes@univ-paris8.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Thibault <thibault.keromnes@univ-paris8.fr>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a syspref that allow to customize the authority detail
view in OPAC with XSLT.
Test plan:
1. Make sure to have at least one or more authorities
2. OPAC: Home > Authority search(Submit) > Authority search results
3. Click details on a result and notice the view
4. Apply patch
5. INTRA: Home > Administration > System preferences ->find
"AuthorityXSLTOpacDetailsDisplay"
6. Write the path where your file is. You can try with the XSLT for
biblio for instance:
.../koha/koha-tmpl/opac-tmpl/bootstrap/en/xslt/UNIMARCslim2OPACDetail.xsl
7. Save changes
8. Repeat 2-3 and notice the display
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Thibault <thibault.keromnes@univ-paris8.fr>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the ability to send selected patrons for batch
modification. It does this by adding a hidden form which is populated
from the borrowernumbers stored in the browser's localStorage when
selections are made.
To test, apply the patch and perform a patron search in the staff client
which will return multiple pages of results.
- Select a patron on the first page of results.
- The "Add to patron list" and "Batch patron modification" buttons
should become active, and the "Patrons selected" box should show "1"
- After checking another checkbox the "Merge selected patrons" button
should activate and the "selected" count should increment.
- Test making selections on other pages of results. The "selected" count
should continue to increment.
- Test the "Batch patron modification" button, confirming that all the
patrons you selected are correctly passed to the batch patron
modification tool.
- Test that the "Clear" control works correctly to clear all checkboxes
and disable all other buttons.
- Test that the "Select all" and "Clear all" controls work correctly,
enabling all buttons and correctly incrementing the "selected" count.
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The 'Allow changes to contents from' dropdown when creating/edit lists
should be most locked down to least locked down:
1. Nobody
2. Owner only
3. Permitted staff only
4. Staff only
5. Anyone seeing this list
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Run unit tests
sudo koha-shell <instance>
prove t/db_dependent/Koha/Patron.t
prove t/db_dependent/Virtualshelves.t
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Public lists with 'Allow changes to contents from' = 'Permitted staff only'
can have their contents managed by Koha patrons with either of the
permissions below:
- superlibrarian permission
- catalogue permission + 'edit_public_list_contents' sub-permission
Test plan:
1. Apply patches, update database, restart services
2. In the staff client go to: Lists > New List
3. Create a list, choose 'Allow changes to contents from' => 'Permitted
staff only'
4. Log into the OPAC as a patron with no permissions.
5. Confirm you CANNOT add a biblio to the list from the OPAC search result page and
OPAC biblio detail pages
6. Log into the OPAC as a patron with only the 'catalogue' permissions
enabled
7. Confirm you CANNOT add a biblio to the list from OPAC search result
or biblio detail pages
8. Log into the OPAC as a patron with the 'catalogue' and
'edit_public_list_contents' permissions enabled
9. Confirm you CAN add/remove biblios from the OPAC search result and
biblio detail pages
10. Log into the OPAC as a patron with superlibrarian permissions
11. Confirm you CAN add a biblio to the list from the OPAC search result
page and OPAC biblio detail pages
12. Log into the staff client as a patron with only the
'catalogue' permission and confirm you CANNOT add/remove records from the
list
13. Log into the staff client as a patron with the 'catalogue' and
'edit_public_list_contents' sub-permission (found under 'Lists' parent
permission)
14. Confirm you CAN add/remove records from the list
15. Login into thestaff client as a patron with 'superlibrarian'
permissions and confirm you CAN add/remove records from the list
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Apply first patch
2. Install en-NZ and another language - e.g. mi-NZ - so you have three
languages showing in your sysprefs en-NZ (selected), en (unselected) and
mi-NZ (selected)
3. Tick en-NZ and mi-NZ in language and OPACLanguages sysprefs. Order
en-NZ above mi-NZ and save
4. Refresh the syspref page and confirm mi-NZ is displaying above en-NZ,
even though you ordered en-NZ first
5. Refresh the syspref page multiple times and observe the order of the
languages changes
6. Apply this (second) patch
7. Restart plack
8. Refresh syspref page several times confirming that en-NZ is always
ordered first - as expected.
Sponsored-by: Kinder library, New Zealand
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Sponsored-by: Kinder library, New Zealand
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Apply this patch and restart services
2. Run t/db_dependent/Languages.t
3. Notice tests 16 and 17 sometimes fail
4. Apply all the other patches and restart services
5. Run t/db_dependent/Languages.t
6. Notice all tests consistently pass
Sponsored-by: Kinder library, New Zealand
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We are storing edi vendor acccount passwords in clear text in the
database. Now that Koha has the Koha::Encryption module, we should
use that to encrypt passwords for all existing and new EDI accounts.
Test Plan:
1) Apply this patch
2) Create one or more EDI vendor accounts
3) Run a report to view the account passwords, note they are in clear
text
4) Run updatedatabase.pl
5) Re-run the report, account passwords should be encrypted now
6) Edit a vendor EDI account, note you can still view and update the
password for an account
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>
This patch adds the classes to the template files so that the plugin hook can identify that cover images are required and where to inject them
Test plan as per first commit
Sponsored-by: PTFS Europe
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a plugin hook to inject cover images into the templates
Test plan:
1) Apply all patches
2) Go to https://github.com/PTFS-Europe/koha-plugin-addBDSCovers
3) In the releases section, download the .kpz file
4) Upload this in the plugins section and enable the plugin
5) In either the OPAC or staff client, search the catalog
6) The results should have cover art from BDS covers
7) Click on a result and the detail page should also have the cover art
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Go go the plugin admin page
upload a plugin
Notice that the "Actions" column is not longuer sortable
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch implements the code to allow a patron to receive multiple
orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page
To test:
1. apply all patches
2. updatedatabase
3. Go to system preferences and allow AcqReceiveMultipleOrderLines
4. In acquisitions module, create a vendor if you don't have one and add
3 baskets.. one with create items on ordering, one with create items
on receiving and finally one with create items when cataloguing
5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods.
6. Close all baskets and receive shipment.
CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected"
7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page
8. Check some of the checkboxes
CHECK => "Receive selected" button shows how many rows are selected
9. Go to the next page and select some more rows
CHECK => Changing page does not modify how many rows where selected
10. Go back to previous page
CHECK => Previously selected rows are still selected
11. Reload the page to deselect all rows
12. Select only one row and click on "Receive selected" button
CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked.
13. Click on cancel to go back to parcel.pl page
14. Select all rows (even the ones from the next page of the table) and
click on "Receive selected"
CHECH => In orderreceive.pl page there is a table with all selected rows
15. Ensure table has more than one page, as in step 7
16. Click on the "edit" link in the last row of the current page
CHECK => A modal window is displayed with 4 tabs within: Info,
Accounting, Receipt history and Items
CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos
order, 'Cancel' to close the modal without keeping modifications, 'Save'
to close modal keeping modifications and 'Next' to go to the next order
CHECK => Even that we are at the end of the current page, 'Next' button
is still available
17. Click on 'Next' button
CHECK => The table behind the modal now displays the next page, and the modal was not closed
18. Click on 'Previous'
CHECK => The table behind the modal went back to the first page, and the modal was not closed
19. Click on 'Previous' button till you reach the first row of the first
page
CHECK => Only when you reach the first row of the first page 'Previous'
button gets disabled
20. Click on 'Next' button till you reach the last row of the last page
CHECK => Only when you reach the last button of the last page 'Next'
button gets disabled
21. Check that behaviour for the different types of order are still the
same
a. For orders that where created through suggestion, check that the
suggestion info is present in Info tab. If when suggestion was accepted
you set a reason, a dropdown to change the reason shoul display also.
b. For orders that where created through subscriptions, check that
the Items tab is disabled, and the Receipt history is enabled. On
accounting tab you should be able to change quantity ordered. If there
were less items received than ordered, the next time you receive this
order the child order generated from this one shoul appear in receipt
history.
c. For orders that don't come from subscription and creates there items on ordering, Receipt history
should be disabled, and a table with prefilled items shold appear in the
Items tab. You can edit them and the changes should appear in the item's
row.
d. For orders that don't come from subscription and creates there
items on receiving, Receipt history should be disabled, and a form to
create the items should appear in Items tab. When you add an item a
table should appear.
e. For orders that don't come from subscription and creates there
ites on cataloguing, Receipt history and Items tabs should be disabled.
f. Any changes made in quantity (received or ordered) or funds in the modal should be
reflected in the table if you click save from the modal.
22. Once you've done all you checking and verifications click save
23. While saving a progress bar should appear
24. If no error was detected, you should be redirected back to parcel.pl
page
25. If an error or warning was detected (like there is an order with 0
items to receive) the save button should be disabled and warnings
are dispayed.
26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
Sponsored-by: Virginia Polytechnic Institute and State University
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch corrects a typo in the output of
search_for_data_inconsistencies.pl when a bibliographic record has no
title.
The patch also replaces biblio to bibliographic record in the same
sentence for terminology consistency.
To test:
- Have a bibliographic record without a title
- Run misc/maintenance/search_for_data_inconsistencies.pl
- Read output, make sure the sentence is correct
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We removed the 'scoped' attribute and so the style rules added in the
previous patch were applied to the agreement list view.
Why is 'scoped' not working is the main question here (?) but adding a
more specific selector to aim only the component (AgreementsList) from
the modal is a quick solution.
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Bug 33491: Add a more specific class for the modal
We don't want to apply these CSS rules to other modals
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
