This updates the call to store after populating the order
I put this on it's own bug just for sake of dependency, in case it is needed
seperate from 32166 for backports
To test:
1 - Apply and test with bug 32166
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When importing from a staged file we retrieve the records form the DB, skip any that are not selected,
and process the rest.
When we skip some, we still raise our record count, and use this to retrieve the inputs.
When building the page, we don't increment for skipped reocrds, so there can be a mismatch, i.e.
Record #1 on the page to add records may be the 3rd record in the import file
Rather than using a counting system, let us use the import record id directly
To test:
0 - Set system preferences:
MarcFieldsToOrder:
price: 949$g
quantity: 949$k
budget_code: 949$l
discount: 949$m
sort1: 949$n
sort2: 949$q
MarcItemFieldsToOrder:
homebranch: 949$a
holdingbranch: 949$b
itype: 949$y
nonpublic_note: 949$x
public_note: 949$z
loc: 949$c
ccode: 949$8
notforloan: 949$7
uri: 949$u
copyno: 949$t
price: 949$g
replacementprice: 949$v
itemcallnumber: 949$o
quantity: 949$k
budget_code: 949$l
1 - Stage attached sample file, Format:MARCXML, Record matching:Koha biblio 999$c
2 - Add to a basket from the staged file
3 - Select 1st record to basket and save
4 - Record is added with the fields above as expected
5 - Add to basket again, select 2nd record
6 - Record is added with price from 020a, ignoring incoming fields
7 - Repeat with 3rd, same problem
8 - Apply patch
9 - Stage file and repeat step 3
10 - Confirm added with correct values
11 - Add 2nd record and save, values correct
12 - Add 3rd record, values correct
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch deducts the current cost of an order if modifying it, so that
the current cost isn't counted when checking whether the updated cost
will take the order total amount above the allowed budget.
To test:
1. Add an active budget of $1,000
2. Attach a fund of $1,000. Set the fund to warn at 98% and $900.
3. Add an order to a basket, give it a vendor price of $500 with no
discount or tax and Save
4. Modify the order and change the vendor price to $450 and Save
5. Notice you get a warning that this order total amount will exceed the
allowed budget - this is incorrect.
6. Apply the patch and cancel the change so you're redirected back to
the basket
7. Modify the order and change the vendor price to $450 and Save
8. You should be able to Save without requiring confirmation
9. Add another order to the basket, give it a vendor price of $100 with
no discount or tax and Save. This should save normally, confirming we
can add new orders that do not exceed the allowed budget
10. Add another order to the basket, give it a vendor price of $500 with
no discount or tax and Save. This should trigger the warning that you
will exceed the allowed budget, as expected.
Sponsored-by: Waikato Institute of Technology
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1 - Receive some orders via acquisitions
2 - View the invoice with these orders
3 - Click 'Modify fund' on the received orders list
4 - Confirm you can change the fund
5 - Set some authorised value categories for funds
6 - Reload the invoice
7 - Confirm the categories dropdowns change when different funds selected
8 - Confirm updating the statistic fields saves correctly
9 - Add an inactive budget with some funds
10 - Test the 'show inactive' button on shipment fund, adjustments, and modifying order fund
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
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>
This patch adds support for filtering invoice searches on additional
fields. To test:
1. Generate additional fields for invoices
2. Have invoices with additional fields
3. Use invoice searching and play with filtering by additional fields.
=> SUCCESS: It works!
4. Sign off :-D
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds support for additional fields for invoices. A new option
is added to the 'Additional fields' admin page, for the 'aqinvoices'
table.
Adding/editing invoices now supports this additional fields.
To test:
1. Apply this patches
2. Verify the original test plan works
=> SUCCESS: It does!
3. Sign off :-D
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
By using objects a number of other routines are not needed:
GetImportRecordMarc SetImportRecordStatus SetMatchedBiblionumber
To test:
Grep for routines above in addorderiso2709 and confirm they are not used
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes the use of GetImportRecordsRange from the step
of listing import batches to choose. It was only used for a count so is a simple
replacement
To test:
1 - Stage a number of files for import
2 - Import one of the files from tools
3 - Add to basket form a staged file
4 - Confirm staged baskets are listed, and imported basket is not
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes the use of GetimportRecordsRange from the importing
step
To test:
0 - Apply patch
1 - Stage a marc file for import
2 - Add to basket from a staged file
3 - Select titles to import (don't select all)
4 - Fill out necessary fields, be sure to select itemtype on items tab
5 - Import
6 - Confirm titles successfully added to basket
7 - Confirm staged import not marked as imported
8 - Add to basket from same file
9 - Select rest of titles
10 - Import
11 - Confirm staged file now marked imported
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch changes the way records are loaded for display when adding to
a basket from a staged file
To test:
1 - Stage a file of records for import
2 - Go to Acquisitions, find a vendor, create or find a basket
3 - Add to basket from staged file
4 - Choose the file
5 - Note the display of records
6 - Cancel
7 - Apply patch
8 - Stage from same file
9 - Note the display is unchanged
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Hiding the list may lead to biblioitems.itemtype being NULL.
We do not want that, since 942$c is mandatory.
Test plan:
Create basket and set 'create items when' to receiving or
cataloging.
Create order from new empty record.
Check biblioitems.itemtype of created biblio.
Without this patch, it would have been NULL like this:
select biblionumber,title from biblio;
| 7 | Test 3 |
select biblionumber,itemtype from biblioitems;
| 7 | NULL |
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>
This patch adds a new English 1 page layout to be used when exporting a
basketgroup as PDF. This has been modelled after an example PDF from
another library system.
To test:
1) Go to Koha Administration -> Libraries. Ensure Library A has an
address, phone and fax.
2) Go to Koha Administration -> System preferences. Search for
OrderPdfFormat. Set this to the new English 1-page layout option.
3) Go to Acquisitions. Use an existing vendor or create a new one.
Ensure the vendor has a postal address, phone, fax and accout number.
4) Create a basket for this vendor. Add a few orders to the basket.
5) Close the basket and add it to a basket group of the same name.
6) Edit the basket group. Add an address in the delivery place, and a
delivery comment. Check the box to close the basket group and Save.
7) Click the button to Export as PDF.
8) View the exported PDF. Confirm all of the information displayed is
correct.
9) Reopen the basketgroup. Edit the details and remove the delivery
place text. Re-close the basketgroup.
10) Repeat steps 7 and 8.
Sponsored-by: Pymble Ladies' College
Signed-off-by: David Nind <david@davidnind.com>
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>
This patch adds skiptotals parameter to GetBudgetHierarchy so calculating
totals can be skipped from some pages.
Test plan:
1) Open browser's Inspect -> Network
2) Go to receive orders
3) Check the timings for page load
4) Apply the patch
5) Refresh the page
6) Check the timings again
7) prove t/db_dependent/Budgets.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This allows you to empty the delivery date and ensures the current date
shows
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Also add functionality to edit the estimated delivery date from a closed
basket.
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
FAIL acqui/addorder.pl
FAIL valid
" dt_from_string " is not exported by the Koha::DateUtils module
Can't continue after import errors
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch allows you to specify an estimated delivery date per order.
The specified estimated delivery date is also considered when searching
for late orders and exporting late orders. You can also edit the
estimated delivery date from the late orders page.
Test plan:
1. Update database, rebuild schema, restart services
2. Go to Acquisitions, search for a vendor, and create a new basket
3. Add an order to the basket. When filling in the accounting details,
notice the new 'estimated delivery date' field, but don't add a date.
Save the order.
4. Confirm no date shows in the estimated delivery date column in the
orders table.
5. Modify the order. Add a date in the estimated delivery date field and
save the order.
6. Confirm the date now shows in the orders table.
7. Close the basket.
8. Go to the Late Orders page.
9. Put estimated delivery date from and to parameters in the search
filters on the left. Ensure the from and to dates encapsulate the date
you entered in the estimated delivery date field for the order.
10. Click Filter and ensure the order shows.
11. Select the checkbox next to the order. Click the Export as CSV button.
12. Open the CSV and confirm the estimated delivery date that you
entered shows as expected in the file.
13. Click Edit under the estimated delivery date. Confirm the estimated
delivery date modal pops up with the correct order line number in the
modal header.
14. Remove the estimated delivery date and click Save.
15. Confirm that the estimated delivery date calculated by Koha now
shows in the late orders table.
16. Select the checkbox next to the order. Click the Export as CSV button.
17. Open the CSV and confirm the calculated estimated delivery date
shows in the CSV.
18. Confirm tests pass: t/db_dependent/Koha/Acquisition/Order.t
Sponsored-by: Bibliotheksservice-Zentrum Baden-Württemberg (BSZ)
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Found this crash in our 20.11 logs:
Cannot insert order: Mandatory parameter biblionumber is missing at /usr/share/koha/acqui/cancelorder.pl line 60.
at /usr/share/perl/5.28/Carp.pm line 289
Carp::croak('Cannot insert order: Mandatory parameter biblionumber is missing') called at /usr/share/koha/Koha/Acquisition/Order.pm line 79
Koha::Acquisition::Order::store('Koha::Acquisition::Order=HASH(0x55f3760e2860)') called at /usr/share/koha/Koha/Acquisition/Order.pm line 189
Koha::Acquisition::Order::cancel('Koha::Acquisition::Order=HASH(0x55f3760e2860)', 'HASH(0x55f375a17ec0)') called at /usr/share/koha/acqui/cancelorder.pl line 60
Not sure how to reproduce this one as it happened. But might be related to repeated clicking, backspacing etc.
Test plan:
Create a new basket and order.
Open this same basket in two browser tabs.
Cancel the order line (delete catalog record) in tab 1.
Go to second tab, try again.
Without this patch, it will crash. With this patch, an error message.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a new vendor_type field when creating/editing vendors
and displays the field on search and details for a vendor
To test:
1 - Apply patch, update database
2 - Edit/create a vendor in acquisitions
3 - Note new 'Vendor type' field, free text in editor
4 - Save a value
5 - Confirm it displays in vendor search results and vendor main page
6 - In Authorised values add a new value to 'VENDOR_TYPE' category
7 - Confirm the description of VENDOR_TYPE shows and makes sense
8 - Add/Edit a vendor, note the vendor type is now a dropdown selection
9 - Save with a value
10 - Confirm the description shows in results and vendor page and vendor details
Signed-off-by: Caroline <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
and split the subroutine into 2 smaller subroutines (one for ordering,
the other for receiving)
Test plan:
1. Create a vendor and an acquisition basket
2. In this basket, create new orders using all the different methods
(from an existing record, from a suggestion, from a new record, ...)
then close the basket and receive these orders.
Make sure it works the same with and without the patch
3. Run tests in t/Prices.t,
t/db_dependent/Acquisition/populate_order_with_prices.t, and
t/db_dependent/Budgets.t
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea rely on the KohaDates TT plugin for the date formatting. We
should not have any output_pref calls in pl or pm (there are some
exceptions, for ILSDI for instance).
Also flatpickr will deal with the places where dates are inputed. We
will pass the raw SQL value (what we call 'iso' in Koha::DateUtils), and
the controller will receive the same value, no need to additional
conversion.
Note that DBIC has the capability to auto-deflate DateTime objects,
which makes things way easier. We can either pass the value we receive
from the controller, or pass a DT object to our methods.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
- add search form field for ISSN number
- add search logic including ISSN variations search
if SearchWithISSNVariations preference is set
Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD Amended patch:
-# FIXME Special case here
- print "Biblio not found\n,";
+ print "Biblio not found\n";
- my $biblio = Koha::Biblio->find($hostbiblionumber);
+ my $biblio = Koha::Biblios->find($hostbiblionumber);
Rebased-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch simply removes a discrepancty where when a discount is provided on the order form
we add the discount to the price, and when it comes form the vendor we subtract the discount.
Discounts should always descrease the estimated cost
To test:
0 - Have a vendor with a discount of 10% specified
1 - Export a record from your Koha
2 - Stage the record for import and match on biblionumber
3 - Add to a basket in acq from the staged file
4 - Select the title, and set order price to $10 and do not fill the discount field
5 - Add the order - note $10 RRP and $9 actual/budgeted cost
6 - Repeat 2&3
7 - Select the tile, set price $10 and discount 50%
8 - Add the order - note $20 RRP and $10 actual/budgeted cost! FAIL
9 - Apply patch, restart all
10 - Repeat 2-7
11 - Add the order, note $10 RRP and $5 actual.budgeted cost
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
CGI param basketno should be explicitly scalar,
or else error log gets flooded with this warning:
AH01215: CGI::param called in list context from
/home/vagrant/kohaclone/acqui/basket.pl line 175, this can lead to
vulnerabilities. See the warning in "Fetching the value or values of a
single named parameter" at /usr/share/perl5/CGI.pm line 412.
This patch fixes it by working with it in a scalar context.
The functionality still remains the same but warning doesn't flood
error log.
To reproduce:
1. Head over to the acquisitions page.
2. Pick existing vendor with email contact info or create a new one.
3. Create a new basket or use existing one, and if it doesn't have
any orders, add a new order to it.
4. Use the "E-mail order" button to send order.
5. Check the error log and find the upper mentioned warning.
(Note: if you're going to test this more than once, you might need
to restart your Plack in order for this warning to get added to your
log file again, reasons of that is that the authors of CGI.pm decided
to "warn only once")
6. Apply the patch.
7. Use the "E-mail order" button again, ensure that the same warning
doesn't get added to the log file again.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The C4::Suggestions::SearchSuggestion subroutine is badly written and
can be replaced by calls to Koha::Suggestions->search.
The hard part in this patch is suggestion.pl, the other occurrences have
been replaced easily.
Test plan:
The idea is to test the whole suggestion workflow.
1. Create a suggestion on OPAC
2. Create a suggestion on the staff interface
3. Edit suggestions
4. Filter suggestions (use the different filters and "organize by"
values)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Remove SearchSuggestion tests
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: (QA follow-up) Save some DB queries
This patch makes the suggestion-related pages rely on array size instead
of querying the DB each time they need to. In the case of
suggestion/suggestion.pl it goes from 4 COUNT(*) to 1.
To test, with KTD:
1. Run on the host machine:
$ docker exec -ti koha_db_1 bash
$ mysql -ppassword
> SET GLOBAL general_log_file='/var/log/mysql/mycustom.log';
> SET GLOBAL log_output = 'FILE';
> SET GLOBAL general_log = 'ON';
> \q
$ tail -f /var/log/mysql/mycustom.log | grep suggestions
2. Visit the different pages changed on this bug
=> SUCCESS: Some queries
3. Apply this patch
4. Repeat 2
=> SUCCESS: Less queries!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Fix branchcode and budgetid filtering
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Fix conflict with bug 28941
Well, this patchset fixed the security bug...
Redoing on top of bug 28941
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: (follow-up) Missing semicolon
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Fix 'all' libraries
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: (follow-up) Add value to filter_archived
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This bug fixes how the discount amount for an order is stored, when an order is added to a basket using "From staged MARC records".
Test plan:
1. Export a record (without the items) (Tools > Catalog > Export data).
2. Delete the record from the catalog (including any items).
3. Stage the record for import (Tools > Catalog > Stage MARC records for import).
4. Create a new vendor with a discount of 25%. (Or select and existing vendor that has a discount). (Acquisitions > New vendor)
5. Create a new basket for the vendor. (Acquisitions > Manage orders > search for vendors > New > Basket).
6. Add to the basket using "From a staged file":
. select "Add orders" next to the staged file
. select the record to add to the order
. enter a price
. leave the discount field blank
. select a fund
. select "Save"
==> The order is created!
7. Modify the order - note that the discount is showing on the form as .25% instead of 25%, also note that the discount amount is calculated correctly.
8. Check what is recorded in the database:
. koha-mysql kohadev
. select * from aqorders;
==> discount field for the basket item shows as 0.2500
9. Change the discount to 25%. Run step 8 again - discount amount will be correctly shown as 25.0000
10. Apply the patch.
11. Repeat steps 1-9 - discount amount is shown and calculated correctly.
12. Test modifying the discount amount - should be calculated and shown correctly.
13. Sign off!
See additional comments in the bug description.
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>
This patch makes a number of changes to the vendor search/view template
in order to make it work better in different contexts:
- Add a vendor-specific toolbar under each vendor search result. This
gives instant access to the options for a new basket, new contract,
vendor edit, or to receive shipments. A delete button will appear if
available.
- Add a summary of the number of baskets and subscriptions. This helps
the user know if there are closed baskets and whether an outstanding
subscription might be blocking the option to delete. Each number is
linked to the view of those entries.
- Indicate whether a vendor is inactive. The vendor name appears in a
different color when it is inactve and is labeled as such.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- To test you should have multiple vendors in your system, some active
and some inactive. Add some baskets and subscriptions to one or more
if necessary.
- Go to Acquisitions and submit an empty vendor search to show all
vendors.
- Verify that the page looks correct and that all controls work as
expected.
- Open the basket view for a single vendor and compare the two views.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Adds an "Edifact" systempreference to govern whether edifact processing
is enabled. In most places this is hidden if the current
vendor does not appear in the edi vendors table. This preference
hides the admin screens which define this and a couple of links.
Also fixes an anomaly whereby the basketgroup screen was not
making the same check on whether edi ordering should be enabled as
the basket screen. Both now use the same logic.
Rebased-by: Mark Tompsett <mtompset@hotmail.com>
Rebased-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
Add a manager to a basket
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
I squashed the patches because they are too trivial to have a test plan.
Or it is too much work to write the test plan for such trivial cases. I
leave the original commit messages just in case.
Generally, this are all cases in which CGI::param is being called in a
trivially identifiable _list context_. i.e. they are assigned to a
@variable.
I left one case out on purpose: admin/auth_subfields_structure.pl
Paul introduced this:
my @kohafield = ''.$input->param('kohafield');
and then:
my $kohafield = $kohafield[$i];
My intuition says it is forcing scalar context on the first assignment
so the list contains a single element and then inside the loop some
$kohafield assignments should lead to undef, and even warnings. I leave
it for a separate patch because it is not that easy testable and is a
sensible area.
Bug 29771: Remove warning from acqui/finishreceive.pl
This patch removes a warning that shows when receiving.
To test:
1. Do the acq workflow up to the receive step.
2. Once you choose the items and click on Finish
=> FAIL: There's a warning in the logs
3. Revert receipt
4. Apply this patch
5. Receive
=> SUCCESS: No more warnings
6. Sign off :-D
Bug 29771: Remove warning from svc/members/add_to_list
To test:
1. Run:
$ tail -f /var/log/koha/kohadev/*-error.log
2. Generate a patron list
3. Perform a patron search that gives you a few
4. Select some, and choose to add them to the list
=> FAIL: The logs show the infamous warn:
CGI::param called in list context from /kohadevbox/koha/svc/members/add_to_list
5. Apply this patch
6. Restart plack and repeat 4
=> SUCCESS: No warn!
7. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Michael Sutherland <sudrland@vt.edu>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
It will conflict with other ->messages methods, it's too generic.
Bug 29230 needs Koha::Patron->messages to return Koha::Patron::Messages for instance.
Test plan:
Confirm that the tests modified by this patch still pass
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On bug 29844 we decided to remove wantarray from Koha::Objects->search.
Reviewing the difference occurrences I found some unnecessary uses of ->as_list,
where iterators should be used instead.
This patch only removes the obvious places, not the tricky ones.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We have already a search filter for active orders.
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When deleting a basket we cancel all the contained orders - when a
basket contains an order that was previously cancelled this can cause
an error if the biblio was deleted
When picking the orders to cancel, we should limit our search
to those not already cancelled.
To test:
- have a basket with at least one order
- click "Cancel order and delete catalog record", confirm cancellation of order and deletion of bib
- click "Delete basket", confirm deletion
- get error "Cannot insert order: Mandatory parameter biblionumber is missing at /kohadevbox/koha/acqui/basket.pl line 136.
at /usr/share/perl/5.28/Carp.pm line 289"
- apply patch
- restart
- delete the basket
- success!
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We were shifting the price and replacement price for imported orders
only after the line:
> $duplinbatch = $import_batch_id and next if $duplifound;
This lead to the "replacementprice" and "price" query parameters not
being shifted/removed from the list if a duplicate record came across
and caused the prices be applied to the next record being imported.
To reproduce:
1) Download two records from koha to marcxml file, then cat those:
cat bib1.marcxml bib2.marcxml > bibs.marcxml
2) Delete bib2 from koha
3) Stage bibs.marcxml for import
4) Create a new order basket, then "Add to basket" using "From a
staged file" option
5) Select both bib1 and bib2 and set price & replacement price for
bib1 to be 99.00 and for bib2 to be 88.00
6) Click save and notice bib2 was imported with the wrong prices, 99.00!
7) Apply patch and notice the prices are now correctly set to 88.00.
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds aqorders.order_internalnote and
aqorders.order_vendornote to the Acquisitions history search.
To test:
1) Apply patch and restart services
2) Create an order in Acquisitions and set an internal note and a vendor note
3) Go to /cgi-bin/acqui/histsearch.pl and search by internal or vendor
note using the terms you set in step 2
4) Note your order is returned and internal note and vendor note are
included in the search results at the end of the table
Sponsored-by: Bibliotheksservice-Zentrum Baden-Wuerttemberg
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>
To test:
1 - Populate system preference NewItemsDefaultLocation
2 - Stage a file of marc records
3 - Create an acquisitions basket with 'AcqCreateItems' set to 'ordering'
4 - Attempt to add to basket from your staged file
5 - You get a 500 error, and in the logs:
Can't use string ("") as a HASH ref while "strict refs" in use at /usr/share/koha/lib/C4/Items.pm line 1605.
6 - Apply patch
7 - Repeat #4
8 - Success!
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The indicator value for 952 was hard coded in every case to " ". In
order to achieve that we can simply pass undef to TransformHtmlToXml()
and it will set the indicator values to " ".
To test:
1) Make sure the submission of (at least some) the modified files
still work, e.g. test that making a new item via
cataloguing/additem.pl works.
Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Rebased-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
1) open acqui/addorderiso2709.pl in your code editor and make sure
nothing references $item in the if block where it was removed from
Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Replacing a multiple object->column(value) by ->update.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This certainly is one of my shortest fixes ever ;)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As requested in comment #49, renamed uses of AcqLog to AcquisitionLog
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
JD amended patch: replace one missing occurrence in Budgets.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This commit makes changes in response to Jonathan's feedback in comment
- Moved from using zero padded strings to store log data to a JSON
object
- Stopped storing formatted dates in logged data
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If an order is cancelled but the associated bib / items are unable to be
removed, we go into error handling. We still need to log the
cancellation though. So this fix moves the logging to just after the
cancellation, so it will be logged regardless of the outcome with
associated things.
Signed-off-by: Maura Stephens <maura.stephens@gmit.ie>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Maura Stephens <maura.stephens@gmit.ie>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 23376 we replaced $order, from hashref Koha::Acq::Order, but 2
occurrences have not been corrected.
It causes a bug on the order receive page when the bib is linked with a
suggestion.
Test plan:
Create an order from bib A, create a suggestion for purchase on bib A
(OPAC)
Receive the order.
Without the patch: Notice the "Suggested by: (suggestion #)"
With the patch you see the info of the suggester
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the edi_order relationship method to
Koha::Acquisition::Basket to return the most recently attached
edi_message of type 'ORDER' for the basket.
NOTE: EDI currently returns raw DBIC results. I have opted to maintain
that approach here, but would like to work on upgradeing the
Koha::EDIFACT::Order class to be a subclass of Koha::Object at a later
date.
We then use this new relationship in acqui/basket to display the EDI
status for such baskets.
Test plan
1/ Setup a vendor with EDI Ordering enabled
2/ Add a new basket for the vendor.
3/ Note the new 'EDI status' field displays and reads 'Not ordered'
4/ Close the basker
5/ The 'EDI status' should continue to display 'Not ordered'
6/ Re-open the basket
7/ Close the basket via 'Create EDIFACT order'
8/ Navigate back to the now closed basket
9/ Note the 'EDI status' field now displays 'Pending' and the transfer
date.
10/ Progress the EDI order by running the edi_cron.pl script
11/ The EDI status field should now reflect that the message has been
sent.
Signed-off-by: Benjamin Veasey <B.T.Veasey@lboro.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
No idea why UpdateStats in C4::Circulation needs the fully qualified
namespace!
I kept getting
Undefined subroutine &C4::Circulation::UpdateStats called at /kohadevbox/koha/C4/Circulation.pm line 1643.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are using Koha::Logger when it makes sense to keep the info,
otherwise we simply remove it
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 28572: Replace missing occurrence in misc/admin/koha-preferences
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As highlighted by Jonathan in comment #90, we were passing
borrowernumber to ModBasket. This was a hangover from when we explicitly
logged the borrower, which was later discovered to be unnecessary
duplication, and was removed in commit "Remove data duplication".
This commit removes this unnecessary parameter.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As requested by Tomás and Jonathan, we now log the entire basket object
when logging an action.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In response to Séverine observations in comment #10, this patch removes
the duplicate logging of the borrowernumber
https://bugs.koha-community.org/show_bug.cgi?id=23971
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds logging for the following Acq actions:
- Basket creation
- Basket editing
- Basket approval (via EDI)
- Basket closure
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 23971: (QA follow-up) New DBrev syntax
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 22773: The deprecated plugin is removed
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Christopher Kellermeyer <ckellermeyer@altadenalibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Remove asset for removed js
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Caused by
commit 03a9bdc851
Bug 24469: Move the new queries to a dedicated ImportBatch subroutine
Undefined subroutine &CGI::Compile::ROOT::kohadevbox_koha_acqui_neworderempty_2epl::SetMatchedBiblionumber called at /kohadevbox/koha/acqui/neworderempty.pl line 183
Test plan:
Create a new order from a staged file, select "Add order" next to a
title
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch remove the 0000-00-00 from the WHERE condition from
ordered.pl and spent.pl to prevent an error under MySQL 8
It also fixes the wrong values in DB (if possible, ie. under other DBMS
that MySQL 8)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: POD line for $import_record_id.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The column import_biblios.matched_biblionumber was not populated when an
order is created from a staged file.
Test plan:
A/ Create a new order from a stage file.
Use the "Save" button at the bottom of the "Add orders from" page
Then note the matched_biblionumber value. It should be populated correctly
B/ Import again the same record, this time you will have to use the "Add
order" link in the list of order (ie. not the "Save" button)
Note the matched_biblionumber value. It should be populated correctly
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Sarah Daviau <sdaviau@arlingtonva.us>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a difference between YAML::Load and YAML::XS::Load
From YAML::XS pod:
"YAML::XS only deals with streams of utf8 octets"
Test plan:
We are going to test 1 occurence and QA will confirm others don't
contain typos.
0. Don't apply the patches
1. Create a new itemtype with code=❤️
2. Create a new item using this itemtype (to biblionumber=1 will work)
3. Fill OpacHiddenItems with
itype: [❤️]
4. Search for "street shuffle" or any terms that will return the biblio
Notice that the item is there (there is an error in logs)
5. Apply the patches
6. Repeat 4 and confirm that the item is now hidden
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
From tht YAML pod:
"""
This module has been released to CPAN as YAML::Old, and soon YAML.pm will be changed to just be a frontend interface module for all the various Perl YAML implementation modules, including YAML::Old.
If you want robust and fast YAML processing using the normal Dump/Load API, please consider switching to YAML::XS. It is by far the best Perl module for YAML at this time. It requires that you have a C compiler, since it is written in C.
"""
See also
https://gitlab.com/koha-community/qa-test-tools/-/merge_requests/35
Test plan:
Try some place where YAML::XS is not used and confirm that it works
correctly
QA note: This patch removes some uses of YAML that were not useful
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch is the result of making the same changes we did on the
t/db_dependent/AuthorisedValues.t file (replacing the calls to
Koha::AuthorisedValues->search with the tricky branchcode param, and
call ->search_with_library_limits, with the library_id as a third
parameter.
What I did was:
$ git grep 'Koha::AuthorisedValues\->search'
and then revisited each of the grep results to check if they added the
'branchcode' parameter to the filters.
This patch changes the calls to ->search, for
->search_with_library_limits in all the places that require it in the
current codebase [1].
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Charges/Sales.t \
t/db_dependent/Ill*
3. Verify the batchmod.pl script is working and filtering the authorised
values keeps working
[1] Some places like the Koha/Template/Plugin/AuthorisedValues.pm plugin
don't seem to be tested, at first glance.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 27402 is adding it, we do not longer need the query_from_filters JS
function.
This patch also remove the filters on the left. As we have DT
remembering the filter on the table we don't need them anymore.
Technical note:
Prior to this patch, the search on biblio.author, biblio.title and
biblio.isbn was done by adding hidden columns. Now we are using:
"data": "biblio.author:biblio.title:biblio.isbn"
to tell the wrapper we are going to build a search on these 3
attributes.
Another trick is to pass a default_filters parameters to the wrapper, to
tell it we want to filter on the orders of a given vendor (this is a
bugfix, the original implementation was returning all the orders).
However We should not use /acq/orders?vendor_id=42 but /acq/vendor/42/orders instead (which does not exist yet),
otherwise (with bug 27353 ) we are going to display the wrong number of non-filtering rows.
The change in Orders.pm is only formatting to match what's done in
Bug 27353: Set X-Base-Total-Count header for REST API
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@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 restores the original behaviour: if you jump into receiving
an order, and then go back to receiving, you want the page to remember
your filters.
This feature was overlooked. On fixing it, I wrapped some JS code in a
function for reusing it and simplified it a bit as well.
To test:
1. Enter a search term in either of the search fields
2. Add a note, receive or do another action
=> SUCCESS: The search term is kept
3. Apply this patch set
4. Repeat 2
=> SUCCESS: The search term is kept
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
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: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@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. Create a vendor
2. Create a basket
3. Add an order to the basket (note the existence of the option 'gist'
4 Apply patch
5. Create another order (note the existence of the option 'TaxRates'
instead)
6. Run 'prove t/Prices.t' to confirm the tests were successful
7. If everything above is correct then patch was successful
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When a staged MARC file is used to populate a basket in acquisitions,
the status of the batch is kept as "staged" until a user repeat the operation.
The "imported" status is added to the batch when new orders are added to
a basket "from a new file" (yes!...)
Test plan:
- Create a basket
- Add to basket From a New File
- Select a marc file and stage
- Add titles to your basket
Until all your records are imported the batch will have the status
"staged"
When all your records will be imported, the status of the batch will be
"imported"
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To reproduce:
1- create a basket
2- add more of 20 orders with uncertain price
3- click on uncertain price button
4- on page 1 of list, uncheck uncertain box of an order
5- click on save button
6- orders who were on page 2 are not display anymore in page uncertainprice.pl
7- return to basket view acqui/basket.pl
8- orders who were on page 2 have "rvcd" label and quantity is null
The data in page 2 and beyond is not transmitted, but the code doesn't
handle that. This patch makes sure that all that (empty) data is not (wrongly) processed.
Sponsored by: CCSR
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes code use the new Koha::Acquisition::Basket->close
method and makes CloseBasket obsolete.
It then removes it, and adapts the few places in which it was used.
1. Apply this patch
2. Run:
$ kshell
k$ git diff origin/master --name-only | grep -e '\.t$' | xargs prove
=> SUCCESS: Tests pass!
3. Try playing with baskets, closing them
=> SUCCESS: All works as expected!
4. Sign off :-D
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>
At the moment there are several cases, when closing a basket is not
possible:
- when there are no order lines in it
- when there are order lines with uncertain prices
- when the basket is marked as a standing order
The first case wasn't checked correctly as only pending/received
orders would be counted, but not cancelled orders.
To test:
- Create a basket
- Create an order line
- Verify the "close this basket" button shows
- Cancel the order line - the button disappears
- Apply the patch
- Verify the button appears and works now
- Create another basket - make sure you cannot close it
without order lines
- Create an order line with uncertain price checked
- you cannot close it
- Resolve the uncertain price - you can now close the basket.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
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 mentioned controller scripts use the new
$order->cancel method instead of DelOrder.
To test:
1. Apply this patches
2. Have a basket with some orders
3. Play with cancelling orders and removing baskets
=> SUCCESS: No behaviour change!
=> SUCCESS: No errors!
4. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This allows to filter on standing orders on the acq advanced search
checkbox. For this purpose a new checkbox is shown behind the order
status search option.
As both not yet ordered and standing orders have the status
'new' or partially received internally, this seems like a good
placement as it will help distinguish these cases clearly.
new + standing order = standing order, but nothing received yet
partially received + standing order = active standing order
all status + standing order = all standing orders
To test:
- Create some baskets with at least one order, some 'standing' and
others not
- In the top toolbar choose tab Orders search > Advanced search
- Make some searches with and without the new 'Standing order' option
- Verify the right orders are found
- In the search results standing orders will now show with the
status + (standing order).
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The rebased patchset subsequnetly re-introduced the now deprecated use
of authnotrequired on staff client controllers.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset switches from using DB lookups to using an order object for most things on orderreceive.pl
It simplifies the script and makes minimal changes to the template
To test:
1 - Place some orders and receive them
2 - Have orders with or without subscriptions attached
3 - Try with different AcqCreateItems settings
4 - Apply patch
5 - No behaviour should change
6 - Read code to ensure things make sense
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Before this patch the order receive page (parcel.pl) would show
... Received by: <current user> On: <current date>
This is not really helpful. Whenever you viewed an invoice, it
would tell you it was _you_ who received that _today_.
As we don't store a creator of an invoice and the order lines
in an invoice could have been received by different people (which
we also don't know about), the "Received by" is removed by this patch.
Instead of today's date, we can show the shipment date entered for
the invoice. Again: different order lines could have been received
on different dates for this shipment. So only the shipment date makes
sense as it's on invoice level.
This also makes changes to the page title, breadcrumby and page heading:
When the invoice is closed, they will read:
Receipt summary for [vendor] ...
When the invoice is not closed, they wil read:
Receive orders from [vendor] ...
To test:
- Create a basket with some orders in acq
- Close the basket
- Receive shipment and create an invoice
- Make sure shipment date is not set to today
- Verify the information shown on top of parcel.pl is you and today
- Change staff users
- Go to your invoice, it's now this user and today
- Apply patch
- Received by: should be gone and the On: replaced by Shipment date:
with the date you selected
- Check the page title, breadcrumbs and headings read all the same 'Receive orders...'
- Finish receiving and close the invoice
- "Go to receipt page"
- Verify they now read "Receipt summary.."
If you have older invoices in your system, it would work
even better with these as you'd see that always today's date
is displaying without the patch.
Signed-off-by: Marjorie <marjorie.barry-vila@collecto.ca>
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>
We don't allow editing of orders that are part of a closed basket, but
we don't enforce the rule in the controller file.
This patch use output_and_exit to stop the script and display an error
to the end user.
Test plan:
Create a basket, add an order
On the basket view you see the "Modify" link, open it in a separate tab
=> You can edit the basket
Keep this tab open, get back to the other one and close the basket
Reload the tab with the order edition form
=> You cannot longer edit the basket
QA: Do we need a check in addorder.pl as well?
Signed-off-by: Henry Bolshaw <bolshawh@parliament.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some library would like to delay the importing of invoices until
a time of their choosing. The invoices should be imported into
the database as they do now, but the invoice processing should
be skipped. Instead, any invoice file with a status of 'new'
should have an 'Import' button to process the invoice.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Enable the new syspref EdifactInvoiceImport
4) Run the edi cronjob to import a new invoice file
5) View EDI messages table at /acqui/edifactmsgs.pl
6) Note the invoice files is not processes, and retains the status of 'new'
7) Use the 'import' button to process the invoice
8) Note the invoice is now marked 'received' and the 'import' button is gone
9) Verify the invoice was actually processes
Signed-off-by: Debi Stears <DDStears@washoecounty.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
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>
To test:
0 - Be in staff client as a superlibrarian
1 - Place some suggestions
1 for any branch
1 for signed in branch
1 for another branch
2 - Go to Koha main page, 3 suggestions pending
3 - Click 'Suggestions pending approval' - you see one suggestion
4 - Click on 'Acquisitions' in breadcrumbs , 3 suggestions pending
5 - Click manage suggestions - you see one suggestion
6 - Apply patch
7 - On mainpage and acqui-home you now see "Centerville: 1 / All libraries: 3" suggestions
8 - Confirm that the links take you to suggestions view of your branch or all libraries respectively
9 - Turn on IndependentBranches
10 - Create a user with acquisition and suggestions permissions but not superlibrarian in one of the branches used above
11 - Sign in as that user
11 - See "Centerville: 1" suggestion on mainpage and on acqui home
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 a ->store call missing when we attempt to create a new item.
Test plan:
- set at least one value in MARCItemFieldsToOrder
- add to a basket via staged file with at least one value matching your MARCItemFields mappings
- set required fields for your order and click Save
=> Without this patch you got:
receive error: "DBIx::Class::Storage::DBI::_dbh_execute(): Column 'itemnumber' cannot be null at /kohadevbox/koha/Koha/Acquisition/Order.pm line 113
at /usr/share/perl5/DBIx/Class/Exception.pm line 77"
=> With this patch applied the order has been created successfully
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 modifies the code for parsing MARC framework configurations
so that the placeholder "<<YY>>" translates to a two-year date.
To test, apply the patch and modify a framework to include placeholders.
For example, in MARC21:
- Administration -> MARC structure -> 952 -> Edit subfields -> d
- Expand "Advanced constraints" and add a default value:
<<YYYY>> <<YY>> <<MM>> <<DD>> <<USER>>
- Save your configuration and go to Cataloging.
- Go to the add/edit items page for a record which uses the framework
you edited.
- In the "Add item" form, in the "Date aquired" field, you should see
the correct values. For example: '2019 19 12 03 Leonard'
Perform the same test when adding an item during the Acquisitions
process (depending on your AcqCreateItem setting).
Note that acqui/neworderempty.pl has been modified because the
placeholder-replacement code is repeated there, but I couldn't discover
how to test it (if it is used at all?)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If a fund is created with a amount of 0, it will not appear in the fund
list (when a new order is created for instance).
0 allocated funds can be used to track donations and other situations
where there is not an expected amount for the year.
Test plan:
0. Do not apply the patch
1. Create 1 active and 1 inactive budgets
2. Create some funds for each budgets, with amount > 0 and amount == 0
3. Add orders to basket
=> Note that the funds with amount == 0 are not displayed
4. Apply the patch
5. Add orders to basket (using the different possible ways we have)
=> Note that the funds with amount == 0 are displayed
This change is applied to the different views of the acquisition module.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch make possible the reopening and merging of invoices even if
the logged in user does not have the edit_invoices permission
I don't think it really makes sense but at least it's now possible.
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add a new permission to merge invoices
Test plan:
- Remove the new permission "merge_invoices" for a given patron,
use it to log in into Koha
- Create 2 invoices, try to merge them
=> There is no way to merge it
- Add the permission
=> Now you can merge the invoices
Sponsored-by: Galway-Mayo Institute of Technology
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add a new permission to delete acquisition baskets
Test plan:
- Remove the new permission "delete_basket" for a given patron,
use it to log in into Koha
- Create basket, try to delete it
=> There is no way to delete it
- Add the permission
=> Now you can delete the basket
Sponsored-by: Galway-Mayo Institute of Technology
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add a new permission to delete invoices
Test plan:
- Remove the new permission "delete_invoices" for a given patron,
use it to log in into Koha
- Create an invoice, try to delete it
=> There is no way to delete it
- Add the permission
=> Now you can delete the invoice
Sponsored-by: Galway-Mayo Institute of Technology
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add a new permission to edit invoices
Test plan:
- Remove the new permission "edit_invoices" for a given patron,
use it to log in into Koha
- Create an invoice, edit it (click "detail")
=> You can see the detail of the invoice, but cannot edit it. It's a read-only view.
- Add the permission
=> The form is back and you can modify the invoices and save the changes.
Also, you are able to create adjustments.
Sponsored-by: Galway-Mayo Institute of Technology
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
New permission to reopen a closed invoice.
Test plan:
- Remove the new permission "reopen_closed_invoices" for a given patron,
use it to log in into Koha
- Create an invoice, close it
=> You are not able to reopen the invoice
- Add the permission
=> You are able to reopen the invoice
Sponsored-by: Galway-Mayo Institute of Technology
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If 'Actual cost' has not been set then it has the value of 0.00 which
Perl evaluates to true so this patchset resets it to 0, so the fallback
to ecost_tax_included/ecost_tax_excluded happens.
Test plan:
1. Add item to acquisition basket (make sure the vendor has: tax rate: 15%, 'List prices: Include tax', 'Invoice prices: Include tax')
2. Set 'Vendor price' = 10 and do not set 'Actual cost'
3. Save order
4. Observe basket.pl shows 'Total tax exc.' has a value of 0.00 and GST
column has value of -8.70
5. Jump into the database:
select tax_value_on_ordering from aqorders where
ordernumber=<ordernumber>;
[You can get the ordernumber from clicking on the 'Modify' line the item
is listed in]
6. Observe a negative value: -8.70
7. Apply patch and restart plack
8. Add a second item to the basket
9. Set 'Vendor price' = 10 and don't set 'Actual cost'
10. Save order
11. Observe basket.pl shows 'Total tax exc' has value of 8.70 and GST
has value of 1.30
12. Repeat step 5 and observe tax_value_on_ordering = 1.30
13. Run t/Prices.t unit test:
sudo koha-shell <instancename>
prove t/Prices.t
Sponsored-by: Horowhenua District Council, NZ
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We did not take into account the vendor selected.
Test plan:
1. Choose Vendor
2. Create Basket
3. Assign a new vendor
Without the patch this new vendor is not changed
With the patch applied the vendor is changed
4. Edit the basket, change the vendor
Reported-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Rhonda Kuiper <rkuiper@roundrocktexas.gov>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If no late order we got:
"Argument passed to the 'IN' operator can not be undefined"
It highlights a context error
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>
This was the only occurrence of GetBooksellersWithLateOrders and it was
the only subroutine of C4::Bookseller
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>
This patch is removing the use of GetBooksellersWithLateOrders and use
the late order list to generate the vendors.
Test plan:
Create several vendors, several orders, close the baskets
Also create vendors that do not have orders (or basket not closed)
Go to the late orders page and confirm that the list of vendors is
correctly filled, select one, you can see the "select all" link in the
header of the table
QA: that would be good to test this with production data and compare
execution time.
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>
Specify the UTF-8 charset in the header and Encode the output to avoid encoding issues
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This new enhancement adds the ability to create a CSV profile for the late
orders export.
Prior to this, the CSV profile was hardcoded in a template and not
editable (unless you modify the .tt file of course).
The main difficulty of the request was to make the multiple claims dates
accessible from the CSV profile. So far we only accept columns from the
database. However we would like to use the Koha::Acquisition::Order
object to make things easier (it had a ->claims method to access the
different claims).
To acchieve this, we are going to accept the TT syntax for that CSV profile.
It means that only CSV profiles created for 'late_orders' will have the
capability to use the TT syntax (can be extended later of course if
needed).
The alternative was to use specific placeholders, like %claims_count%,
%claimed_date%, but it sounded more powerful and flexible to allow the
TT syntax instead.
Note that the former export (template based) still exists and is the
default option.
Test plan:
0. Apply the patches and execute the update database entry
1. Create some orders, close the basket
2. Claim some of the orders
3. Note the new button at the bottom of the table that have several
entries.
=> The first entry will generate a CSV file using the previous method
=> The second entry will generate it using the new CSV profile, note
that the number of claims as well as the different claims date are
displayed.
4. Bonus point: Edit the CSV profile (Home › Tools › CSV export
profiles) that is named "Late orders (csv profile)", or create a new
one, and modify it.
Export the late orders using this CSV profile and confirm that the
generated CSV file is the one you expect.
Sponsored-by: Institute of Technology Tralee
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Angela O'Connor Desmond <angela.oconnordesmond@staff.ittralee.ie>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
So far we only record the number of claims and the date of the last
claim, in the aqorders table.
To keep track of the different claim dates, this patchset is going to
make the following DB changes:
* Create a new table 'aqorders_claims' (id, ordernumber, claimed_on)
* Remove the two columns from the aqorders table: claims_count and
claimed_date
This will allow to display the different claim dates where needed: on
the late orders page, and the basket page.
To avoid additional fetches of Koha::Acquisition::Orders, GetLateOrders
has been moved to Koha::Acquisition::Orders->filter_by_late
That way we are going to add consistency, robustness, and cover the
feature with new tests.
Test plan:
0/ Create a bunch of new orders. Make sure they are from different
vendor (with different delivery time).
1/ Go to the late orders page and claim some orders
2/ Reclaim some of those orders
3/ Confirm that you can see the different claim dates for a given orders
(the history of the late orders claims is kept and displayed)
4/ Bonus point: Regression tests:
a. Modify the closedate of the basket in the database. That
will allow you to make sure the patch set did not introduce regressions.
It would be good to test the different filters on the late orders page:
* delay
* Estimated delivery date from/to
* Vendor
b. Confirm that the subtotal and the total values from the late orders
page is correct.
c. Test the update database entry: do not apply these patches, claims
some orders against master. Apply the patch, execute the update DB entry
then confirm that the number of claims is correct (note that the dates
will not as it is not possible to guess them).
QA note: the branchcode parameter has been removed from filter_by_late.
At first glance it seems that it was not used.
Sponsored-by: Cork Institute of Technology
Signed-off-by: Angela O'Connor Desmond <angela.oconnordesmond@staff.ittralee.ie>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This is simply a SQL change that makes things a bit easier to read
and also prevents too much data being returned in a large system
To test:
1 - Have some orders in your system in the ordered status
2 - Click the 'Ordered' amount for your budget from Acquisitions home
3 - Note the view of orders, possibly screen shot
4 - Apply patch
5 - Restart all the things
6 - Reload the ordered page
7 - Confirm nothing has changed
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There are 2 subroutines from C4::Acquisition that could be removed:
- GetLastOrderReceivedFromSubscriptionid
- GetLastOrderNotReceivedFromSubscriptionid
After bug 20726 only GetLastOrderReceivedFromSubscriptionid will be used
(from acqui/neworderempty.pl) and this call could be replaced easily with Koha::Acquisition::Orders
The code (+ tests) related to these 2 subroutines could then be removed.
The parameters for the search is basic and does no really deserve its own subroutine.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch displays and let the librarian edit the suggestion.reason
information when receiving an order.
Note that if no reason was given the edit is not possible (easily
modifiable if needed but it seems that we do not want to display too
much details unnecessarily)
Test plan:
- Create a suggestion and fill the reason
- Create an order from this suggestion
- Close the basket and start receiving the order
=> The reason is displayed and editable
- Modify the reason and click Save
- Receive again
=> The reason has been correctly modified
- Play with the "Others..." option and give a specific reason
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a currency dropdown list to the Actual cost field when
receiving items in the acquisition module.
The idea is to let the librarian entered a price in a foreign currency
that will automatically be converted in the local currency ('active').
This converted value will be use as the actual cost once the form is
submitted.
Test plan:
- Create several currencies with different rates
- Create an order, close the basket and receive
- On the receipt page you will notice a new "change currency" checkbox
right close to the 'Actual cost' input.
- Check it
=> The 'Actual cost' input is readonly and a new line appears at the
bottom.
- Enter a number and select a currency
=> The 'Actual cost' input is automatically filled with the converted
value
- Save
=> The converted Actual cost has been inserted in the database.
Sponsored-by: Athlone Institute of Technology
Signed-off-by: Devinim <nazli@devinim.com.tr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Apply mandatory defaults from the ACQ framework to records from external
source in Acquisition.
Test plan:
[1] Add 'BK' as mandatory default in ACQ framework for 942$c.
[2] Add order to basket via external source.
[3] Check 942$c on detail page of new record, MARC tab.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
No other changes than whitespace, guys.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
On bug 24430 we replaced the call to CountBiblioInOrders with
Koha::Biblio->active_orders
In case the bibliographic record is deleted, the count must be set to 0.
This prevent the app to crash with:
Can't call method "active_orders" on an undefined value at
/home/vagrant/kohaclone/acqui/parcel.pl line 244
Test plan:
Create 2+ orders
Receive one, delete it, delete the bibliographic record
Receive the order one
=> Without this patch, on the parcel page you should get the error
=> With this patch applied you must be allowed to finish the receive
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Starting to replace the ModItem calls with Koha::Item->store
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The subroutine SearchItemsByField is only called once and can be
replaced easily with SearchItems
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
NO_LIBRARY_SET was used when the DB user was logged in. Since bug 20489
it's not longer possible. We could remove the code.
One occurrence left in C4::InstallAuth as there is no (real) logged in user yet.
Test plan:
* Install Koha to make sure NO_LIBRARY_SET is not needed during the
install process
* Login into Koha
* Make sure the your library's name is displayed correctly in the header
* Set another library
* Confirm that the library's name is updated
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No problem during install, nor changing library.
Fixed (pre-existing) tab in circ/branchtransfers.pl
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We allow for the user to add multiple users to this field, and the
search function expects and array. We have been treating it as a scalar
TO test:
1 - Have an open basket in acquisitions
2 - Add to basket - from an existing order (copy)
3 - Enter a name in the 'Basket created by' field and select a user
4 - Hit search
5 - ISE (Can't use string ("1") as an ARRAY ref while "strict refs" in use at /usr/share/koha/lib/C4/Acquisition.pm line 2482.)
6 - Apply patch
7 - Repeat 1-4
8 - Success!
9 - Test with mutiple 'created by' entries as well
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1) Apply the patch
2) Have a Z39.50 endpoint with attr 31 defined - Library of Congress
supports this
3) Try to find some biblio records through Z39.50 using the new field
"Publication year" in acquisition module
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
A successful message says that the email has been sent and the order has
been claimed, but nothing happened.
Test plan:
0. Do not apply this patch
1. Create a new vendor, does not create a contact
2. Create some orders, close the basket
3. Go to the late orders page and claims some orders
=> You get a successful message, but the claim has not been done!
4. Apply this patch
5. Claim the orders
=> You get an error
6. Set a contact for the vendor
7. Claim the orders
=> Success
In the docker container, you may need to:
% apt install postfix
% postfix start
Edit /etc/hosts
127.0.0.1 localhost localhost.localdomain
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We certainly faced 3 similar bugs due to this syntax: bug 23006, bug
22941 and bug 17526.
To prevent other issues related to this syntax this patch suggests to
replace them all in one go.
Test plan:
Confirm that the 2 syntaxes are similar
Eyeball the patch and confirm that there is no typo!
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch modifies basketgroups.pl so that existing data about a basket
group's billing and delivery place are correctly preselected in the edit
form. These fields shouldn't reset to the logged-in user's home branch
just because they have an empty value.
To test, apply the patch and go to Acquisitions -> Vendor -> Basket
groups.
When adding or editing a basket group the pre-selected value for
"Billing place" and "Delivery place" should be correct:
- When creating a new basket group: The logged-in user's library
should be pre-selected.
- When editing a basket group which has a library defined for either
the billing or delivery places, the correct library should be
pre-selected.
- When editing a basket group which has no library defined for either
the billing or delivery place there should be no library
pre-selected (the "--" option should be pre-selected).
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removes some methods that were introduced for API usage in
the first iteration of the object embedding development effort.
Those methods were obsoleted by bug 24528, which introduces a smarter
way for Koha::Object->to_api to embed *_count attributes on the output
structure based on the relationships and a call to ->count.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Biblio.t
=> SUCCESS: Tests pass
3. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removes the "neworderbiblio" script and template which are
made obsolete by the "search to order" feature.
deleted: acqui/neworderbiblio.pl
deleted: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/neworderbiblio.tt
Some documentation in addorder.pl has been corrected to remove reference
to neworderbiblio.pl.
To test, apply the patch and verify that the correct files have been
removed.
Search the Koha codebase to verify that no links to
acqui/neworderbiblio.pl remain.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
and remove 'scalar' keyword in calls where it's not needed.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch replaces the only uses of CountBiblioInOrders and makes that
code use $biblio->orders->count instead.
Test nothing breaks in basket.pl and parcel.pl
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Replace inputs to edit notes by a link opening a modal, similar
to the basket summary page. This makes it possible for the notes
to appear in the datatable exports.
Also fix exporting with the export as csv button at the bottom
of the page to export notes.
Test plan :
1) In the late orders table (acqui/lateorders.pl), a link should
appear in both the internal and vendor note column, following the
current value if it exist.
-> This link should read "Add ..." if there is no existing note
or "Edit ..." if there is.
2) Click on the link. A modal should appear. Confirm that saving a
note works as expected.
3) Try exporting to any format using either the button at the top
of the table or the one at the bottom of the page.
-> The three new columns and their values should appear in the
export.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
0) Make sure you have a late order
a) Create a test vendor unless you have one
b) Create a test basket unless you have one
c) Close the basket to mark the order as late
1) Go to the late orders table
Before patch : Orderno, ISBN, vendor notes, internal notes are absent
After patch: fields are present
2) Edit the vendor note and/or the internal note
3) Press the save notes button
4) Refresh page and cache (CTRL+F5), if notes have been correctly saved, your modifications should be displayed.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 8417 added the ability to edit the date received, but a merge
conflict was wrongly resolved during a rebase of
commit 20d9ed618f
Bug 13321: Rename variables
Test plan:
Create an order
Receive it
Set a date (different from today)
=> The date you picked should have been set in DB for the order
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ability to create a new purchase suggestion from an
existing title. This will prevent the creation of bibliographic records
that already exist in the catalogue. Also it will ease the process
during acquisition.
Test plan:
- Login at the OPAC and go to the detail of a bibliographic record.
- Note that there is a new link "New purchase suggestion for this title"
on the right of the screen
- Please suggest an other icon if that one is not appropriated
- Click on it and submit your new suggestion
=> You should not get the confirmation screen (introduced by bug 14973)
warning you that the title already exists.
- Login staff side and order from this suggestion.
- Receive items and confirm that a new bibliographic record is not
created.
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When exporting a basket group, the names of the files are different:
* pdf => aqbasketgroup.name(.pdf)
* csv => aqbasketgroup.id(.csv)
Better to use basketgroup's name for consistency and readability
Test plan:
Create a basketgroup and export it in pdf and CSV. The name of the
generated file must be the basketgroup's name suffixed by the extension.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch modifies two pages so that the "Uncertain price" information
is shown by the template rather than the Perl script, making the text
translatable.
To test, apply the patch and go to Acquisitions.
- Locate or create an order in a basket which has an uncertain price.
- When viewing the contents of that basket the order which was marked
as having an uncertain price should be labeled "Uncertain."
- The same should be true for the invoice page. If you don't have an
existing invoice with an "uncertain" order,
- Go to "Receive shipments" for the vendor your "uncertain" order is
with.
- Create a new invoice.
- Receive one or more orders which has an uncertain price.
- Press the "finish receiving" button.
- In the "Invoice details" section of the invoice page you should
see the "Uncertain" label on the correct order.
Signed-off-by: Christophe Croullebois <christophe.croullebois@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
For the invoice view: close, receive, reopen, mark prices uncertain, go
to the invoice page (not sure it's expected however)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Create a new basket in acq, mark it as 'standing'
2 - Add an item, leave the RRP and Vendor price as 0
3 - Receive shipments for the vendor
4 - Select the title from this basket
5 - On receipt enter an actual cost
6 - Finsih receiving
7 - Go to the basket
8 - Note the total for the order and the basket are 0, keep this browser tab open
9 - Open a new browser tab and create a new non standing basket
10 - Add to basket, again with no RRP or vendor price
11 - Close the basket, receive the item
12 - Enter an actual cost on receipt
13 - Return to view the basket
14 - Total and order are $0
15 - Apply patch
16 - Refresh the basket in both tabs
17 - You now see the actual price for the orders
Signed-off-by: Rhonda Kuiper <rkuiper@roundrocktexas.gov>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
