Resolve (line numbers based on 16.11.x):
Use of uninitialized value in hash element at acqui/basket.pl line 337.
Use of uninitialized value in hash element at acqui/basket.pl line 338.
Use of uninitialized value in hash element at acqui/basket.pl line 340.
Use of uninitialized value in hash element at acqui/basket.pl line 342.
Use of uninitialized value in hash element at acqui/basket.pl line 344.
Argument "" isn't numeric in multiplication (*) at koha-tmpl/intranet-tmpl/prog/en/modules/acqui/basket.tt line 486.
Argument "" isn't numeric in multiplication (*) at koha-tmpl/intranet-tmpl/prog/en/modules/acqui/basket.tt line 591.
Test plan:
If you have older acq data, you may have records in aqorders with field
tax_rate_on_ordering is NULL. These orders will trigger the above warns.
If you do not have, you could simulate by setting this field to NULL.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Move to aqinvoice_adjustment
Move to Koha::Acquisition::Invoice::Adjustments
Test if variable exists before count
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds the ADJ_REASON authorised value category tot he atomic
update, and fixes code to display a hint of no reasons are defined
other minor updates to remove warns in logs
To test:
Apply patches
Run updates
Check authorised value categories to see ADJ_REASON exists
Add an adjustment, not you have no reaosn drop down
Note there is a hint if you hover
Add a value to ADJ_REASON
add another adjustment, note you can now add reasons (or not)
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
https://bugs.koha-community.org/show_bug.cgi?id=19166
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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patchset adds the ability to add adjustments to an invoice, one can
provide a reason, an adjustment amount, select a budget, and choose
whether to encumber the funds before the invoice is closed or not
To test:
1 - Create a new invoice with or without a shipping cost
2 - Note there are no existing adjustments
3 - Add an adjustment
4 - Submit the form withno changes, nothing happens
5 - Update the adjustment you created, ensure changes are saved but no
extra adjustment created
6 - Add another invoice prodiving only reason or amount (you can have 0
value adjustments)
7 - Verify the adjustment total at bottom is correct
8 - Recieve some orders
9 - Verify totals are correct
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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
New MySQL column: aqorders.createdby
Creator's name is displayed on order's receive pages (acqui/orderreceive.pl
and acqui/parcel.pl)
On acqui/orderreceive.pl it replace the name of basket's creator
On acqui/parcel.pl, to avoid adding more data in the table of pending
orders, it is shown in a popup like MARC and Card views
Test plan:
1/ Run updatedatabase.pl
2/ Create a new order and go to the receipt page (acqui/parcel.pl)
3/ Click on "Order" link in column "More" (previously "View record")
4/ A javascript popup should appear with your name in it. Close the
popup.
5/ Click on "Receive" link
6/ Your name should appear in front of "Created by" label, to the right
of the page.
Patch updated with use of atomic update.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The permission for EDI is edi_manage, but 2 pages asked
for manage_edi, allowing users not to access those.
To test:
- Add edi_manage to your permissions
- Try to access the EDIFACT messages from the
acq start page
- Verify it doesn't work
- Apply patch and try again
- You should be able to access the page now
- Try to access the other page directly (if you don't
have EDI data):
/cgi-bin/koha/acqui/edimsg.pl
- Verify you can access the page and don't get a
permission error
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patches reduces the number of SQL calls by combining multiple calls to the recursive functions GetBudgetSpent(), GetBudgetOrdered(), etc. into 4 big queries.
It also removes duplicate function calls from acqui-home.pl
Test plan:
0) Visit Acquisition home
0) Apply patch
1) Refresh page. It shoud look identical.
2) prove t/db_dependent/budgets.t
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Imo these somewhat weird lines ask for improvement, but I don't want to change
the exact conditions here. Just removing the need to call find twice.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When an item has an itemtype not in the itemtype table. Trying to fetch
it's description lead to an error.
Using authorized values like ccode to populate the itemtypes of the
biblioitems (instead of the itemtype table) can lead to such data.
Or importing records with invalid itemtype codes. Koha doesn't do enough
checks at import to at least warn about these issues.
== Test plan ==
1. first we need an item with an itype not in the item_types table
1. download a record as MARCXML
2. find it's item type in administration; and the related code
3. open the MARCXML file and search for occurences of the code
and replace them by some non-existing value like "FOOBAR"
4. also change the barcode so it won't be ignored because
it's a duplicate
5. also change the title to easily find it later in the search
6. tools → "Stage MARC records for import"
7. upload your file
8. "stage for import"
9. click "Manage staged records"
You should end on the page related to your staged record
10. "Import this batch into the catalog"
2. now we need it in a basket group
1. have/create a active budget
2. have/create a fund
3. have/create a vendor with minimal info
4. create a basket with minimal info
5. add our imported item to the basket
for example search it by name
6. go to the basket. URL should be
/cgi-bin/koha/acqui/basket.pl?basketno=XXXXX
7. close this basket
and tick "Attach this basket to a new basket group with the same name"
8. you will end up in the basket groups lists
9. go to the "closed" tab
11. go to the basket group
your vendor page => Basket groups => Closed
3. export as PDF, it should fail (internal server error)
this is the bug (no kidding ^_^)
4. apply this patch
5. reexport the basket as PDF
6. it should work
7. create an item type (in administration)
that has the same code as the one that you put in the MARCXML
8. reexport the basket as PDF
9. check that in the PDF that the description is here:
table at the bottom of the document → "Document" column
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On the page acqui/basketgroup.pl the prices of baskets should be shown
formatted according to the selected CurrencyFormat syspref, with no
currency symbol or code.
Test plan:
1) Create a basket with items in it worth more than 1000 currency units.
2) Close the basket.
3) Go to acqui/basketgroup.pl page and check that the price format matches
the current CurrencyFormat syspref.
4) Go to Administration and change CurrencyFormat syspref to one of the
other available options and recheck step 3.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Fixed some tabs.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The aqorders.subscriptionid info is not sent to the template when the
order is edited. Which means we lose this link.
Test plan:
Create an order from a subscription
Edit the order
=> Without this patch, the aqorders.subscriptionid value is set to NULL
and items are created when receiving serial.
=> With this patch applied the link is preserved and expected behaviors
are preserved during all the acquisition workflow
You should also try and create several orders from the same subscription
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The ACQ MARC framework is only used for the ‘Item’ block.
This patch add the ability to define biblio fields (!= 995 or 952) to
customize the display of the bibliographic details when ordering.
This new feature is controlled by a new pref:
UseACQFrameworkForBiblioRecords
Test plan:
- Create a new installation to populate the ACQ framework correctly
- Set the pref UseACQFrameworkForBiblioRecords to "Use"
- Create a new order
=> You will see the lib from the ACQ framework
- Add/remove/update biblio subfields in the ACQ framework
- Create a new order
=> You should see the new subfields displayed
Note for QA: I though I would be able to refactor existing code to make
it more flexible, but it is a bit messy and lost a lot of time. I
finally decided to copy/paste the existing code. I simplified it as, I
think, we do not want the plugin, etc. like in the full biblio editor.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In acqui/parcel.pl both the "Pending orders" and "Already received" tables show how many holds there are for the given record. However, the count of holds in the "Pending orders" table confuses librarians because it only lists holds for the particular items in the orderline. Due to that, the holds column may show 0 holds even if there are a dozen record level holds for that bib! This is not what librarians seem to expect, instead it seems that the same total holds in the "Pending orders" table would be preferred.
Test Plan:
1) Find an invoice with an item in the "Already received" table
2) Add one or more record level holds to the record
3) Note the holds column does not count those holds
4) Apply this patch
5) Note the holds column now shows total holds and holds for just those ordered items
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nancy Keener <nkeener@washoecounty.us>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 19812: (QA follow-up) Swap sides for total and item holds
Bug 19812: (QA follow-up) If 0 holds show '0' not '0 / 0'
Bug 19812: (QA follow-up) Remove unnecessary line
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Should be sufficient to read code and see all lines were commented and
that this patch removes useless lines
To be thorough, ensure that your can add an order to a basket and add a
biblio.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Add an order from external source
2 - Note you don't have keyword or standard ID fields
3 - Add a catalog record from Z3950, note those fields are there
4 - Apply patch
5 - Check acq and note you do have those fields
6 - Do some searches to verify they work as expected
Signed-off-by: Maksim Sen <maksim.sen@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In order to simplify and make uniform the code, the controller scripts send
a Koha::Patron object to the templates instead of all attributes of a patron.
That will make the code much more easier to maintain and will be less
error-prone.
The variable "patron" sent to the templates is supposed to represent the
patron the librarian is editing the detail.
In the members module and some scripts of the circulation module, the
patron's detail are sent one by one to the template. That leads to
frustration from developpers (making sure everything is passed from all
scripts) and to regression (we got tone of bugs in the last year because
of this way to do).
With this patch set it will be easy access patron's detail, passing only
1 variable from the controllers.
Test plan:
Play with the patron and circulation module and make sur the detail of
the patron you are editing/seeing info are correctly displayed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Case:
Check the following files have been updated from
use strict;
use warnings;
to
use Modern::Perl;
acqui-home.pl
addorder.pl
basketgroup.pl
basketheader.pl
booksellers.pl
check_budget_total.pl
check_duplicate_barcode_ajax.pl
edi_ean.pl
edifactmsgs.pl
edimsg.pl
finishreceive.pl
histsearch.pl
invoice.pl
invoices.pl
neworderbiblio.pl
neworderempty.pl
newordersuggestion.pl
ordered.pl
orderreceive.pl
parcel.pl
parcels.pl
pdfformat/layout2pages.pm
pdfformat/layout2pagesde.pm
pdfformat/layout3pages.pm
pdfformat/layout3pagesfr.pm
spent.pl
supplier.pl
uncertainprice.pl
updatesupplier.pl
z3950_search.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Corrected a single semicolon in edimsg.pl during signoff.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan
[1.] Check the patch to see that I have removed:
$template->param( uncertainprices => 1 ); from line 204 as Mr Druart has instructed to do
(to get to the patch see the comment above by Mr Druart)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
MarcItemFieldsToOrder defines how Koha looks at tags in order records to generate item data.
Let's look at a simplified case:
homebranch: 955$a
holdingbranch: 956$a
So, here we are looking at 955 for the home branch, and 956 for the holding branch. So, it should make sense that Koha requires that these fields exist in equal number in the record. That is, for each 955, there should be a corresponding 956.
Let's look at a different case:
homebranch: 946$a|975$a
holdingbranch: 946$a|975$a
In this case, we are using the fallback behavior. VendorA stores the branch data in 946, and VendorB stores it in 975. This seems like it would work, but it won't! That's because Koha is expecting there to be the same number of 946's as there are 975's! In reality, the VendorA records will have a number of 946's, and *zero* 975's. The inverse will be true for VendorB.
Koha should be able to skip those tags that simply don't exist in the record.
Test Plan:
1) Set MarcItemFieldsToOrder to something like:
homebranch: 946$a|975$a
holdingbranch: 946$a|975$a
budget_code: 946$f|975$f
itype: 946$y|975$y
notforloan: 946$l|975$l
ccode: 946$t|975$c
quantity: 946$q|975$q
price: 946$p|975$p
itemcallnumber: 946$n|975$n
loc: 946$c|975$t
2) Create a record using only the 975 tag for item building data
3) Import the record into Koha
4) Create a basket
5) Attempt to add the record to the basket
6) Note the unequal fields error
7) Apply this patch
8) Reload the page
9) No error!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marci Chen <mchen@mckinneytexas.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: Fix typo occurrance and theses.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If no profile_id is passed, GetBasketAsCSV will fallback to default itself.
No need to make the distinction in basket.pl.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Go to Tools -> CSV profiles -> New CSV Profile
2) Create a new CSV profile with any name of SQL fields. Ensure profile
type: SQL and usage: basket export in acquisition
3) Go to Acquisitions -> Find or create a vendor -> Use or create a
basket
4) Click the dropdown menu next to the 'Export as CSV' button. There
should be a 'Default' option and your new CSV profile (at least)
5) Click the 'Default' option. Notice warns
6) Click the 'Export as CSV' button. Notice warns
7) Click your new CSV profile option. Notice warns
8) Apply patch and refresh page
9) Repeat steps 5-7, confirm that warns do not show
10) Confirm export still works as expected
Sponsored-by: Catalyst IT
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If no string is passed to output_pref, it needs to be called in scalar
context (to avoid a shift in the hash elements).
Here we have billingdate that is not defined yet (NULL)
Test plan:
- Search for an existing invoice
- Show details
- Changing shipping cost
- Save
- Verify the new amount is shown
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset adds the 'subtitle' field to the results display on
acquistions search for adding an order form an existing item.
Any field mapped to 'subtitle' in 'Keyword to MARC mapping' will be
fetched and displayed in the results
To test:
1 - Perform an acquisitions search for existing record
2 - Note record subtitles are not displayed
3 - Map 245$b and 245$n to 'subtitle' in 'Keyword to MARC mapping'
4 - Note they are still not displayed ion acq results
5 - Apply patch
6 - subtitle fields should now display
Sponsored by: Round Rock Public Library
<https://www.roundrocktexas.gov/departments/library/>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Patch applies and works as expected.
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Create an order file that includes prices and items
(MarcFieldsToOrder)
2 - Stage the file
3 - Set vendor to 'prices exclude tax'
4 - Open a basket and add from the file
5 - View the items in the basket
6 - Prices are reduced by the tax rate and tax is calculated to return
prices to the value in the file
7 - Apply patch
8 - Repeat steps 1-6
9 - Prices should now calculate correctly
10 - Repeat with 'MarcItemFieldsToOrder'
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>
QA tools reported for acqui/addorderiso2709.pl
FAIL valid: push on reference is experimental
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If you import an order file ( using MarcItemFieldsToOrder ) that has a different budget for each item to be ordered, you will get an error and a partially created basket. This is because Koha attempts to add the item to each order *for each budget*. This is clearly incorrect. Instead, we should be grouping items by budget and for each budget only adding those items that have a matching budget.
Test plan:
1) Do not apply this patch
2) Download the provided MARC record
3) Add the branchcode 'ALD' to your server
4) Add the ccode 'ACOL' to your server
5) Add the budget codes 'adultay' and 'branchay' to your server
6) Stage the order file
7) Create a basket, import the order file
8) No we have 3 records, 2 of them have 2 items each with different budget codes
9) Attempt to import, note the error
10) Apply this patch
11) Repeat steps 6-8, note the order completes and results in 5 order lines being added to the basket!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Christopher Kellermeyer <ckellermeyer@altadenalibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
First step of test plan amended (not apply instead of apply).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
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>
This adds a new basket attribute (create_items) that can optionally be
set to override AcqCreateItem.
The following have been modified to reflect this (with the value of
create_items that causes them to behave differently in parentheses):
* Cancelling receipt of an order (receiving)
* Creating an order by hand or from MARC (ordering)
* Receiving an order (receiving)
* Showing orders with uncertain price (ordering)
* Showing orders (receiving)
* Showing acquisition details in the OPAC (ordering)
Test plan:
1) Create baskets with "Create items when:" set to ordering,
receiving, cataloging and unset.
2) Test each of the above for each of these baskets, verifying that
the basket-specific attribute overrides AcqCreateItem if set and
falls back to the syspref otherwise.
NOTE: A check of AcqCreateItem in opac-detail.tt was removed because it
was redundant; the code path in question cannot be triggered unless
create_items/AcqCreateItems is set to the correct value anyway.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Barbara Fondren <bfondren@roundrocktexas.gov>
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>
Details of the basket an order is tranferred to or from
are displayed in the basket display.
Unfortunately these details were not being read so
the display incorrectly showed the details
of the current owning basket.
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan remains the same.
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Go to Acquisitions -> Find a vendor -> View a basket with orders in
it (or make a new basket and add an order)
2) Click Cancel order
3) Notice incomplete breadcrumbs, and 'Acquisition' typo
4) Apply patch and refresh page
5) Breadcrumbs should be fixed. Confirm links to vendor and basket work
as expected
Sponsored-by: Catalyst IT
Signed-off-by: severine.queune <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 15801 removes the 2 lines that were necessary to retrieve the
framework selected by the user and pass it to the template.
All bibliographic records created when adding an order to the basket
using an external source used the default framework.
Test plan:
Add an order to a basket from an external source
Select another framework than the default one
=> Without this patch, whatever the framework you picked, the default
one is used
=> With this patch applied the framework code you will pick will be used
Signed-off-by: Marijana Glavica <mglavica@ffzg.hr>
Signed-off-by: Marijana Glavica <mglavica@ffzg.hr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Open the koha intranet error log
2) Go to Acquisitions -> Find or create a vendor
3) Create a new basket, filling all fields
4) Notice warns in error log
5) Edit this basket
6) Notice warns in error log
7) Apply patch
8) Create another basket, confirm warns do not show
9) Edit this basket, confirm warns do not show
Sponsored-by: Catalyst IT
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This bug was introduced in commit 2bf3ce268d
Bug 17196: [QA Follow-up] Additional fix on acqui/basketgroup
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
... when referring to the name of the vendor.
To test:
1) Confirm vendor shows on webpage title (tab name)
2) Confirm vendor shows in breadcrumbs
3) Confirm vendor shows in heading when viewing basket ('Basket x (1) for
vendor')
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Go to Acquisitions
2) Find a vendor and a basket
3) Click 'Close basket' button
4) Notice that on confirmation page, breadcrumbs are missing vendor
5) Apply patch and refresh page
6) Vendor name should now show
7) Confirm link to vendor works as expected
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
At the moment we have 2 different modules for acquisition orders:
Koha::Tmp::Order[s] and Koha::Acquisition::Order
The later has been added before the creation of Koha::Object.
Koha::Tmp::Order[s] has been created to make the TT syntax for notices
works with acquisition order data.
This patch removes the temporary packages Koha::Tmp::Order[s] and adapt
the code of Koha::Acquisition::Order[s] to be based on Koha::Object[s].
It also overloads Koha::Object->new to add the trick that was done in
Koha::Acquisition::Order->insert. This is needed because acqui/addorder.pl
is called from several places and CGI->Vars is used to retrieved order's
attributes (and so much more). To avoid regression, the easiest (but not
cleanest) way to do is to filter on aqorders column's names.
This is *not* a pattern to follow!
Test plan:
Create basket and add orders from different ways, then continue a whole
acquisition process
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Go to Acquisitions, find a vendor and a basket (create if you don't
have either)
2) Close the basket
3) View the basket and reopen it
4) Notice the warn
5) Apply the patch and repeat steps 1-3
6) Notice the warn no longer shows and the basket is reopened as
expected
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Find a record with an item that has no itemtype (or remove the
itemtype of an item)
2) Go to Acquisitions -> Find a vendor or make a new one -> create a new
basket
3) Add the record from Step 1 to your basket
4) Close the basket
5) Go back to the vendor and click 'Receive shipments'
6) Put in an invoice number, click Next
7) Click the Receive link for your item
8) Confirm you see an internal server error
9) Apply the patch and refresh the page
10) The error should be gone and behaviour should continue as expected
Sponsored-by: Catalyst IT
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch is a followup to making
Koha::Acquisition::Booksellers->search work as any other Koha::Objects
(DBIC) query instead of having a different behaviour hardcoded.
To achieve it, this patch makes the controller scripts add
wildcard/truncation chars as prefix and sufix for searches, and make the
default sorting for results be by 'name', ascending.
To test:
- Just verify the behaviour remains unchanged by this patchset on the
controller scripts (re. searching).
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As reported by Nick, a typo from bug 17843.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Most of the time C4::Biblio::GetBiblioData is used to retrieve the title
and/or the author of a bibliographic record.
This patch replaces the easy occurrences of GetBiblioData, the ones
where the 2 joins are needed, but only data from biblio and biblioitems
table are.
Test plan:
It will be hard to test everything, I'd suggest a QAer to review this
patch and confirm that the difference occurrences of GetBiblioData have
been correctly replaced by calling Koha::Biblios->find or
$biblio->bibioitem
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The variable name has_subscriptions implies that it is a boolean. In reality
we save the number of subscriptions into it. Renaming has_ to cnt_.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
C4::Biblio::GetSubscriptionsId can be replaced using
Koha::Biblio->subscriptions
Test plan:
Create a new order for a bibliographic record
Create a new subscription on this biblio
From the basket (acquisition), confirm that you are not able to delete
the order with the biblio ("Can't cancel order and delete catalog record
1 subscription(s) left")
Receive the order
On the parcel page, confirm that you are not able to delete the order
with the biblio
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The C4::Koha::getitemtypeinfo subroutine did the almost same job as
GetItemTypes. On top of that it returned the imageurl value processed by
C4::Koha::getitemtypeimagelocation.
This value is only used from the 2 [opac-]shelves.pl scripts. Then it's
better not retrieve it only when we need it.
Test plan:
Play with the different scripts touched by this patch and focus on item
types. The same description as prior to this patch must be displayed.
Note that sometimes it is not the translated description which is
displayed, but that should be fixed on another bug report. Indeed we do
not expect this patch to change any behaviors.
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This script floods the logs with this kind of warnings.
To test:
- Run:
$ koha-plack-err
- Edit a vendor in the acquisitions module
- Save
=> FAIL: Logs show lots of warnings that look like:
CGI::param called in list context from package CGI::Compile::ROOT::home_vagrant_kohaclone_acqui_updatesupplier_2epl
- Apply this patch
- Run:
$ restart_all
$ koha-plack-err
- Edit a vendor, add/delete vendor contacts
=> SUCESS: No more warnings
- Verify editing and storing vendor contacts works as expected.
- Sign off :-D
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch allows the user to use a CSV export profile to create the fields to export the basket as CSV in a basket page.
Test plan:
1) Apply the patch
2) Go to Tools › CSV export profiles and create a profile of type "SQL for basket export in acquisition"
example:
biblionumber=biblio.biblionumber|auteur=biblio.author|titre=biblio.title|date=biblioitems.copyrightdate|editeur=biblioitems.publishercode|isbn=biblioitems.isbn|quantite=aqorders.quantity|prix=aqorders.rrp|panier=aqorders.basketno
3) In acquisition module, create a new basket and add an order to the basket
4) On basket detail page, there should be the split button labelled "Export to CSV"
5) Try to use the button and export CSV with your CSV profile you defined in step 2
6) Validate the CSV file.
7) Repeat 4-6 with a closed basket.
a) close the basket
b) View the basket
c) validate that there is an export button
d) test it with an export
8) prove t/db_dependent/Acquisition/GetBasketAsCSV.t t/db_dependent/Koha/CsvProfiles.t
Initial work:
Sponsored by: CCSR
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: mehdi <mehdi.hamidi@inlibro.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In acquisition, several templates try to display publisher code and publication year : invoice.tt, parcel.tt, transferorder.tt.
Thoses pages use C4::Acquisition methods GetPendingOrders or GetInvoiceDetails.
The bug is that in the SQL query of those methods, biblioitems.publishercode and biblioitems.publicationyear.
In uncertainprice.pl those datas are fetch using GetBiblioData.
It whould be better to fetch them in GetPendingOrders and GetInvoiceDetails.
This patch changes SQL queries to fetch wanted datas : aqorders.*,biblio.title,biblio.author,biblioitems.isbn,biblioitems.publishercode,biblioitems.publicationyear. GetInvoiceDetails also needs : biblio.seriestitle,biblioitems.volume.
This patch also unifies the way biblio datas are displayed :
<a href="link to catalog using biblionumber">[title]</a> <em>by</em> [author] – [isbn]
<em>Publisher:</em> [publishercode], [publicationyear]
Test plan :
- Choose a biblio record containing a data in :
biblio.title,
biblio.author,
biblioitems.isbn,
biblioitems.publishercode,
biblioitems.publicationyear,
biblio.seriestitle,
biblioitems.volume.
- Create an order using this biblio.
- Look at this order in pages : parcel.pl, transferorder.pl, uncertainprice.pl
=> You see publisher code and publication year
- Look at this order in page : invoice.pl
=> You see publisher code, publication year, series title and volume
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Load http://localhost:8081/cgi-bin/koha/acqui/booksellers.pl?booksellerid=1
2 - Should get internal server erro
3 - Apply patch
4 - Reload
5 - Should not get error
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If using MarcItemFieldsToOrder with AcqCreateItem = Create,
the order and the items will be created, but they will not be linked via aqorders_items!
Test Plan:
1) Enable creation of items when ordering
2) Set up MarcItemFieldsToOrder
3) Upload an order record that uses the fields in step 2
4) Create a basket and add the records from the file
5) Note the order and items are created, but no rows in aqorders_items are created
6) Apply this patch
7) Repeat steps 3-4
8) Note the rows in aqorders_items are created!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marci Chen <mchen@mckinneytexas.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When adding a batch from a stage file with defaut matching on
title/author, if a duplicate is detected, all following records
treated in the batch are discarded from import even if they are not duplicates
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If the bibliographic record of an order has been removed, $order->{bibionumber}
is undefined. We need to handle this specific case correctly.
To test:
1 - Create a basket
2 - Order a bib
3 - Cancel order and delete record
4 - You cannot view basket
5 - Apply patch
6 - View basket
7 - There should not be an error
r calling count on undefined bib in basket.pl if order cancelled and
record deleted
Followed test plan, works as intended
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Receiving orders process the comma as a decimal point
Invoices are displaying incorrectly when formatting total
Test Plan:
1. Open a basket
2. Place an order for an item with price > 1000, $4367.00 for example
3. Close basket
4. Receive order
5. Note on orderreceive.pl the price is populate as "4,367.00"
6. Receive/Save
7. Note the 'Actual Cost' is now $4.00, verify db contains 4 as well
8. Cancel receipt
9. Receive again, this time enter price as "4367"
10. Receive/save
11. Note actual cost is correct
12. Finish receiving
13. Note invoice reads total as $4.00
14. Check db. price in aqorders is correct but displaying incorrectly
15. Apply this patch
16. Repeat step2 1. 14, note errors are fixed
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Setup a vendor with a discount
2 - Stage a file
3 - Create a basket
4 - Order from staged file
5 - Add a price but no discount
6 - Save order
7 - Note ecost is not discounted
8 - Apply patch
9 - Repeate 2-6
10 - Note ecost is discounted
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Updating to use they/them and skipping the ones changed to it
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comments throughout the Koha codebase assume that
all librarians or borrowers are male by using the
pronoun 'he' universally. This patch changes to
'he or she' / 'him or hers'.
Testing plan:
- ensuring modifying tests still pass:
+ C4/SIP/t/06patron_enable.t
+ t/db_dependent/Circulation.t
+ t/db_dependent/Koha/Patrons.t
+ t/db_dependent/Reserves.t
Sponsored-By: California College of the Arts
No code changes detected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
0 - Ensure AcqCreateItem is set to 'placing an order'
1 - Order some items, note entrydate and datelastseen match
2 - Alter those dates to be earlier than today (or wait some days)
3 - Recieve the item and note datelast seen not updated
4 - Apply patch
5 - Repeat 1-3
6 - Date last seen should be updated.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Works as expected.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The combobox on the left side of late orders is filled by sub
GetBooksellersWithLateOrders. The same change as in the first patch
must be made here to include suppliers with late orders without a
price.
Bonus: Sort the list.
Test plan:
[1] Run t/db_dependent/Bookseller.t.
[2] Go to late orders. Use the filter on suppliers.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Several warnings like:
Variable "$confirm_pref" is not available at /usr/share/koha/masterclone/acqui/basket.pl line 507.
Primarily caused by sub edi_close_and_order.
Easy fix.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The solution of Jonathan can be applied in two other cases, effectively
making GetItemHolds obsolete.
Test plan:
[1] Git grep on GetItemHolds
[2] Add an order, place a hold, delete order.
[3] Add an order, receive, place hold, delete order.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Crash in basket.pl:
Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/basket.pl line 466.
Comes from a biblionumber == NULL in aqorders where I cancelled the order and deleted the biblio.
Crash in parcel.pl:
Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/parcel.pl line 246.
Similar fix.
Trivial fixes indeed.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Trivial fix.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
It is not about when the hold was 'placed' but if the hold pertains to
the future or not.
Test plan:
[1] Git grep on holds_placed_before_today.
[2] Run t/db_dependent/Koha/Biblios.t
[3] Run t/db_dependent/Reserves.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Reserve::GetReservesFromBiblionumber took 3 parameters, the
biblionumber, an optional itemnumber and a "all_dates" flag.
If set, the subroutine returned all the holds placed on a given bibliographic
record, even the ones placed in the future. Almost all of the calls had this
flag set, they will be replaced with a call to Koha::Biblio->holds.
But 5 did not have it:
- C4::Biblio::DelBiblio
-tools/batch_delete_records.pl
=> These 2 were wrong, we want to retrieve the holds to cancel them
before deleting the record. We need to get all the holds, even the ones
placed in the future /!\ CHANGE IN THE BEHAVIOR
- acqui/parcel.pl
=> 1 call per item were made to this subroutine. They have been replaced
with only 1 call to the new method Koha::Biblios->holds_placed_before_today
Then we filter on the itemnumbers.
I think this is wrong: we need the number of holds to know if the record
can be deleted, so even if future holds exist, the deletion should not
be possible.
- serials/routing-preview.pl
- C4::ILSDI::Services::GetRecords
- C4::SIP::ILS::Item->new
=> Seems ok, we just one to display holds placed before today
Test plan:
I would suggest to test this patch with patches from bug 17737 and bug 17738,
to place different kind of holds (biblio and item level, future and
past).
Then do a whole workflow to detect bug, view a record, delete record,
order, place a hold on an item which has been ordered, etc.
The hold's informations should always be the same without or without
these patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Koha::GetAuthvalueDropbox subroutine does the same job as
Koha::AuthorisedValues->search
We should then replace the different calls to this subroutine to finally
remove it.
There were 2 calls to this subroutine:
- from the AuthorisedValues TT plugin (called from av-build-dropbox.inc
and members/housebound.tt)
- from the acqui/ajax-getauthvaluedropbox.pl ajax script
To make sure that this patchset does not introduce regressions, we will have
to test that the TT plugin and the ajax script still behave as before.
Test plan:
1/ Test acqui/ajax-getauthvaluedropbox.pl
- Link a fund to an authorised value category
- Create a new order
=> When you select a fund linked to AV category, the sort1 (and/or
sort2, depending on what you set) should be replaced with a dropdown
list populated with the authorised values
2/ Test av-build-dropbox.inc
- Create some authorised values for Bsort1
- Edit a patron
=> The sort1 should be a dropdown list populated with the Bsort1 AV
3/ Test members/housebound.tt
- Enable the housebound module (pref HouseboundModule)
- On the patron detail page, click on the "Housebound" tab
=> The frequency dropdown list should be populated with the different
HSBND_FREQ AV
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Items::GetItemsCount can be replaced with Koha::Biblio->items->count
Test plan:
Create a bibliographic record with items attached
Try to delete the record from a basket (acquisition module), the detail
page and the batch item deletion tool.
=> You should not be able to delete it.
Remove the items and then try again to delete the record
=> Now you must be able to delete it.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Fix use of 'gstrate' for 'tax_rate'
Signed-off-by: Matthias Meusburger <matthias.meusburger@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch redirects to the vendor's list of baskets after deleting a
basket, fixes breadcrumbs after deletion and also hides the toolbar
actions after deletion (seeing as you can't edit/export etc a basket
that no longer exists).
To test:
1) Go to Acquisitions -> find a vendor -> view a basket or create a new
basket
2) Delete the basket. Notice you are taken to a list of all vendors and
baskets
3) Apply patch and do step 1 again
4) Delete the basket. Notice appropriate breadcrumbs, no toolbar, and
confirm link to return to baskets for the vendor works.
Sponsored-by: Catalyst IT
Followed test plan, works as expected (links to vendor's baskets and all baskets)
Signed-off-by: Marc Véron <veron@veron.ch>
Re-tested. Wording of buttons "Show baskets for vendor..." and "Show all
active baskets" makes sense.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The goal of this development is to automatically generate items in Koha with
populated information based on a 9XX field and subfield, with the new syspref
MarcItemFieldsToOrder.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Benjamin Daeuber <bdaeuber@cityoffargo.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This typo was introduced in Bug 13726 and has obvious fix
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
==TEST PLAN==
1) Open Acquisitions and click on the ordered link under the fund
2) There will be no link on the title
3) Go back and click on thespent link
4) There will be no link on the title
5) Apply patch
6) Go to Acquisitions and click on ordered
7) There will now be a link that takes the user to the book catelog
page
8) Go back and click on sent
9) There will be a link that takes the user to the book catelog
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works like a charm!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
order
TEST PLAN
1. Go to the acquisition module and create budget with fund of 0.00 and
another fund of 1.00.
2. On acquisitions use a vendor to create a new basket and add an order
to that basket.
3.Find a record and order it.
4. Under accounting details the fund with 0 in it won't be visable.
5. Apply patch and refresh, then it should be.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
acqui/basketgroup calls GetOrders and expects marcxml in the results.
Fixing it by an additional call of GetXmlBiblio.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch create a Koha::Acquisition::Booksellers module and
Koha::Acquisition::Bookseller::Contract[s] modules.
All code in the acquisition module is adapted to use the CRUD methods of
Koha::Object[s].
The former C4 routines are removed.
Test plan:
Since a lot of files are impacted by this patch, try a complete
acquisition workflow and try to catch errors.
Be focused on bookseller and bookseller' contacts data.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Biblio::GetHolds can be replaced with Koha::Biblio->holds->count
Test plan:
Create an order and place a hold on the biblio you have ordered.
On the basket view, you should not be able to Cancel the order and/or
delete the record
Receive the order, on the parcel page you should get the same behavior.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Yes, we are fixing these four typos here.
Test plan:
[1] Read the changes.
[2] Run t/Auth_with_shibboleth.t
[3] Run git grep recieved| grep -v -e 'recievedlist' | grep -v -e 'serials-recieve.tt'
Note: serials-recieve.tt is just history. Bonus points for the one who makes
us get rid of that column recievedlist.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
EDIT:
Rebased. Change in Accounts has been corrected already.
Removed the po file.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This typo has been introduced by
commit eed14b080d
Bug 13001: Refactor VAT and price calculation - parcel page
So before the tax rewrite (13321, 13323).
It sounded weird to me that testers did not catch the bug on this page.
To understand the logic:
Conditions are listincgst, invoiceincgst
Conditions | Before this patch | If we fix the typo | After this patch
0 0 | excluded | excluded | excluded
0 1 | included | included | included
1 0 | excluded | excluded | excluded
1 1 | included | included | included
Test plan:
Create 4 vendors with the difference combinations
Create a basket, add an order (with a tax) and receive it
Confirm that the different values displayed on the parcel page are correct
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.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: Kyle M Hall <kyle@bywatersolutions.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: Kyle M Hall <kyle@bywatersolutions.com>
When you order from a staged file you're getting duplicate warnings that
are inaccurate. For example, when you order a file of 50 DVDs for
example and they don't have ISBNs they're matching on the books. And
then you have to order them one by one.
This patch replaces the use of FindDuplicates with Koha's match point
system. This means you can select from the same match points defined
and used in the batch record importer, or you can opt to skip matching
altogether!
Test Plan:
1) Import a record with a title, isbn and author.
2) Delete the from the record and stage it again
3) Attempt to add it to a basket via the staged record
4) You should note the gives you the "No records imported" message
5) Apply this patch
6) Create a matcher for ISBN
7) Create a matcher for Author/Title
8) Attempt to add the record to your basket using the ISBN matcher
8) Koha should find no match and import the record to the basket
9) Stage the record again
10) Attempt to add the record to your basket using the Title/Author matcher
11) You should recieve the "No records imported" message.
Signed-off-by: Barbara Fondren <bfondren@roundrocktexas.gov>
Signed-off-by: Nicole C Engard <nengard@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When placing a new order, the budget dropdown will display the budget hierarchy.
TEST PLAN :
1. Go to the Administration module
2. Add a new budget (ie : Budget 2016)
3. Add a fund to this budget (ie : Book)
4. Add a child fund (ie : Adult fiction)
You will have this hierarchy :
Budget 2016
|____ Book
|_____ Adult fiction
5. Go to the Acquisition module
6. Select a vendor and create a new basket
7. Place an order
8. Check the budget dropdown menu
BEFORE PATCH
Book
Adult fiction
AFTER PATCH
Book
Adult fiction
Dropbown menu is hierarchical as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This commit permits to update the tax rate on receiving.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com>
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Well, we have finally arrived here \o/
The method where the prices are calculated uses the equations listed on
the wiki page (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC).
The ecost is calculated from the rrp (using the discount and the tax
rate). That's why we removed the ability to edit this value.
That's why we remove the ability to edit the ecost on ordering in a
previous commit (bug 12840).
The total is now calculated in the scripts. That's why this patch
removes lines in the test file.
In C4::Acquisition::populate_order_with_prices, the calculation on
receiving must depend on the 'invoiceincgst' supplier parameter, and not
listincgst (which is used on ordering).
It also removes the rounding errors, now we store "exact" values in DB
(10^-6).
The values will be displayed using the Price TT plugin it will round the
values for us.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com>
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Now we need to calculate the prices (ecost, rrp, unitprice) and tax
(tax_rate, tax_value) when the price is set for an order.
This only appends in the 3 files impacted by this patch.
addorder*.pl on ordering
finishreceive.pl on receiving
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com>
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch renames the variable according to the new DB column names
* gste => tax_excluded
* gsti => tax_included
* gstrate => tax_rate
* gstvalue => tax_value
This patch also modify the ModReceiveOrder subroutine:
* Edit vendor note on receiving is not possible, so the code should not
permit that.
* Update ModReceiveOrder to pass a hashref
And that's all!
git grep on gste, gsti, gstrate and gstvalue should not return any code
that can be executed.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com>
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Koha::getframeworks returned a hashref of biblio frameworks.
It was mainly used to generate the dropdown list of frameworks.
The scripts modified in this patch did not necessary order the element
by description (frameworktext), the displays were not consistent from
one screen to another.
Using the same search method everywhere:
Koha::BiblioFrameworks->search({}, { order_by => ['frameworktext'] });
We will know always get the framework in the same order.
Test plan:
Following the different pages modified by this patch, and make sure the
frameworks are displayed correctly in the dropdown list:
1/ acqui/z3950_search.pl - Create an order from an external source.
2/ admin/fieldmapping.pl - Define some mappings keyword / MARC field
3/ admin/marctagstructure.pl - On the MARC frameworks admin page, select
another framework than the default one and click on the 'Search' button
4/ catalogue/MARCdetail.pl - On the MARC defail page, change the
framework you want to use to display the record
5/ cataloguing/addbiblio.pl - Add or edit a biblio record, change its
framework. When editing, the framework of the record should be selected
by default
6/ cataloguing/addbooks.pl - Go on the cataloguing home page and click
on the "New record" button. You should see all the frameworks
7/ cataloguing/merge.pl - Select 2 biblio records to merge. On the first
step (select the merge reference), you should be allowed to select the
framework to use.
8/ tools/inventory.pl - On the inventory page, the "Item statuses" part
should be populated as before this patch
9/ tools/manage-marc-import.pl - Stage records for import. Before
importing them into the catalog, you should see the framework dropdown
list.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works Ok.
No errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
No need to redirect, just sent the params to the template directly
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When no notice template ACQORDER was defined, you'r receive a false
positive "email sent" message. Now it will display a specific
error message instead.
Also includes 2 unit tests to test for the warn and new error code.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
With this patch it will be possible to send order information
to the vendor by e-mail. For now this feature can be triggered
manually with a button before closing the basket.
The order e-mail is based on the acquisition claim feature, but
uses a new notice template.
Test plan:
1) Vendors
A new checkbox "Contact when ordering?" was added to the vendor
page.
- Add a vendor and/or edit an existing vendor
- Verify the new option is saved correctly
- Verify the new option displays on the vendor summary page
after saving
2) Notices
The feature works with a new notice template: ACQORDER
It works with the same formatting/fields etc. as the acq claim
notice.
- Add a new notice template ACQORDER in module
'Claim/order aquisition'
- Make sure to use fields from the various offered tables
in your notice
- Verify it is saved correctly
3) Basket
- Turn on LetterLog system preference
- Create multiple order lines
- Click the 'Send order' button in the toolbar
- Verify error or success message
- Verify you received the e-mail
- Verify there is a new entry with about the sent
notice in your action_logs table
4) Regression testing...
- Verify order claims still work
- Verify serial claims still work
- Verify new serial issue notices still work
...
(I can provide additional test plans if needed)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the call to C4::Koha::GetKohaAuthorisedValues with
Koha::AuthorisedValues->search_by_koha_field
Test plan:
AV descriptions should be displayed on the following pages:
- XSLT view - location and ccode
- Bibliographic detail, moredetail and OPAC pages - location, ccode, copynumber
- returns - location
- opac-basket - ccode, location
- The 3 reports: catalogue_stats.pl, issues_stats.pl and
reserves_stats.pl - location, ccode
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Koha::GetAuthValCode returned the authorised value
category for a given kohafield.
This can be acchieve easily using a new Koha::AuthorisedValues->search_by_koha_field
method which will mimic search_by_marc_field.
Test plan:
Confirm that the description is correctly displayed on the following
pages:
- detail and moredetail of a bibliographic page (itemlost, damaged, materials)
- Set AcqCreateItem=ordering and receiving items.
The description for notforloan, restricted, location, ccode, etc.
field should be displayed.
- Items search form
- On the checkout list from the circulation.pl and returns.pl
pages, the description for "materials" should be displayed
Note that GetKohaAuthorisedValuesMapping is going to be removed on bug
17251.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Note: Same situation as in Bug 17403
To test:
- Verifiy that code change makes sense.
Note: Same situation as in Bug 17403
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended patch: Remove unecessary comment
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Built on top of bug 17441
Test plan:
Just have a look at the changes. Trivial.
Git grep seleted. No results.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The subroutine C4::Koha::GetKohaAuthorisedValueLib just retrieves a description
(lib) for a given authorised value.
We can easily replace it using:
Koha::AuthorisedValues->search({ category => $cat, authorised_value => $av })->lib
or
Koha::AuthorisedValues->search({ category => $cat, authorised_value => $av })->opac_description
Test plan:
- On the detail page of a bibliographic record, the description for notforloan,
restricted and stack (?) should be correctly displayed
- View a shelf, the location (LOC) description should be displayed
- On the search result page, the location description should be displayed in the
facets
- Set AcqCreateItem=ordering and receiving items.
The description for notforloan, restricted, location, ccode, etc. field
should be displayed.
- When creating item in the acquisition module, the dropdown list for
field linked to AV should display the AV' descriptions
- On the transfers page, the description of the location should be
displayed.
- On the checkout list from the circulation.pl and returns.pl pages, the
description for "materials" should be displayed
- Fill some OPAC_SUG AV and create a suggestion, the reason dropdown
list should display the description of OPAC_SUG
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
- Uses a dialog box to warn of unique fields not copying, dialog was in
place for barcode generation so removed the extar modal completey
- Fixes a problem when barcode was undefined and autobarcode on
- deleted an extra space in Barcodes/hbymmincr.pm
Signed-off-by: sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch add an 'Add multiple copies' button on the new order page in
acquisitions. While processing the multiple copies a modal is
displayed.
To test:
1 - Add an order to an acquisitions basket
2 - Choose to add multiple items
3 - A modal shouold warn about ignoring UniqueItemFields from syspref
4 - When submitting the modal should popup until all items are processed.
5 - The modal should disappear after items are added.
6 - Items should be cloned, minus unique fields
7 - Enable autoBarcode for various formats, ensure you are warned that
barcodes will be generated, and ensure they are generated correctly
Sponsored by: Middletown Township Public Library (http://www.mtpl.org)
Signed-off-by: sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When you notice a typo in your invoice number after finishing with the
receiving process, the only way to correct it right now is in the
database - or by undoing all the steps and starting over.
It would be nice if the invoice number could be edited.
Test Plan:
1) Apply this patch
2) Browse to acqui/invoice.pl for an invoice
3) Note the new "Invoice number" field contains the existing invoice
4) Alter the invoice number
5) Save the invoice
6) Note the invoice number has been updated
7) Edit the invoice again
8) Attempt to save the invoice with an empty invoice number field
9) Note that you cannot save the invoice without having an invoice number
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
[1] Candidate 1 is FillWithDefaultValues.
This routine in Acquisition.pm does not autovivify the tagslib
structure but first collects the keys at tag and subfield level.
So, unsafe can be safely added here :)
[2] Candidate 2 is script acqui/neworderempty.pl.
It only (!) uses GetMarcStructure to know if there is a ACQ framework.
There should be cheaper ways to do it, but when we use the fast cache,
it does not matter that much anymore.
[3] Candidate 3 is script acqui/orderreceive.pl. Same reason as [2].
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with neworderempty.pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is the fourth and last patch set to remove C4::Branch.
The real purpose of this patch is to standardise and refactor some code
which is related to the libraries selection/display.
Its unconfessed purpose is to remove the C4::Branch package.
Before this patch set, only 6 subroutines still existed in the C4::Branch
package:
- GetBranchName
- GetBranchesLoop
- mybranch
- onlymine
- GetBranches
- GetBranch
GetBranchName basically returns the branchname for a given branchcode.
The branchname is only used for a display purpose and we don't need to
retrieve it in package or pl scripts (unless for a few exceptions).
We have a `Branches` template plugin with a `GetName` method which does
exactly this job.
To achieve this removal, we will use this template plugin and delete the
GetBranchName from pl and pm files.
The `Branches.all()` will now select the library of the logged in user
if no `selected` parameter has been passed.
This new behavior could cause regressions, for instance there are some
places where we do not want an option preselected (batch item
modification for instance), keep that in mind when testing.
GetBranchesLoop took 3 parameters: $branch and $onlymine.
The first one was used to set a "selected" flag, for a display purpose:
select an option in the libraries dropdown lists.
The second one was useless: If not passed or set to 0, the
`C4::Branch::onlymine` subroutine was called.
This onlymine flag was use to know if the logged in user was able to see
other libraries infos.
A patron can see the infos from other libraries if IndependentBranches
is not set OR if he has the superlibrarian permission.
Prior to this patch set, the "onlymine test" was done on different
places (neworderempty.pl, additem.pl, holidays.pl, etc.), including the
Branches TT plugin. In this patch set, this test is only done on one
place (C4::Context::only_my_library, code moved from
C4::Branch::onlymine).
To accomplish the same job as this subroutine, we just need to call the
`Branches.all()` method from the `Branches` TT plugin. It already
accepts a `selected` parameter to set a flag on the option to select.
To avoid the repetitive
[% IF selected %]<option selected="selected">[% ELSE %]<option>[% END %]
pattern, a new `html_helpers` TT include file has been created, it
defines an `options_for_libraries` block, which takes a `selected`
parameter. We could imagine to use this include file for other
selects.
The 'mybranch` and `onlymine` subroutines of the C4::Branch package have
been moved to C4::Context. onlymine has been renamed with
only_my_library. There are only 4 occurrences of it, against 11 before
this patch set.
There 2 subroutines are Context-centric and it makes sense to put them
in `C4::Context` (at least it's the least worst place!)
GetBranches is the tricky part of this patch set: It retrieves all the
libraries, independently of the value of IndependentBranches.
To keep the same way as the existing calls of `Branches.all()`, I have
added a `unfiltered` parameter. If set, the `Branches.all()` will call
a usual Koha::Libraries->search method, otherwise
Koha::Libraries->search_filtered will be called. This new method will
check if the logged in user is allowed to see other libraries or only
its library.
Note that this `GetBranches` subroutine also created a `category` key:
it allowed to get the list of groups (of libraries) where this library
existed. Thanks to a previous patch set (bug 15295), this value was
not used anymore (I may have missed something!).
Note that the only use of `GetBranch` was buggy (see bug 15746).
Test plan (for the whole patch set):
The best way to test this whole patch set is to test with 2 instances: 1
with the patch set applied, 1 using master, to be sure there is no
regression.
It would be good to test the same with `IndependentBranches` and the
without `IndependentBranches`.
No difference should be found.
The tester must focus on the library dropdowns on as many forms as
possible.
You will notice changes in the order of the options: the libraries will
now be ordered by branchname (instead of branchcode in some places).
A special attention will be given to the following page:
- acqui/neworderempty.pl
- catalogue/search.pl
- members/members-home.pl (header?)
- opac/opac-topissues.pl
- tools/holidays.pl
- admin/branch_transfer_limits.pl
- admin/item_circulation_alerts.pl
- rotating_collections/transferCollection.pl
- suggestion/suggestion.pl
- tools/export.pl
Notes for QA:
- There are 2 FIXMEs in the patch set, I have kept the existing behavior,
but I am not sure it's the good one. Feel free to open a bug report and
I will fill a patch if you think it's not correct. Otherwise, remove the
FIXME lines in a follow-up patch.
- The whole patch set is huge and makes a lot of changes.
But it finally will tremendously reduce the number of lines:
716 insertions for 1910 deletions
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Category module contained only 1 method to return the patron
categories available for the logged in user.
The new method Koha::Patron::Categories->search_limited does exactly the
same thing (see tests) and must be used in place of it.
Test plan:
- Same prerequisite as before
For the following pages, you should not see patron categories limited to
other libraries.
- On the 'Item circulation alerts' admin page
(admin/item_circulation_alerts.pl), modify the settings for check-in
and checkout (NOTE: Should not we display all patron categories on
this page? If yes, it must be done in another bug report to ease
backporting it).
- Search for patrons in the admin (budget) and acquisition (order) module.
- On the patron home page (search form in the header)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Numeric comparison operator is used where string comparison required,
resulting in the following warning in the log: 'Argument "delete" isn't
numeric in numeric eq (==).'
This patch corrects it to use 'eq' not '==' to compare strings.
To test, apply the patch and go to Acquisitions -> EDIFACT messages.
Delete an EDIFACT message. There should be no error in the error log.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If you try to delete an EDIFACT message it triggers an error:
Can't use string ("2") as a subroutine ref while "strict refs" in use at
/acqui/edifactmsgs.pl line 43.
Test Plan:
1) Attempt to delete an EDIFACT message
2) Note the error
3) Apply this patch
4) Attempt to delete an EDIFACT message again
5) Note it succeeds
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* Add `AFTER` to DB update
* Change "Is standing order basket:" to "Orders are standing:"
* Disable item creation when adding from a staged file
* Correctly show is_standing for existing baskets
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This allows creation of special baskets that include standing orders.
These orders do not have a known quantity (and may not have a known
price in advance). Upon receipt, the received items are split into a new
completed order.
Test plan:
1) Run updatedatabase.pl.
2) Run prove t/db_dependent/Acquisition/StandingOrders.t . (and the
other Acquisition tests).
3) Create a new basket, mark it as a standing order basket.
4) Add an order to this basket, and notice that the quantity field is
missing (and thus not required).
5) Receive items for this order, and notice that the original order is
unchanged. The new child order line should have the correct price
and quantity information.
(Note: the QA tools output what seems to be a spurious spelling error
for Test::More's "isnt" in StandingOrders.t.)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This allows sorting to be configured within a field. For example, while
many values are included for search on author, sorting should only be
done on the main entry values. This permits that by have a sort value,
which can be true, false, or null. true and null are pretty much the
same, but false means that a field isn't available for sorting on. By
default (null), fields can be sorted on.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch fixes a regression introduced by bug 15084: The currency
dropdown lists are not correctly built.
The selected currencies are wrong.
Test plan:
Create a vendor, the selected currencies should be the default one
Edit the vendor, the selected currencies should be the ones defined for
this vendor
Create an order, the selected currency should be the 'List prices' of
the vendor
Edit an order, the selected currency should be the one defined for this
order
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
subroutines should not take $dbh in parameter.
C4::Biblio::TransformMarcToKoha has it and does not use it.
Test plan:
Look at the patch and confirm that all occurrences of
TransformMarcToKoha have been modified.
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Add support for processing incoming Edifact Quotes, Invoices
and order responses and generating and transmission of
Edifact Orders.
Basic workflow is that an incoming quote generates an aquisition
basket in Koha, with each line corresponding to an order record
The user can then generate an edifact order from this (or another)
basket, which is transferred to the vendor's site
The supplier generates an invoice on despatch and this will
result in corresponding invoices being generated in Koha
The orderlines on the invoice are receipted automatically.
We also support order response messages. This may include
simple order acknowledgements, supplier reports/amendments
on availability. Cancellation messages cause the koha order
to be cancelled, other messages are recorded against the order
Which messages are to be supported/processed is specifiable on a
vendor by vendor basis via the admin screens
You can also specify auto order i.e. to generate orders from quotes
without user intervention - This reflects existing
workflows where most work is done on the suppliers website
then generating a dummy quote
Received messages are stored in the edifact_messages table
and the original can be viewed via the online
Database changes are in installer/data/mysql/atomicchanges/edifact.sql
Note new perl dependencies:
Net::SFTP:Foreign
Text::Unidecode
Signed-off-by: Paul Johnson <p.johnson@staffs.ac.uk>
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
perl -p -i -e 's/^.*set the version for version checking.*\n//' **/*.pm
+ manual adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Mainly a
perl -p -i -e 's/^.*3.07.00.049.*\n//' **/*.pm
Then some adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
perl -p -i -e 's/^(use vars .*)\$VERSION\s?(.*)/$1$2/' **/*.pm
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
- Reproduce error described in first comment.
- Apply patch
- Try to reproduce error. Page will display as expected.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This subroutine is unused and can be removed.
There is no trace left of currency in C4::Budgets.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Most part of the code here is unnecessary complex. We should selected
the currency if it is selected, that's all :)
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
C4::Branch::GetBranchDetail retrieved library infos, it could be easily
replaced with Koha::Libraries->find
When this change needs other big changes, the unblessed method is
called, to manipulate a hashref (as before) instead of a Koha::Library
object (for instance when $library is sent to GetPreparedLetter).
Test plan:
1/ Print a basket group, the library names should be correctly
displayed.
2/ Enable emailLibrarianWhenHoldIsPlaced and place a hold, a HOLDPLACED
notice will be generated (focus on the library name)
3/ Edit a patron and change his/her library
4/ Generate the advanced notices (misc/cronjobs/advance_notices.pl) and
have a look at the generated notices
5/ Same of overdues notices
6/ Set IndependentBranches and use a non superlibrarian user to place a
hold. The "pickup at" should be correctly filled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch mainly replaces C4::ItemType->all with
Koha::ItemTypes->search.
Test plan:
At the places where the C4::ItemType module was used, confirm there is
no regression:
- acqui/neworderempty.pl
- catalogue/itemsearch.pl
- admin/item_circulation_alerts.pl
and the 2 cataloguing plugins:
- marc21_linking_section.pl
- unimarc_field_4XX.pl
QA step:
prove t/db_dependent/HoldsQueue.t should return green
Note that the tests were buggy.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If no active currency is defined, Acquisitions does not work properly and software
can occur while receiving.
This patch adds the warning message about missing active currency to Home > Acquisitions
To test:
- Apply patch
- Go to Home > Administration > Currencies & Exchange Rates > Currencies
- Make sure that no active currency is set
- Go to Home > Acquisitions
- Verify that a warning displays:
- If user has at least permission for parameters_remaining_perissions,
the warning should display a link to Currencies and exchange rates (currency.pl)
- If the user has no permission to edit the Currencies and exchange rates,
no link is displayed.
- Set an active currency
- Veryfy that the warning no longer displays
(Amended to remove superfluous line / mv)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No errors
Signed-off-by: JM Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
When ordering from a staged file, the list of files
should only include imports of bilbiographic and
no authority data.
To test - start without the patch:
1) Stage an authority file
2) Stage a bilbiographic file
3) Create a new basked in acquisitions
4) Create a new order line selecting "From a staged file"
5) Verify that both files are shown
6) Apply patch
7) Verify that only the bibliographc file shows
in the list now
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 7298 tried to fix this issue, but it was not correct.
We have 3 files in acqui/csv:
basketgroup.tt, basket.tt and lateorders.tt
The first 2 don't contain translatable string, and are not modified on
translating the templates (`translate install`)
On the contrary, lateorders.tt has some strings to translate ('Author:',
'Published by:', etc.). After being translated, all carriage returns
between TT tags are removed.
Test plan:
1/ choose a language and update + translate the templates
for instance:
cd misc/translate;
./translate update es-ES; ./translate install es-ES
2/ Go to acqui/lateorders.pl using this language
3/ Generate a csv for 1+ late orders and confirm the first line only
contains the headers.
Signed-off-by: Laurence Lefaucheur <laurence.lefaucheur@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch replaces all use of C4::Dates with Koha::DateUtils, which is
the best practice to follow.
It also fixes a bug on the invoice search, the shipment date (from and
to) were not passed correctly from one page to the other.
Test plan:
1/ Search for orders using the different filters
2/ Create an invoice, try with setting and leaving empty the date
fields.
Default should be an undefined value (not today)
3/ Search for invoices and use the 4 different filters.
Close and reopen invoices.
The filters should be kept from one page to the other (not that it does
not work with shipment date before this patch).
4/ Receive an order, on creating the invoice, the default date should be
today.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Find another place where there is a patron search (add user to a basket,
add users to a fund or edit owner of a fund, set a guarantor to a child,
etc.).
Do a search a confirm that the results are now sorted by name instead of
cardnumber.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
While transferring an order, a untranslatable JavaScript confirmation
dialog pops up.
This patch moves the information about the order to be transferred to the
top of the screen to better inform the user what order is to be transferred,
and simplifies the confirmation dialog.
To test:
- Apply patch
- Transfer an order from a basket to another basket
- Verify, that on top of the screen an information is displayed about which
order from which vendor and basket is to be transferred
- Verify that the transfer works OK
- Update a po lang file and confirm you see the string and you are able
to translate it.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Dialog box with readable & translatable info.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This script has scary FIXMEs and can be removed.
It is never called from Koha code.
On the way, this patch remove the C4::Budgets::ModCurrencies subroutine,
which was only called from this script.
Test plan:
git grep 'acqui/currency.pl
and
git grep ModCurrencies
should not return anything.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No more ModeCurrencies, no call to acqui/currency.pl
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch does the following:
[1] Adjust authorities_merge_ajax just as in bug 14588.
[2] Replace some indirect syntax for fetch GGI::Cookie.
[3] Along the way replace some new CGI's. Note that I am not aiming to
replace them Koha wide. The "fetch class" variant is less readable.
NOTE: The changes to tools/upload-file.pl and upload-file-progress.pl
are moved to report 14321.
Test plan:
[1] Run the URL authorities/merge_ajax.pl in staff.
[2] Upload a file with Stage MARC records for import.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
[1] It runs, but also before patch
[2] File uploads without problem
No errors
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We could certainly remove 1 or 2 call to CGI->new in tools/background-job-progress.pl
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently the date of the order reception is the date of shipping date,
which is wrong.
This patch makes this date editable (with default is today).
Test plan:
1/ Create an order and receive it
2/ Confirm that you can edit the reception date and it's take into
account as the datereceived.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Create an order for an existing biblio, confirm that the pagination links work correctly.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from:
- acqui/pdfformat/layout2pages.pm
- acqui/pdfformat/layout2pagesde.pm
- acqui/pdfformat/layout3pages.pm
- acqui/pdfformat/layout3pagesfr.pm
To test:
- Apply patch
- Go to Home > Acquisitions > [Vendor] > Basket groups
- Print a basket (order)
- Verify that the current date is formatted respects syspref 'dateformat'
- Do the same with syspref 'OrderPdfFormat' set to the four different choices
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Date printed in PDF Ok
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The ind_tag of TransformHtmlToXml is unused.
Some calls to this function incorrectly revert indicator and ind_tag (which
is not a problem when both are empty..)
Patch of Srdjan Jankovic, amended and signed off by Marcel de Rooy.
The following calls are fixed:
call in acqui/addorder.pl: switched indicator with ind_tag
call in acqui/addorderiso2709.pl replaced too
acqui/finishreceive.pl replaced too
These calls are fine:
two calls in cataloguing/additem.pl are fine
call in serials/serials-edit.pl is fine
call in tools/batchMod.pl is fine
The folllow-up patch adds a simple unit test.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
With AcqCreateItem=='placing an order', tested if adding an order still
worked (covered both addorder.pl and addorderiso2709.pl).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch make inactive vendors really inactive.
That means an inactive vendor would not be able to add a basket / add an order.
Revised test plan
=================
1/ In the acquisition module create 2 vendors: 1 active and 1 inactive.
2/ On the acqui/booksellers.pl, acqui/uncertainprice.pl,
admin/aqcontract.pl and acqui/supplier.pl (pages which include the
acq toolbar), you should be able to, for both the 'active' as well
as the inactive vendor :
(a) add new basket
(b) add order items to the basket
Remark: This is *wrong*. You should be able to do so only for active
vendor.
3/ Apply the patch
4/ Go to the links in step #2 above and select the inactive vendor
you should no longer be able to:
(a) add new basket
(b) add order items to the basket
Remark: This is the *correct* behaviour
5/ No change should be noted for vendor marked "active", and should
be able to undertake operations 4 (a), 4 (b) and 4 (c).
Remark: This is the *correct* behaviour.
6/ run koha qa tests tool
Bug 12054: (follow-up) Inactive vendors should be inactive
Don't display "add order""block and buttons if the vendor is inactive.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Jonathan Druart agreed that C4::Input is vestigial code that should be removed.
Here is how I checked. First I found where C4::Input was used. Then, I checked
what functions are in the package: just checkdigit. Then, I confirmed that
checkdigit is not used at all in any acquisition, administration, or member
related perl scripts. Lastly, I took a look at our supposed test file for the
package. It was painfully sparse.
As such, this patch removes the test file and the package file, and removes
C4::Input references from these six files:
- acqui/addorderiso2709.pl
- acqui/basketgroup.pl
- acqui/neworderempty.pl
- acqui/uncertainprice.pl
- admin/aqplan.pl
- members/memberentry.pl
NOTE: neworderempty had 3 lines of it?! Didn't anyone see that?!
Here is the output of what I did to confirm this correction:
mtompset@debian:~/kohaclone$ git reset --hard origin/master
HEAD is now at 6e9086f Bug 3206: (QA followup) missing comma on sysprefs.sql
mtompset@debian:~/kohaclone$ git grep C4::Input
C4/Input.pm:package C4::Input; #assumes C4/Input
C4/Input.pm:C4::Input - Miscellaneous sanity checks
C4/Input.pm: use C4::Input;
acqui/addorderiso2709.pl:use C4::Input;
acqui/basketgroup.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/uncertainprice.pl:use C4::Input;
admin/aqplan.pl:use C4::Input;
members/memberentry.pl:use C4::Input;
t/Input.t: use_ok('C4::Input');
mtompset@debian:~/kohaclone$ grep sub C4/Input.pm
sub checkdigit ($;$) {
my $temp2 = substr($infl,$i,1);
if ($rem eq substr($infl,8,1)) {
} # sub checkdigit
mtompset@debian:~/kohaclone$ grep checkdigit `find acqui -type f`
mtompset@debian:~/kohaclone$ grep checkdigit `find admin -type f`
mtompset@debian:~/kohaclone$ grep checkdigit `find members -type f`
mtompset@debian:~/kohaclone$ cat t/Input.t
use strict;
use warnings;
use Test::More tests => 1;
BEGIN {
use_ok('C4::Input');
}
Apply this patch, and the output of git grep C4::Input will be empty.
Run koha qa test tools (kind of overkill)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Since Bug 14408, the method get_template_and_user can not have an empty template_name.
Pages calling with an empty value should use C4::Auth::checkauth()
This patch corrects acqui/updatesupplier.pl
Test plan :
- Apply patch
- Connect to intranet with a user having "vendors_manage" permission
- Go to acquisition module
- Create a new vendor
- Click on "Edit vendor"
- Change some information and save
=> Your change is saved
- Connect to intranet with a user not having "vendors_manage" permission
- Try to access <intranet>/cgi-bin/koha/acqui/updatesupplier.pl
=> Access is denied
- Disconnect from intranet
- Try to access <intranet>/cgi-bin/koha/acqui/updatesupplier.pl
=> Access is denied
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
When adding a batch of records to a basket, duplicates are skipped and
an alert is displayed with a link to them so as they could be treated
individually.
Test plan :
You need the 2 test attached files TestFile1.mrc and TestFile2.elc
(TestFile1 includes only the title "Amilec ou La graine d'hommes" that
is also included in TestFile2)
1) go to “Stage MARC records for import” page, upload TestFile1 and
stage it (select iso 5426 encoding).
2) Manage staged record and import the batch.
3) Make sure that the new record is indexed (depending to your indexing
system and test platform).
4) Go back to go to “Stage MARC records for import” page upload
TestFile2 and stage it (select iso 5426 encoding).
5) Go to acquisitions module and create a new basket.
6) From your basket, in the “Add order to basket block” choose 'From a
staged file'.
7) Then click File2 (‘addorder button').
8) Go down the "Import all" block and save.
9) You are redirected to the basket page : a warning is displayed to
tell you that some duplicates have been found and skipped.
There's a link on the warning throughout you can go back to the list of
remaining records and treat them individually if necesary.
10) Click the link : you fall upon the title of TestFile1 (of course as
it's a duplicate).
11) Check that the imported records have been indexed.
11) Go down the "Import all" block and save.
12) A warning is displayed saying that no records have been imported
because they all match an existing record. The “Import all” block is not
any more visible.
Signed-off-by: JA <aloi54@live.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Most of them were found and fixed using codespell.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
http://bugs.koha-community.org/show_bug.cgi?id=14383
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 14047: Sort z39.50 servers in Acquisition
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 14047: [QA Follow-up] Move result_class back into attributes
No need to put this into a separate call.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Note that we strictly speaking do not need the hashref inflator here,
because TT understands hash.column as well as object.property.
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the item for an order had been deleted since or there was never
an item created for the order (subscription orders) those records
where missing from the "Spent" page in acquisitions.
Patch corrects the SQL to list the correct records.
To test:
- Create different orders for one fund and receive them
- normal order with a few items
- subscription order (no item)
- normal order with an item, delete the item after receiving
- include some freight cost in one of the invoices
- Compare the amount spent shown on the acq start page
with the amount shown at the end of the 'spent' page
- Without the patch, the amounts don't match and not all
received titles are listed
- With the patch, amounts should match and list shoudl be complete
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This condition is never reached, the confirmation to delete a basket is
done with a popup in the template.
Test plan:
Confirm you don't find any regression when creation/editing and deleting
a basket.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: I didn't create or edit. However, the only perl script that uses
the template is acqui/basket.pl and the only place delete_confirm
is set in acqui/basket.pl is in that code which is only called if
del_basket actually existed anywhere else, which it doesn't.
I did have two baskets, one with two transfers from the first, so
I transferred one back, and then proceeded to test the two delete
buttons in the modal. No issues. Cancel (to close the modal) works
too.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
At the moment, it is possible to create records in acquisitions, but the
ACQ framework is only used for items created in this module.
This patch allows to defined default values in the ACQ framework for
records created on the acquisition module.
Test plan:
1/ Make sure you have the ACQ framework created (otherwise create it
from the default framework).
2/ Define a default value for a field (for instance 099$z=1).
3/ Go in the acquisition module and create a new order from a new
record.
4/ Fill mandatory information and save.
5/ Go on the detail page of this record and verify the default value
exist.
Signed-off-by: Gaetan Boisson <gaetan.boisson@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
These two subroutines did the same job (same select, same join, etc.)
Test plan:
Go on the basket list page and verify you see the pending and the
cancelled baskets.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Two small things are adjusted in separate follow-ups.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch fixes the regressions introduced by the previous patches.
If you have tested all in once, you didn't see them.
It introduces library, category and "first letter" filters.
Test plan:
1/ On all pages impacted by previous patches + new order empty (link patron to
an order) + guarantor search
2/ Add / Select patron to the list
3/ Use the filters
4/ Confirm there is no regression
Tested together with other patches.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The "Managed by" field displayed on creating/editing an order is always
the name of the logged in user.
To reproduce:
1/ Log in with patron A
2/ Create a basket
3/ Create an order
4/ Log in with patron B
5/ Edit the order
6/ The "Managed by" line is "patron B"
Test plan:
Apply the patch and confirm that the "patron A" is always the basket
manager.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
There is a badly managed date in acqui/basket.pl:
if the date is 15/01/2015 (metric format), it will become
2015-1-15 after the following line:
$estimateddeliverydate = "$year-$month-$day";
Add_Delta_Days is used at several place, and the ouput is forced to
display date on 4 digits and month/day on 2 digits.
This patch does the same thing for $estimateddeliverydate.
Note that I previously developed a patch to take this format into account (with missing 0)
in Koha::DateUtils::dt_from_string, but I don't think it's a good idea
to manage bad formated dates.
We will certainly find some issues after previous patches, but it will permit to catch
them!
IMO it's preferable than to keep them hidden.
The patch was:
diff --git a/Koha/DateUtils.pm b/Koha/DateUtils.pm
index 5fe2653..4434a67 100644
--- a/Koha/DateUtils.pm
+++ b/Koha/DateUtils.pm
@@ -72,17 +72,17 @@ sub dt_from_string {
my $fallback_re = qr|
(?<year>\d{4})
-
- (?<month>\d{2})
+ (?<month>\d{1,2})
-
- (?<day>\d{2})
+ (?<day>\d{1,2})
|xms;
if ( $date_format eq 'metric' ) {
# metric format is "dd/mm/yyyy[ hh:mm:ss]"
$regex = qr|
- (?<day>\d{2})
+ (?<day>\d{1,2})
/
- (?<month>\d{2})
+ (?<month>\d{1,2})
/
(?<year>\d{4})
|xms;
@@ -90,9 +90,9 @@ sub dt_from_string {
elsif ( $date_format eq 'us' ) {
# us format is "mm/dd/yyyy[ hh:mm:ss]"
$regex = qr|
- (?<month>\d{2})
+ (?<month>\d{1,2})
/
- (?<day>\d{2})
+ (?<day>\d{1,2})
/
(?<year>\d{4})
|xms;
diff --git a/t/DateUtils.t b/t/DateUtils.t
index 886e1d6..0877240 100755
--- a/t/DateUtils.t
+++ b/t/DateUtils.t
@@ -189,3 +189,8 @@ is( output_pref( { dt => $dt } ), '31/01/2015 12:34', 'dt_from_string should mat
# date before 1900
$dt = dt_from_string('01/01/1900');
is( output_pref( { dt => $dt, dateonly => 1 } ), '01/01/1900', 'dt_from_string should manage date < 1900' );
+
+# missing 0
+$dt = dt_from_string('1/1/2015');
+is( output_pref( { dt => $dt, dateonly => 1 } ), '01/01/2015', 'dt_from_string should generate a DT object even if 0 are missing' );
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch is the main patch.
The "common" template is improved to allow different type of picking:
"add" or "select".
The first one appends a patron to a list, the second one selects the
patron and close the result search window.
The members/guarantor_search.pl has completly changed but is quite the
same file as acqui/add_user_search.pl. Both should exist: they don't
belong to the same module (acqui vs members), the picking type is
different (add vs select) and the columns are not the same.
The changes in the common template are very powerful, it's now possible
to list the column we want! This will be very useful for further
reusability.
Before this patch, all patrons mathing the pattern were return. Now only
the first 20 are (depends on the DataTables selected value).
For QA: This patch introduces a new template plugin "To", for now it
permits to convert a perl structure to json. In the idea, it could
permit to convert foo to bar too.
Test plan:
1/ Verify there is no regression in the guarantor search. When the
selection has been done, all data from the guarantor should fill the
form in the "main address" section.
Note that the request is done when the search input in not empty and the
user stop to write for 1 sec.
2/ Verify there is no regression on the 2 other pages where this patron
search is used: link a patron to an order and to a basket (in the
acquisition module).
Signed-off-by: Morag Hills <the.invinnysible.one@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The add_user_search tt file will be reuse in next commits, this commit
just moves it in a "common" directory.
Signed-off-by: Morag Hills <the.invinnysible.one@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The date filters on the parcel page would only work with
dates formatted YYYY-MM-DD.
To test:
- Select a vendor, that already has a few invoices
- "Receive shipment" - you are on the parcels page
- Use the From and To filters on the left, notice there
is now a date picker on those fields
- Verify the search works correctly for different date
formats
Signed-off-by: Nicole <nicole@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When no search has been done yet, it's not necessary to display the
result list.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Before this enh, the users to add to a basket should have the
acquisition.order_manage permission.
This patch reintroduces this behavior.
The code in acqui/add_user_search.pl was never used. The filter should
be done in the members/search service.
But it is not possible easily to filter using a sql query, so the filter
is done after. This means that we cannot use the DT pagination
(otherwise the results will become inconsistent).
Test plan:
1/ On adding patrons to a basket, verify that the search patron results contain
patron with the acquisition.order_manage permission.
2/ Verify that all patrons are return on the 'normal' patron search and
when adding patrons to an order.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch is the main patch.
This feature adds the ability to link patrons to an order.
On that way, they will be notified when the order is completely
received.
Test plan:
1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl).
code: ACQ_NOTIF_ON_RECEIV, module: acquisition
2/ You can edit it if you want
3/ Create a basket and create an order with 1 or more items
4/ Link 1+ patrons to this order
5/ Close the basket and receive the order
6/ When you have received all items for this order, all patrons attached
will be notified. Check the message_queue table to check if the letters
have correctly been added to the queue.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
A previous enhancement allows to link basket with patrons.
Next patches will use the same way to link order with patrons.
In order to avoir c/p of code, this patch refactores this part of code.
Test plan:
1/ Verify there is no regression on adding/modifying users to a basket.
(acqui/basket.pl?basketno=XXX, "Managed by", "Add user").
2/ Note that you get a friendly message if the user is already present in the
list and when the user has correctly been added to the list.
3/ Note that the list uses the member search service (ie. DataTable +
serverside processing).
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If more that 1 tax rate exist, 1 total ligne should be display in the
footer.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Previous patch does modify the code for cancelled orders.
Test plan:
Cancel 1+ orders and verify the prices are correct (i.e. the same as
the non-cancelled orders) and that the prices are formated.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12969 introduces a subroutine to centralize VAT and prices
calculation.
It should be use in the acqui/basket.pl script.
Test plan:
0/ Don't apply the patch
1/ Create 4 suppliers with the different configurations
2/ Create a basket and create several orders
3/ Go on the basket page
4/ Apply the patch
5/ Verify you don't see any difference before and after applying the
patch
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If more that 1 tax rate exist, 1 total ligne should be display in the
footer.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12969 introduces a subroutine to centralize VAT and prices
calculation.
It should be use in the acqui/invoice.pl script.
Test plan:
0/ Don't apply the patch
1/ Create 4 suppliers with the different configurations
2/ Create a basket and create several orders
3/ Receive the items and create an invoice
4/ Go on the invoice page acqui/invoice.pl?invoiceid=XXX
5/ Verify you don't see any difference before and after applying the
patch on the invoice details table.
Note: The only different you should see is the price formating for
"Total tax exc.". Before this patch "432.10" was displayed "432.1".
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The acquisitions search is exhibiting the same behavior as bug 11410.
Results are always fixed in order of biblionumber, among other possible
issues ( including the ampersand issue ).
Test Plan:
1) From an open basket, choose "Add to basket"
2) Run a search for "From an existing record"
3) Note the "View MARC" URLs are fixed in order of biblionumber
4) Apply this patch
5) Refresh the page
6) Note the results are no longer fixed in order of biblionumber
Signed-off-by: David Cook <dcook@prosentient.com.au>
Works as described.
I think the code could be a bit tidier, but I think it makes sense to
use buildQuery here. It'll detect CCL, CQL, and PQF queries, as well
as parsing a regular keyword search as one would expect when searching
the catalogue.
It also has the added bonus of performing relevance searching,
so long as QueryAutoTruncation is off, and so long as library staff
avoid using the "*" truncation wildcard (see bug 12430).
While there are simpler ways to fix this acq bug, I think this was
probably the best move, as it adds a bit to the consistency of what
librarians can expect from their search results.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Same result with and without the patch but I agree with the changes.
BuildQuery should be called before SimpleSearch if QP is not used.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds the ability to search orders using the basket creator.
Test plan:
- go on the order advanced search form (acqui/histsearch.pl)
- use the autocomplete input to search patrons
- launch the search and verify the results are consistent with the
values you have filled.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12969 introduces a subroutine to centralize VAT and prices
calculation.
It should be use in the acqui/basketgroup.pl script.
Test plan:
0/ Don't apply the patch
1/ Create 4 suppliers with the different configurations
2/ Create a basket and create several orders
3/ Close the basket and create the corresponding basket groups.
4/ Print the basket group
5/ Verify you don't see any difference before and after applying the
patch on the pdf file.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In parcel.tt, total are calculated for subtotal.
This could be done in the pl script for more consistency.
Test plan:
Go on a parcel page with several already received orders.
Orders must be linked to different funds.
If possible ecost and unitprice (price on ordering and on receiving)
should changed (different values will be displayed in the table).
The values displayed before and after the patch must be the same.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
For already received orders, the total should be calculated with the
unitprice, not the estimated cost.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12969 introduces a subroutine to centralize VAT and prices
calculation.
It should be use in the acqui/parcel.pl script.
Test plan:
1/ Create 4 suppliers with the different configurations
2/ Create a basket and create several orders
3/ Go on the parcel page
4/ You should see, on the "pending orders" table, the same prices as
before this patch.
Note that the prices are now correctly formated.
You could see one change for the supplier configuration 3 (1 0):
If the cost of the item is 82, discount 10% and vat 5%:
The "Order cost" = 140.58 instead of 140.57.
Indeed, before this patch, the order cost was wrong, now you should have
70.29*2 = 140.58
( before: 140.58 + 7.03 = 147.61
now: 140.58 + 7.02 = 147.60 )
5/ Receive the items and return on the parcel page
Now the "Already received" table with the same prices as before this
patch.
Note some differences too:
- There was a td tag missing, the table was badly formated, it's now
fixed (column below the "Cancel receipt" link).
- The prices are now correctly formated.
- For the configuration 2 (1 1), if the cost of the item is 82, discount
10% and vat 5%:
( before: 140.57 + 7.03 = 147.60
now: 140.58 + 7.02 = 147.60 )
Note that 7.03 is the "correct" value, but on all other pages, 7.02 is
displayed.
To be consistent, we should display the same prices everywhere.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
