Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
A variable was doubled up which made the columns in the
table of orders no longer line up (different number of headers
to columns).
To test:
- Create at least one basket with one or more orders
- Close the basket
- Add the basket to a basket group manually or let Koha do it
on closing
- Change the OrderPdfFormat system preference to 'German 2-page'
- Go to the basket group page and print the PDF of the basket
- Verify the table of orders doesn't look right and runs outside
the page
- Apply patch
- Repeat the PDF print - now table should look right
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>
To test:
1- find the NewItemsDefaultLocation syspref
2- confirm it says "NOTE: This system preference requires the misc/cronjobs/cart_to_shelf.pl cronjob. Ask your system administrator to schedule it."
3- apply patch
4- restart all
5- reload syspref, it doesn't say that anymore!
Signed-off-by: Holly Cooper <hc@interleaf.ie>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Total + Adjustments + Shipment cost ($)
changed to:
Total + adjustments + shipment cost ($)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Adjustments are not affected by tax, they are meant as a way to alter invoice
values after receiving (damaged items, refuneds, extra charges, etc)
When adjustments were added the tax included column was missed
To test:
- Add a basket with at least one order
- Close it
- Receive shipment
- Receive the order
- Finish receiving
- Add an adjustment of any amount
- Verify in the invoice details table:
- Total tax exc. is showing including the adjustmnt
- Total tax inc. is missing the adjustment
- Apply patch
- Reload
- Total tax exc. is showing including the adjustmnt
- Total tax inc. is showing including the adjustment
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TEST PLAN:
1. Have multiple holds from multiple patrons and run the holds queue cron to populate the holds queue list.
2. Try sorting by patron and see that is sorts based on first name.
3. Apply patch
4. Try sorting again and now it should sort by surname.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds missing Javascript libraries to the self-checkout
print slip. These missing libraries were preventing the auto print
prompt and close. There was also a font error.
To Test:
0) Apply patch
1) Turn on system preference SelfCheckReceiptPrompt
2) Check out item via /cgi-bin/koha/sco/sco-main.pl
3) Click "Finish"
4) Press F12 on keyboard and choose Console
5) Note no Javascript errors
6) Note that print dialog appears and closes after
a print option is chosen
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The feature was there but a condition disabled it.
Test plan:
- modify the default value for 008@ or another subfield in the ACQ framework using one or more of the placeholders above
- activate UseACQFrameworkForBiblioRecords
- create a basket
- create an order from a new record
- verify the values have been replaced
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It seems that this regression comes from bug 14419, but I have not found
a logic reason behind that.
This patch restores the behaviour we always had: facet groups must be
displayed in a given order: the Zebra index (au, ccode, holdingbranch,
etc.)
Test plan:
Apply this patch, restart all and confirm that the facets are not moving
up and down when you refresh your search result page.
QA note:
I think the following line must be removed
@facets_loop = sort {defined $a->{expand} && defined $b->{expand} && $a->{expand} cmp $b->{expand}} @facets_loop;
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the API set more userenv params than just the
borrowernumber. To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/auth_*
=> SUCCESS: All tests pass
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the authentication step stash the user that got
authenticated so code outside the Mojo part of Koha can use it (i.e.
through the use of C4::Context->userenv).
To test:
1. Apply the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/auth_authenticate_api_request.t \
t/db_dependent/api/v1/auth_basic.t
=> FAIL: Tests fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds regression tests for the different authentication
mechanisms Koha supports. It highlights the fact that Koha expects
userenv to be set on authentication.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TEST PLAN:
1. Have a fine on a Patron's account.
2. Choose the "Write off Selected" button
3. Enter an amount less than the amount owed by the patron.
4. Koha will give a yellow box with a note "You must collect a value
greater than or equal to 2.00." The $2.00 is the amount that is
attempted to write off (the amount less than the amount owed).
5. Apply patch
6. Again try to writeoff an amount less than the amount owed.
7. You should be able to write it off.
8. Try paying an amount more than owed, you should still get an
error. You shouldn't be able to write off more than the amount.
9. Follow the above steps via 'Pay selected' as aposed to 'Writeoff
selected'.
10. You should not be able to 'Tender' less than the amount you have
'Paid'.
11. Disable Javascript and run through all the above steps. You should
still be blocked where relevant.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes some redundant code from the OPAC JavaScript which
was causing problems with the show/hide action on two controls which are
shown only at narrower browser widths: The "Your account" menu shown
when the user is on a user-related page, and the "Refine your search"
menu shown on the search results page.
To test, apply the patch and go to the OPAC. Narrow your browser width
to below 768 pixels.
- Perform a search.
- On the search results page you should see a "Refine your search"
link at the top of the results. Clicking it should expand and
collapse the facets menu.
- Log in to the OPAC.
- On the "Your summary" page there should be a "Your account menu" link
at the top of the main part of the page. Clicking it should expand
and collapse the account menu.
- Verify that these menus display correctly when you widen and narrow
the browser window.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is no need for all the conditions.
From Encode::encode POD:
"If the $string is undef, then undef is returned."
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The cart was outputing ISO2709 MARC records with Latin-1
encoding. Records containing non-latin1 characters were
automatically re-encoded as UTF-8 by browsers, which led to
inconsistent character encodings for downloaded MARC files.
This patch explicitly encodes ISO2709 MARC characters from
the cart download as UTF-8 encoded bytes, which resolves the problem.
Test Plan:
0) Don't apply patch
1) Create bib record with only ASCII characters
2) Add a ü character to the title
3) Save bib record
4) Download bib record from cart (opac and staff client)
5) Using xxd or some other program, note that the ü is
represented by a FC byte (latin-1 encoded)
6) Apply the patch
7) Download bib record from cart (opac and staff client)
8) Using xxd or some other program, note that the ü is
represented by C3 BC bytes (utf-8 encoded)
9) Success
(Note that you could potentially use Notepad++ or some other
program to open the downloaded file and just note the encoding
that it finds. You could also try "chardetect" instead. Lots
of options for figuring out the encoding.)
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It looks like the functionality was broken when ui tabs were upgraded
and mainmainentry was added
To test:
1 - Browse to Authorities
2 - Search in each tab
3 - Note all search results revert to 'Search main heading a only'
4 - Apply patch
5 - Note selection is retained after search
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a missing `| html` filter to the tax_rate value option
that the patchset adds
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If the tax rate for a given order line has been removed from the system
preference gist, that tax rate will show in the pulldown as 0. If a
librarian then saves the order line the original tax rate will be
overwritten with 0%!
Test Plan:
1) Find an order line
2) Remove the tax rate set for that order line from the syspref gist
3) Edit the order line
4) Note the tax rate is 0
5) Apply this patch
6) Edit the order line
7) Note the tax rate now displays with a warning
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
By putting koha-shell in an if statement, "set -e" will no longer
cause the entire koha-foreach program to exit, if koha-shell
returns a non-zero status.
If a non-zero status is returned, we warn on it, and the caller
of koha-foreach can interpret that command visually.
To Test:
1) Write a shell script that says "Hello" and then exits with a 1
status
2) Run koha-foreach against that shell script with multiple instances
available to koha-foreach
3) Before the patch, koha-foreach will die after the first "Hello"
4) After the patch, koha-foreach will continue, through all the
instances, and report which instances returned non-zero statuses
by which command.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Since bug 25172 we are failing loudly if the permissions are not correct
and that the logger cannot init successfully.
We must set the correct permission on upgrading.
koha-create deals with new installs
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Checking any of the checkboxes in the EDI Account editor does nothing.
They always remain set to "off".
Test Plan:
1) Browse to edi_accounts.pl
2) Create a new EDI account, check all the checkboxes
3) Edit the account, note none of the checkboxes are checked
4) Apply this patch
5) Repeat steps 1-2
6) Note the checkboxes remain checked
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch corrects the column configuration tool for basket.pl
TO TEST:
1. Go to Acquisitions and look at basket.pl
2. Open another tab and go to column configuration and try to hide some columns like Quantity.
3. See that the wrong columns are being hidden.
4. Apply patch
5. Trying hiding each column in the table and make sure the correct one is being hidden.
6. Rejoice!
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When modifying an existing authorised value, the category is not
correctly passed to the template and so it is not passed to the
POST request, which results in the authorised value switching to
category '', which effectively make it disappear from the interface.
This patch fixes that.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes the update of marc frameworks from the updatedatabase script and warns the
"MARC to Keyword" (fieldmappings ) to the upgrade log so they can be replaced manually
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
See man sudo, -i parameter.
Should we expect regressions?
Test plan:
0. Use D11 or U18.
Don't apply this patch
1.
$ echo $KOHA_INTRANET_URL
$ sudo koha-shell kohadev
$ echo $KOHA_INTRANET_URL
2. Apply this patch
$ cp debian/scripts/koha-shell /usr/sbin/koha-shell
3. Repeat 1.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The API related tests still don't pass with the previous modifications.
They pass on D10 but fail on U18 and I did not manage to find where the
problems come from.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Now that float/decimal columns are not treated similar to integer ones,
the default value handling we had set for numeric values is not trapping
the float/decimal cases as it should.
We love tests!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The previous fix from bug 25513 does not work in all versions we are
supporting.
Let's hack the float/decimal columns in the same way we did for integer.
prove t/db_dependent/api/v1/acquisitions_vendors.t \
t/db_dependent/api/v1/patrons_accounts.t \
t/db_dependent/api/v1/acquisitions_orders.t
Note that there is another error on U20 for acquisitions_orders.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This reverts commit a79cf4150e.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We have the situation of needing to cast numbers so they are not
confused in JSON with strings by DBD::mysql returning them with the
wrong internal flags.
We have also recently removed the cast, and adding it back now.
This test could help us detect this situation in case we make changes in
the area, and even on specific libraries versions.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a change in the version number.
On U20 we get
Opening and ending tag mismatch: a line 0 and b
On others (D9, D10, U18) we get:
Opening and ending tag mismatch: a line 1 and b
I did not find where it did come from, so assuming it's just a minor
change and won't have side-effects.
Test plan:
Make sure the tests pass on U20 and another OS
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes version-specific packages from the debian/control file,
which fixes a bug where koha-common can only be installed on the debian
version that the package was built on
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
