Sometimes it's really helpful to see all orders for a basket, a
vendor or a standing order, including the cancelled ones.
Currently this is not possible, as we have search options for
every single status and one for "any except cancelled",
but no "Any status" option.
This patch adds the "Any status" option. The sometimes
appearing empty entry is updated to "Any status except cancelled"
as this is what it does.
Testing data:
* Requires multiple order lines with different order status
* Must include at least one order line with status 'cancelled'
To test:
* Go to acquisitions
* Open the advanced search page from the top search options:
Order search > config icon > Advanced search link
* Verify the status pull down looks as described above
* Apply patch
* Verify there is now an "Any status" option in the pull down
* Try searches for different status, including "Any status"
* Verify the results are as expected
* Create a new basket
* Create an order line by 'From an existing order (copy)'
* Verify the search form there also works as expected
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch depends on Bug 31840.
To test:
1) Edit an order and increase the price so that you would expect it to
trigger a warning that you will exceed the amount allowed for this Fund
2) Confirm the warning is triggered
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Apply patches
2. sudo koha-upgrade-schema <instance>
3. Restart services
4. Set TaxRates syspref = 0.15
5. Create a new fund with amount = 1000
6. Add an order to a basket with the following values:
- Fund = Choose the fund from step #5
- Quantity = 1
- Vendor price = 10
- Tax rate = 15%
- Discount = 20%
- Retail price = 10.00
- Replacement cost = 10.00
- Actual cost = 10.00
- Ensure the basket belongs to a vendor with ("List prices" = "Don't include tax" and "Invoice prices" = "Don't include tax")
7. Go to the Acquisitions home page
8. Confirm the 'Ordered' column for the step #5 fund contains 9.20
9. Click on the 9.20 link and confirm the ordered.pl page that loads
also contains 9.20 as the 'Subtotal'
10. Change 'CalculateFundValuesIncludingTax' = 'Exclude'
11. On the Acquisitions home page confirm the 'Ordered' column now
contains 8.00
12. Click on the 8.00 link and confirm the ordered.pl page also contains
8.00 as the 'Subtotal'
13. Close your basket and receive your order - change the 'Actual costs'
= 8.00 (the $10 retail price less the 20% discount, tax exclusive)
14. Go to the Acquisitions home page and confirm the 'Spent' column now
contains 8.00
15. Click on the 8.00 link and confirm the spent.pl page also contains
8.00 as the 'Subtotal'
16. Change 'CalculateFundValuesIncludingTax' = 'Include'
17. Confirm the 'Spent' column on the Acquisitions home page now shows
9.20
18. Click on the 9.20 link and confirm the spent.pl page also contains
9.20 as the 'Subtotal'
Sponsored-by: Waikato Institute of Technology, New Zealand
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds Authorized Value handling for the display of sort1 and
sort2 fields in the acquisitions basket display page.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: emlam <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There is no need for this code to have a hard coded list of fields directly in the code.
Any invalid keys would be skipped anyway.
If we refactor this code then adding new fields will be much simpler.
Test Plan:
1) Set up your MARCItemFieldsToOrder, verify everything is working
2) Apply this patch
3) Restart all the things!
4) Verify there has been no change to the MARCItemFieldsToOrder
functionality
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
These values are stored at the order level, not per item. This patch simply sets the order values from the values retrieved from MarcFieldsToOrder even inf MarcItemFields to order is being used for other fields
To test:
Setup -- Set systempreferences below
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
Stage the attached bib-303.marcxml file
Add to basket from the staged file
Note that discount and sort1 and sort2 are not populated per the Marc
Apply patch, restart all
Stage and add to basket again
Confirm discount and sort1 and sort2 are populated correctly
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
At the moment it's quite a lot of clicks to get from the basket
summary to the invoice something was received in. This adds a nice
shortcut by creating a new column for the invoicenumber in the basket
summary table.
To test:
* Make sure you have a basket with some received and unreceived
order lines
* Verify that the (received) shows for your received lines
* Verify no invoice number or link to it in sight
* Apply patch
* Verify that there is now a column for the Invoice containing
the invoice number as a link to the invoice
* Test with a staff patron, that doesn't have edit_invoices permission
* Verify that now instead of a link you see the invoice number as text
Be happy, sign off ;)
Note: this doesn't change the CSV export. The way the CSV is built is
quite different to the summary table, so it would be better handled
in a separate bug/patch. The columns are already quite different!
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Émily-Rose Francoeur <emily-rose.francoeur@inLibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch allows the default budget to be used as a fallback if no budget is selected. Currently the default budget is set using lines 129-133 but then is never used.
QA follow-up:
- perl tidied
- budget_codes changed to budget_ids for consistency
Test plan:
1) Apply patch
2) restart_all
3) Follow the steps from the bug description
4) Order lines should be added properly
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Rearranged comments
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch moves the dropdown to use select2 and avoids loading all
vendors at page load.
To test:
1 - Create some extra vendors in your system, ideally over 20
2 - Search for a vendor in acquisitions
3 - Click 'New->basket'
4 - Note the dropdown of all vendors
5 - Choose a vendor and create a basket
6 - Apply patch
7 - Repeat
8 - Note only a partial list of vendors is loaded
9 - Search in the dropdown and confirm vendors are returned
10 - Select a vendor and create the basket
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When an already received order line is modified/edited,
we experience data loss. Most prominently, we will lose the
linked invoiceid. Therefore we should not allow editing an
order line that was already received. If something needs to be
changed, the receipt should be cancelled first.
To test:
* Create basket as standing order with items added in cataloguing
* Add an order line
* Receive shipment
* Go to the basket summary page, click on 'Modify'
* Change the actual cost
* Save
* Verify that the invoice is now empty
* In the database aqorders.invoiceid will be NULL
* Apply patch
* Receive another shipment for the standing order
* Go back to basket summary page
* Verify the 'Modify' link is no longer present
* Click 'Modify' on the unreceived order line
* Edit the URL parameter odernumber to have the number of an
already received order line
* Verify you see a nice error message:
This order cannot be edited, the basket is closed or the order was already received.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch is the main patch of this patch set, it contains the
controller acqui/vendor_issues.pl, its corresponding template, and some
links to this script.
It adds:
* A new DB table aqbookseller_issues linked with the aqbooksellers table
* A new subpermission acquisition.issue_manage
* A new authorised value category VENDOR_ISSUE_TYPE and two examples
MAINTENANCE and OUTAGE
* A new controller couple acqui/vendor_issues.[pl,tt]
Test plan:
0. Apply the patches, run updatedatabase and restart_all
1. Go to the acquisition module, create a new vendor or use an existing
one
2. Create a couple of issues for this vendor
3. Edit/Delete and search for those issues
This is the basics for tracking issues with vendors.
Suggestions welcome, on follow-up bug reports.
Signed-off-by: Jonathan Field <jonathan.fieeld@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When creating items at receiving, the generated data structure didn't
match what the code expected, so this patch adapts the code to match the
new data structure introduced by bug 8179.
Once I fixed that, I noticed that the $.ajax request payload, when it
contains an array parameter, it renames it like `param[]`. So the
finishreceive.pl controller is adjusted to this behaviour for the 'on
receiving' use case.
To test:
1. Apply this patch
2. Create a basket with 'create items on receive'
3. Create an order line
4. Close basket
5. Receive shipment
6. Enter invoice number
7. Click on Receive link in the table
8. Fill out item form, make sure all mandatory fields are set
9. Save
10. Verify that the order line is marked as 'received'
11. Verify that there item is created on the record
=> SUCCESS: Works as expected
12. Sign off :-D
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 allows to create additional fields for order lines.
Once created, these fields can be filled during order line creation or
modification.
If additional field is linked to a MARC field, there are two possible
scenario:
- MARC field mode = get: The field cannot be modified and its value is
retrieved from the bibliographic record (current behaviour)
- MARC field mode = set: The field can be modified and its value is
saved to the bibliographic record (new behaviour)
If additional field is linked to an authorised value category, then
authorised values are used. If not directly linked to an authorised
value category, but linked to a MARC field, a search for an AV category
is made on MARC default framework.
This patch doesn't display additional fields value anywhere (except in
order line creation/modification). Future patches will do that.
Test plan:
1/ Go to Acquisitions home
2/ In the left menu, click on "Add order line fields"
3/ Click on "New field" button
4/ Give the field a name (unique), no AV category and no MARC field.
5/ Save.
6/ Create 5 other fields:
a/ no AV category, a MARC field not linked to AV category, MARC field
mode = get
b/ no AV category, a MARC field not linked to AV category, MARC field
mode = set
c/ no AV category, a MARC field linked to AV category, MARC field
mode = get
d/ no AV category, a MARC field linked to AV category, MARC field
mode = set
e/ an AV category, no MARC field
7/ Create everything you need to be able to create order lines
(supplier, basket, ...)
8/ Create an order line. At bottom of the page, you should see your
additional fields, with authorised values dropdrown list for fields
(c), (d) and (e). Fields (a) and (c) should be disabled.
9/ Fill these fields with some data and save order line
10/ check that data was correctly saved into biblio for fields (b) and
(d), but not for (a) and (c)
11/ modify the same order line, check that values you've filled are
correctly retrieved and that values for (a) and (c) were correctly
retrieved from the bibliographic record
12/ modify all values, save, and check biblio once again
Signed-off-by: Harold Dramer <harold.dramer@nyls.edu>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch implements the code to allow a patron to receive multiple
orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page
To test:
1. apply all patches
2. updatedatabase
3. Go to system preferences and allow AcqReceiveMultipleOrderLines
4. In acquisitions module, create a vendor if you don't have one and add
3 baskets.. one with create items on ordering, one with create items
on receiving and finally one with create items when cataloguing
5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods.
6. Close all baskets and receive shipment.
CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected"
7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page
8. Check some of the checkboxes
CHECK => "Receive selected" button shows how many rows are selected
9. Go to the next page and select some more rows
CHECK => Changing page does not modify how many rows where selected
10. Go back to previous page
CHECK => Previously selected rows are still selected
11. Reload the page to deselect all rows
12. Select only one row and click on "Receive selected" button
CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked.
13. Click on cancel to go back to parcel.pl page
14. Select all rows (even the ones from the next page of the table) and
click on "Receive selected"
CHECH => In orderreceive.pl page there is a table with all selected rows
15. Ensure table has more than one page, as in step 7
16. Click on the "edit" link in the last row of the current page
CHECK => A modal window is displayed with 4 tabs within: Info,
Accounting, Receipt history and Items
CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos
order, 'Cancel' to close the modal without keeping modifications, 'Save'
to close modal keeping modifications and 'Next' to go to the next order
CHECK => Even that we are at the end of the current page, 'Next' button
is still available
17. Click on 'Next' button
CHECK => The table behind the modal now displays the next page, and the modal was not closed
18. Click on 'Previous'
CHECK => The table behind the modal went back to the first page, and the modal was not closed
19. Click on 'Previous' button till you reach the first row of the first
page
CHECK => Only when you reach the first row of the first page 'Previous'
button gets disabled
20. Click on 'Next' button till you reach the last row of the last page
CHECK => Only when you reach the last button of the last page 'Next'
button gets disabled
21. Check that behaviour for the different types of order are still the
same
a. For orders that where created through suggestion, check that the
suggestion info is present in Info tab. If when suggestion was accepted
you set a reason, a dropdown to change the reason shoul display also.
b. For orders that where created through subscriptions, check that
the Items tab is disabled, and the Receipt history is enabled. On
accounting tab you should be able to change quantity ordered. If there
were less items received than ordered, the next time you receive this
order the child order generated from this one shoul appear in receipt
history.
c. For orders that don't come from subscription and creates there items on ordering, Receipt history
should be disabled, and a table with prefilled items shold appear in the
Items tab. You can edit them and the changes should appear in the item's
row.
d. For orders that don't come from subscription and creates there
items on receiving, Receipt history should be disabled, and a form to
create the items should appear in Items tab. When you add an item a
table should appear.
e. For orders that don't come from subscription and creates there
ites on cataloguing, Receipt history and Items tabs should be disabled.
f. Any changes made in quantity (received or ordered) or funds in the modal should be
reflected in the table if you click save from the modal.
22. Once you've done all you checking and verifications click save
23. While saving a progress bar should appear
24. If no error was detected, you should be redirected back to parcel.pl
page
25. If an error or warning was detected (like there is an order with 0
items to receive) the save button should be disabled and warnings
are dispayed.
26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
Sponsored-by: Virginia Polytechnic Institute and State University
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes `filter_by_lates` use the `filter_by_active` method
instead of an ad-hoc query filter. It has the advantage that it
considers standing orders too.
No behavior change, tests should still pass.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patchset is adding the ability to create interfaces for vendors.
An interface is a website, software, or portal that you use to manage orders or
gather statistics from the vendor/organisation.
It will help librarians to keep track of those different information
within Koha.
* new DB table aqbookseller_interfaces(id, vendor_id, type, name, uri,
login, password, account_email, notes)
* new AV category VENDOR_INTERFACE_TYPE with 3 example values ADMIN,
ORDERS, REPORTS
* new pair of Koha classes Koha::Acquisition::Bookseller::Interface[s]
* new method to retrieve the interfaces from the vendor
Koha::Acquisition::Bookseller->interfaces
* Add/Delete interfaces when editing a vendor
* Display the interfaces on the vendor show view
Test plan:
- Add a new vendor
=> Notice the new "Interfaces" block
- Create some interfaces
=> They are display on the vendor show view
=> The password is hashed and can displayed on the demand
QA Note:
The "contacts" code is not very nice and I didn't want to replicate it,
so I went another way and tried to make the code reusable, for further
reutilisation.
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Do not apply the patch yet
2. Make sure you have an ACQ biblio framework with some framework
plugins enabled. Create it if you don't.
3. Enable UseACQFrameworkForBiblioRecords system preference
4. Create a new acquisition basket.
5. On this new basket, click on "+ Add to basket", then "From a new
(empty) record"
6. You should see a simplified MARC editor based on ACQ framework.
Confirm that the plugins are not enabled (no visible buttons, nothing
happening on focus/blur)
7. Apply patch
8. Repeat step 5
9. You should now see the plugins' buttons (only if you enabled plugins
that use the 'click' event)
10. Confirm that the enabled plugins work correctly
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patchset is adding the ability to create aliases for vendors. It
will then be easier to search for vendors.
* new DB table aqbookseller_aliases(id, vendor_id, alias)
* new pair of Koha classes Koha::Acquisition::Bookseller::Alias[es]
* new method to retrieve the aliases from the vendor
Koha::Acquisition::Bookseller->aliases
* The api spec changes to allow aliases to be embeded on
GET /acquisitions/vendors
* Add/Delete alias when editing a vendor
* Display the aliases on the vendor show view
* Search vendors by aliases
* Display the aliases in the dropdown list of the vendors in the ERM
module
Test plan:
- Create a vendor, add it some aliases
- Edit the vendor, remove some aliases
=> Behaviour must be consistent
- Search the vendor in the acquisition module by its aliases
=> The vendor must be returned in the result
- Go to the ERM module, add a new agreement or license
=> Notice that the dropdown list of the vendors is displaying the
aliases, that make vendors searchable by their aliases
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch uses the replace method added in last patch to ensure
records are overlayed when added to a basket
To test:
1 - Stage the sample file on this report using the options below
(If not using sample database simply save a record as marc from the details page, then change the title in the interface and import the saved version)
2 - Make sure to match using KohaBiblio (999c)
3 - Set option "Replace existing record" if match found
4 - Once record is staged go to Acquisitions
5 - Find a vendor and select/create an open basket
6 - Add to basket from the staged file
7 - Add order info and save
8 - Check the record, title is unchanged - Sample file should add 'New and improved!'
9 - Check the staged records batch - note the diff shows that new record should have overwritten
10 - Apply patch
11 - Stage file, match on KohaBiblio, set action if matching record found to 'Ignore incoming record'
12 - Add to basket from the staged file and save
13 - Confirm record not overlayed when not reuqested
14 - Stage file, match on KohaBiblio, set action if mathc record found to 'Replace existing...'
15 - Add to basket from staged file and save
16 - Confirm the record is updated to 'New and improved!'
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch:
- fixes some indentation
- flips unless-else to if-else for readability
- expands some comments for clarity
- removes unused biblioitemnum variable
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On 25655 we added a new patch to store the invoice unitprice and
currency even if it's the active currency. Here we then want to display
the column if at least one order has an invoice price in a currency that
is not the active one.
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>
On bug 25655 we are storing the unit price and currency used for
invoicing. Here we are displaying them on the invoice page.
Test plan:
Reuse the test plan from 25655 and go to the invoice page
Notice that a new 'Invoice price' column is displayed if at least one
order of the invoice had a price given in a foreign currency
We could discuss the display of the prices here, we've decided to not
format them.
We cannot do better for now as we are not storing the format along with
the currency.
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>
And fix a bug they caught. We need to undef if a modification is made
and invoice_currency is removed.
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>
Bug 24158 allows to calculate the actual cost on time of receive from a foreign currency.
This new enhancement is storing the price and the currency in database, into two new columns
invoice_unitprice an invoice_currency
Test plan:
Create a new order with several items to receive
Receive one or more items, and tick "change currency" on the order
receive page
Select a currency and finish the receiving
In DB notice that the price and the currency have been stored.
Receive remaining items and confirm that the form is prefilled with
previous price and currency
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>
Calling GetBudgetHierarchy from acqui/histsearch.pl
is slow if param skiptotals is not used.
To test:
1. Open browsers Console -> Network (F12).
2. Navigate to Order search page and perform search.
=> Take a note how long it takes to load the Search results page.
3. Apply this patch.
4. Repeat step 2.
=> Page should now load faster.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Thispatch adds the new method and alters addorderiso2907.pl to use this
rather than GetRecordImportMatches
To test:
1 - Import the attached record several times
2 - Set up a matching rule:
TitleAuthor threshold: 100
Matchpoint:
search index: title, score: 100, tag: 245$a
search index: author, score: 100, tag:100$a
3 - Edit one of the imported records to have a different author
4 - Stage the file again. and match using the matchpoint above
5 - Note that matches are found and listed on batch management, with the lowest scored match last
6 - Choose that match
7 - In acquisitions, add to a basket from the staged file
8 - Check the box for the record
9 - Note the match lists the biblionumber for the highest scoring match, not the chosen one
10 - Add an order and note it is for the wrong biblio
11 - Appy patch
12 - Restart_all
13 - Stage the file again and choose a lower scoring match
14 - Confirm when adding to basket this match is preserved
15 - Complete order and verify correct biblio ordered
16 - Stage again, select no match
17 - Confirm no match listed when adding to basket, and choose 'Do not look for matching records' while adding
18 - Confirm order is created on a new biblio
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:
Go to acqui/addorder.pl.
Create two items.
Check if results still match your expectations.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When the estimated delivery date was entered on adding or modifying
and order, it was not saved to the database.
To test:
* Add new order, fill in estimated delivery date
* Save
* Verify the estimated delivery date is empty
* Modify order line, date will also not be saved
* Apply patch
* The date should now save and update correctly
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On bug 14860 an 'else' was removed, assuming the price fields were set before discount,
this was incorrect. This patch renames the variable and always set the price, only discounting
ecost if a discount, but setting the values even if not
To test:
0 - Have a vendor with a discount of 0% specified (no discount)
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 $0 order line
6 - Repeat with another vendor with a 10% discount and confirm that is correct
7 - Apply patch
8 - Repeat 2-4
9 - Add the order and confirm $10 price
10 - Repeat with discounted vendor, confirm prices are set discounted correctly
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
