- fix unit tests (use a transaction).
- add 3 tabs on the page in order to be more understandable.
- fix a warn in logs
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The js function fetchSortDropbox has been deleted in previous patch.
The new function is getAuthValueDropbox.
Test plan:
- link authorized values to some funds
- open an existing order and verify value are correctly filled in the
sort1 and sort2 values
- create a new order and verify behavior is the same as before
Note: This patch generates 2 ajax queries (max) if the budget is linked
to 2 av categories for sort1 and sort2. This could be improved using a
template plugin for values display on load.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- the blank line is now useless
- add an example for the syspref value
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Ergonomic improvements:
- Remove the green color the selected record.
- Use fieldset.rows (and legend).
- Use the required css class for quantity inputs.
- Replace "budget" with "fund".
- fix the "undefined" string
- Add a "show MARC" link
- replace "no_match" with a text.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds:
- 1 syspref MarcFieldsToOrder
- 1 Ajax script acqui/ajax-getauthvaluedropbox.pl
- 1 routine C4::Budgets::GetBudgetByCode
Before this patch you were not able to order 1 or all the records from
your staged file. You were allowed to specify some information ("Import
All" and "Accounting details" areas) for the order.
With this patch, the previous behaviour still exists.
But now you can *select* which records you want to ordered.
For these ones you can specify independently quantity,
price, budget, sort1 and sort2.
The cherry on the cake is that you can pre-fill these fields with
values from the MARC record.
Test plan:
1. Fill the new syspref MarcFieldsToOrder with something like:
==BEGIN==
price: 947$c
quantity: 969$h
budget_code: 922$a
rrp: 010$d
discount: 969$d
sort1: 923$a
sort2: 924$a
==END==
The empty line at the end is mandatory!
The budget (corresponding to your budget_code) can be filled with
authorized value categories (statistic 1 and 2).
The sort1 and sort2 values can be filled with the an authorized value
(of the category previously selected)
2. Choose randomly one or more biblio(s) and fill fields with what is
relevant.
3. Export the biblio and import it (with the "Stage MARC records for
import" tool).
4. Go on a basket and add an order from a staged file. Select your
staged file.
5. Well. Now you can see your biblio (or biblios if your had exported
more than one). For each one, fields should be pre-filled with the
biblio values. The budget should be selected on the budget
corresponding to the budget_code (in the field 922$a) and the
"planning values" too (with fields 923$a and 924$a).
You can modify these values (or not) and choose a default value for
budget and planning values (in the "Accounting details" area).
6. Save and check the prices values. Modify the order and check that
budget and sort* are good
Prices are calculated following some parameters:
if there is no price => listprice = 0
else =>
- the gstrate value for your order is the gstrate value of the bookseller
- discount = if filled : the discount value / 100
else: the discount value of the bookseller
- if the bookseller includes tax( List item price includes tax: Yes )
if a discount exists:
ecost = price
rrp = ecost / ( 1 - discount )
else: # a discount does not exist
ecost = price * ( 1 - discount )
rrp = price
else # the bookseller does not include tax
if a discount exists:
ecost = price / ( 1 + gstrate )
rrp = ecost / ( 1 - discount )
else: # a discount does not exist
rrp = price / ( 1 + gstrate )
ecost = rrp * ( 1 - discount )
- in all cases:
listprice = rrp / currency rate
unitprice = ecost
total = ecost * quantity
7. Retry with different parameters
8. Check the 'Import all' action still works
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes the following QA issue:
FAIL acqui/invoice.pl
FAIL valid
Useless use of private variable in void context
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patch passes all tests and QA script. Specifically checked
the t/db_depenedent/Acq* tests.
A test plan could be:
0) Add a value in the gist pref (0.1 or 0.25 or something else easy).
1)
a) Create a supplier "10613 0 0" with
List item price includes tax: No
Invoice item price includes tax: No
Tax: 10%
b) Create a supplier "10613 0 1" with
List item price includes tax: No
Invoice item price includes tax: Yes
Tax: 10%
c) Create a supplier "10613 1 0" with
List item price includes tax: Yes
Invoice item price includes tax: No
Tax: 10%
d) Create a supplier "10613 1 1" with
List item price includes tax: Yes
Invoice item price includes tax: Yes
Tax: 10%
2) Create a basket for each supplier
a) 00 List price: 10.00 (11.00 with 10% taxes)
b) 01 List price: 10.00 (11.00 with 10% taxes)
c) 10 List price: 10.00 (9.09 without taxes)
d) 11 List price: 10.00 (9.09 without taxes)
Note: Information on the basket page is shown correctly.
If you look at the list of ordered items for the fund,
the list price is used.
3) Create 1+ order(s) with 1+ item(s) for each basket with
a discount and a gst value.
4) Close the baskets
5) Receive the items
Left actual price as suggested:
a) 00 Actual cost: 10.00
b) 01 Actual cost: 11.00
c) 10 Actual cost: 9.09
d) 11 Actual cost: 10.00
Calculations on the invoice page now all appear to be correct.
Note: When you take a look at the 'ordered' list for the fund,
the actual price is used as entered.
6) Go on acqui/invoice.pl?invoiceid=XX acqui/basket.pl?basketno=YY for
each basket/invoice, click on the "Show all details" checkbox
and verify that the values are all correct.
Calculations are exactly the same for tax registered yes and no.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
GetInvoiceDetails returns a hashref with a key named booksellerid, not
supplierid.
The bookseller was not retrieved from the DB and the listincgst value
was always false.
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
Defined a GST rate on creating an order, receive it and check that all
prices are correctly calculated.
/!\ Behavior change function of supplier parameters (Include/Don't
include tax for list prices and invoice prices)
Notes: patch tested with Bug 11755 applied first; confirmed that:
- price calculations are correct for all combinations of
listincgst/invoiceincgst settings in the vendor record
- unitprice (aka "Actual cost") is taken into account on the
invoice page instead of rrp/ecost, like it should.
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This enhancement introduces a possibility to place orders
from hold ratios list:
- new option "Add order to basket" -> "From titles w/ highest hold ratios";
(user gets redirected from acqusition to "hold ratios" list in circulation)
- "N to order" in "Items needed" column now becomes a link - when clicked,
user gets redirected back to acquisition, directly to order form for
a choosen title (suggested quantity "N to order" is being preserved)
- in the "Items needed" column, there is an additional indication if
there are any pending (not yet received) orders for a given title
This solution is not exactly ideal.. most important drawback: to use
it librarian needs both acquisition & circulation priviledges; if not
having both - new options will not show / wouldn't be active. But it
requires relatively small amount of changes in the code.
To test:
- apply patch,
- test new functions (try to place some orders using an newly added
option, examine resulting order records etc.)
- check modified hold ratios list for possible problems (for user
with only circulation priviledges, additional information regarding
pending orders should be still visible, but not the link
to order form)
- ensure the two following existing options for adding orders to basket
("From an existing record", "From a new (empty) record") a still working
properly.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Minor edit in signoff: Changed "w/" to "with"
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works nicely in my tests, neat new addition.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch removes instances of dt_add_type_uk_date() from acquisitions
templates and updates sorting configurations according to current
guidelines.
In cases where a formatted date was passed from a Perl script, the
script has been modified to pass an unformatted date.
Several instances of the no longer valid align attribute have been
removed from <td> tags in favor of an existing "data" class which is
suitable for display of currency values.
To test, view the following pages in Acquisitions. Columns containing
dates should sort correctly regardless of dateformat system preference
setting. Columns containing bibliographic titles should ignore articles
when sorting.
- Add to an order from a staged file: The table of staged files should
sort correctly. After clicking "add orders" for one of the staged
files, the table of titles in that staged file should also be sorted
correctly.
- Add to an order from a subscription. The table of subscription search
results should sort correctly.
- Orders search results should sort correctly.
- Late orders should sort correctly.
- Search for a vendor. Click on the vendor name to view the vendor
detail page. The table of contracts on this page should sort
correctly.
- From the Acquisitions home page click a number in the "spent" column
of the table of available funds. The table of orders should sort
correctly.
- From the Acquisitions home page click a number in the "ordered" column
of the table of available funds. The table of orders should sort
correctly.
- From a vendor detail page, click the "Receive shipments" button. On
the receive shipments page the table of shipments should be sorted
correctly.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Follow up to the patch for the English templates - repeat tests
with OrderPDFFormat set to pdfformat::layout3pagesfr.
Additional change:
Translates 'published by' to 'publie par'
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Follow up to the patch for the English templates - repeat tests
with OrderPDFFormat set to pdfformat::layout2pagesde.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Switch OrderPdfFormat to pdfformat::layout3pages
- Create one or more baskets with a few orders, make sure you
are adding some records that contain a publication year and/or
edition statement
- Close the basket
- Create a basket group
- Print the PDF and check that edition and publication year
show up and bibliographic information is printed correctly
- Switch OrderPdfFormat to pdfformat::layout2pages
- Repeat PDF print
This patch also changes the formatting a bit and differentiates between
UNIMARC and MARC21. For MARC21 no additional punctuation is needed as
those are cataloged with the information. Only spaces are added for MARC21,
while UNIMARC is kept they way it was before.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch removes the ability of finishreceive.pl to change the vendor
note of an order. It also uses a normal span rather than a disabled
textarea to display the vendor note on the receiving page, to emphasize
that it cannot be changed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
It is now possible to search on the order number on the order search
page.
Also searching on parent_ordernumber is possible, allowing one to
search to search children for a given order number.
Test plan:
1/ create a basket and 1 order with at least 2 items.
2/ receive partialy the order (receive only 1 item).
3/ note that a new ordernumber is created for item not received.
4/ go on the order search form and search for the original ordernumber
without checking the new checkbox "Display children too." => only 1
order (the parent) is displayed.
5/ now check the checkbox and search again => the parent order is
displayed but children too.
Signed-off-by: remy juliette <juliette.levast@iepg.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely, passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch teaches the ordering receiving process how to
set vendor and internal order notes.
One observation: I'm not sure it's entirely useful to set
a note to communicate to the vendor during receiving --
how is it to be sent to them, and why?
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This followup answer QA remarks :
- neworderempty.pl updated so that the 2 new variables are passed
to the template
- modordernotes.tt fixed to make the translation easier
- in CSV headers, to make clear that no change are made for the moment,
rename "note" to "internal note"
Additionnaly, "Publisher code" was wrong in the csv headers. I changed
it to "Publisher" (the field in database is publishercode, but the
content is a real publisher name, not a code)
I did not change "Note:" in modordernotes.tt, because it is just under
a h1 tag which specifies the type of note the librarian is editing.
Test plan :
- edit an existing order, and try to change/add/delete the vendor note,
and the internal note. Check the changes are properly saved
- export a basket and a basketgroup in CSV. Check the columns headers
are "Publisher" and "Vendor note"
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed some tabs. Passes QA script and tests.
Tested:
- add notes when creating an order
- edit notes modifying an order line
- edit notes using the links on the basket summary
- check basket CSV export
- close basket
- check basket group CSV export
- edit notes on order receive page using the links
- edit notes on receive
Note: Translatability of templates could be improved by a follow-up.
It's better not to divide up sentences with if/else structures.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently, there is a single note field in each order. It would be
useful to have 2 notes fields:
- one for the staff (ex: "catalog this book as soon as possible")
- one for the vendor (ex: "urgent", "only the 2d volume"...), which
could later be printed in basketgroup pdf for example
This patch adds a new note made for vendor in each order. The existing
note is renamed "internal note".
The behavior of the 2 notes are the same
Changes in database structure:
- new column aqorders.order_vendornote
- column aqorders.notes renamed aqorders.order_internalnote
To test :
[1] Make a complete acquisiton process (creating the order > looking at
the basket > looking the order > receiving); and try to use the 2
notes (internal note / vendor note)
[2] Check the changes made on one page (eg detail of the order) are
saved and visible on an other page (eg receipt page)
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
prove t/db_dependent/Acquisition.t
prove t/db_dependent/Acquisition/Invoices.t
prove t/db_dependent/Acquisition/OrderFromSubscription.t
all should return green.
NOTE: Any error messages are the same between master and this
patch, and are unrelated to the added/revised tests.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Revised test plan:
1/ Create an order with 2 items
2/ Receive 1 item and enter a note for the order
3/ Verify the note is not saved
The note should be visible on the Mod Order Details screen,
but it isn't there.
4/ Apply patch
5/ Receive the second item and enter a note for the order
6/ Verify the note is correctly saved
The note is visible on the Mod Order Details screen.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works as described. The note now saves correctly and also remains when
you undo a receipt.
Note: it would be nice to show the note on the receive page as well.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Follow-up to fix similar issue on vendor edit.
If the tax rates in Acquisitions -> gist system preference
are entered with trailing zeroes, given vendor tax rate value
may not be correctly handled on vendor edit.
Test plan for this follow-up:
1) insert some tax rates with trailing zeroes in gist
system preference (e.g: '0|0.080|0.12|0.20|0.23')
2) add some vendors, choosing 8.0% 12.0% 20.0% 23.0%
as gst rate
3) try to modify them
4) note that vendors with 12.0% and 23.0% tax rates are
preserving previously choosen rates on edit, while
the ones with 8.0% and 20.0% do not (they are defaulting
to the first defined tax rate)
5) apply the patch
6) repeat 2) and 3)
7) all tax rates configured in system prefrence shall now
behave properly while editing vendors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If the tax rates in Acquisitions -> gist system preference are entered
with trailing zeroes, given order tax rate value may not be correctly
handled on order edit.
To test:
1) insert some tax rates with trailing zeroes in gist
system preference (e.g: '0|0.080|0.12|0.20|0.23')
2) place some new orders, choosing 8.0% 12.0% 20.0% 23.0%
as gst rate
3) try to modify them
4) note that orders with 12.0% and 23.0% tax rates are
preserving previously choosen rates on edit, while
the ones with 8.0% and 20.0% do not (they are defaulting
to the first defined tax rate)
5) apply the patch
6) repeat 2) and 3)
7) all tax rates configured in system prefrence shall now
behave properly while editing orders
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed the problem and that this patch fixes it.
Problem also exists for editing the default tax rate of a vendor.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When order is being created from purchase suggestion:
- Budget/fund stored in suggestion record (if any) is not retained
on order page, system always defaults to 'Select a fund' even if some
fund was already chosen for a suggestion on the earlier stage.
- If there was a price given to, and stored within suggestion record,
initial prices calculations on order page are not working properly
('Replacement cost', 'Budgeted cost' and 'Total' show as 0.00 or blank).
As a workaround - to force correct price recalculation - user needs
to manually alter and then re-alter some price-related fields (e.g.,
quantity or vendor price).
This patch fixes both issues.
Test plan:
1) create a suggestion: choose some buget, enter something in 'Price'
and 'Quantity' fields,
2) try to make an order from this suggestion, to confirm/replicate
aforementioned problems,
3) apply patch,
4) make an order from previously created suggestion again, observe
that both issues are now resolved.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Switch system preference OrderPdfFormat to pdfformat::layout2pagesde
- Create one or more baskets with some orders each.
- Add all baskets to one basket group
- Print the basket group
- Check the account number from your vendor shows up with the other
vendor details
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Switch system preference OrderPdfFormat to pdfformat::layout2pages
- Create one or more baskets with some orders each.
- Add all baskets to one basket group
- Print the basket group
- Check the account number from your vendor shows up with the other
vendor details
- Repeat with pdfformat::layout3pages
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Switch system preference OrderPdfFormat to pdfformat::layout3pagesfr
- Create one or more baskets with some orders each.
- Add all baskets to one basket group
- Print the basket group
- Check the account number from your vendor shows up with the other
vendor details
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Switch system preference OrderPdfFormat to pdfformat::layout2pagesde
- Create one or more baskets with some orders each.
- Add all baskets to one basket group
- Print the basket group
- Check everything is translated into German and the formatting/layout
looks ok
Followed test plan and compared English with German printout.
German version is OK.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
in Acq baskets, there's a pull-down for basket groups. One of the
entries in that pull-down is "No group", which is untranslatable.
This string is hard-coded in Perl.
This patch removes the string from Perl to set it has first option
in select. To allow it to be default value, the option "Add new group"
is moved to last position.
Test plan :
- Go to a closed aquisition basket in no basket group :
cgi-bin/koha/acqui/basket.pl?basketno=x
=> You see "No group" selected in combobox "Basket group"
- Cick on this combobox
=> You see "No group", then existing basket groups and then "Add new
group"
- Select a basket group and click on "change basket group"
=> You see the basket group name in combobox
Use translation, for example fr-FR
- go to src/misc/translator
- run : perl translate update fr-FR
=> You find in PO file :
#: intranet-tmpl/prog/en/modules/acqui/basket.tt:365
#, fuzzy, c-format
msgid "No group"
msgstr "Nom de groupe"
- remove ", fuzzy" and correct translation : "Pas de groupe"
- run : perl translate install fr-FR
- Go to translated aquisition basket page
=> You see translated option in combobox
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
There was some code in acqui/basketgroup.pl that was apparently
intended to let one create a basket group for no (or an unknown)
vendor. However, this code was never reached, as there is nothing
in the templates that invokes basketgroup.pl with 'add' as the
operation that doesn't also pass the vendor ID along.
This patch removes that dead code.
To test:
[1] Create a new basket group for a vendor and verify that it is
created correctly.
[2] Edit an existing basket group, including moving baskets in and
and out of, and verify that it works.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
No regressions found, passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The order status ordered is set when the basket is closed.
The parcel page should only display status "ordered" and "partial".
Test plan:
- create a basket.
- create an order.
- verify the order is not listed on the parcel page (i.e. you cannot
receive it).
- close the basket.
- verify the order is listed on the parcel page.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes Koha <-> Zebra use MARCXML for the serialization when
using DOM, and USMARC for GRS-1.
* The following functions are modified to set the Zebra record syntax
according to the current sysprefs and configuration:
- C4::Context->Zconn
- C4::Context-_new_Zconn
* A new function 'new_record_from_zebra' is introduced, which checks the
context we are in, and creates the MARC::Record object using the right
constructor.
The following packages get touched to make use of the new function:
- C4::Search
- C4::AuthoritiesMarc
and the same happens to the UI scripts that make use of them (both in
the OPAC and STAFF interfaces).
* Calls to the unsafe ZOOM::Record->render()[1] method are removed.
Due to this last change the code for building facets was rewritten. And
for performance on the facets creation I pushed higher version
dependencies for MARC::File::XML and MARC::Record (we rely on
MARC::Field->as_string).
* Calls to MARC::Record->new_from_xml and MARC::Record->new_from_usmarc
are wrapped with eval for catching problems [2].
* As of bug 3087, UNIMARC uses the 'unimarc' record syntax. this case is
correctly handled.
* As of bug 7818 misc/migration_tools/rebuild_zebra.pl behaves like:
- bib_index_mode (defaults to 'grs1' if not specified)
- auth_index_mode (defaults to 'dom')
here we do exactly the same.
To test:
- prove t/db_dependent/Search.t should pass.
- Searching should remain functional.
- Indexing and searching for a big record should work (that's what the
unit tests do).
- Test an index scan search (on the staff interface):
Search > More options > Check "Scan indexes".
- Enable 'itemBarcodeFallbackSearch' and try to circulate any word, it
shouldn't break.
- Searching for a biblio in a new subscription shouldn't break.
- Running bulkmarcimport.pl shouldn't break.
- And so on... for the rest of the .pl files.
[1] http://search.cpan.org/~mirk/Net-Z3950-ZOOM/lib/ZOOM.pod#render()
[2] a record that cannot be parsed by MARC::Record is simply skipped (bug 10684)
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
On editing a basketgroup, the currency for baskets in a basketgroup is
always '0'.
With this patch, the currency is correctly displayed.
TEST PLAN
=========
1) Log into staff client
2) Acquisitions
3) Click 'Search' in the 'Manage orders' box
4) Click '+ New basket' because a vendor name
5) Type 'Test Basket' into basket name
6) Click 'Save'
7) Click 'Add to basket'
8) Click 'From an external source'
9) Type 'Green Eggs and Ham' into the Title text box
10) Click 'Search'
11) Click 'Order' on any one of the results
12) Click 'Add Item' in the 'Item' box
13) Select a Fund from the dropdown in the
'Accounting details' box
14) Click 'Save'
15) Click 'Close the basket'
16) Click 'Yes, close (Y)' without checking attach to a
basket group
17) Click the 'Basket groups' tab
18) Click '+ New basket group'
19) Notice the listing in the 'Ungrouped baskets'.
20) Drag and drop the entry into the 'Baskets in this group'
text area
21) Click 'Save'
22) Click 'Edit'
23) Notice it displays incorrectly. (e.g. Total: 0 0)
24) Apply the patch (git bz apply 11471)
25) Refresh the page
26) Notice it displays the currency correctly. (e.g. Total: 0 USD)
NOTE: If there is a space issue, see Bug 9654.
This can be applied separately from that bug.
27) Run the Koha QA Tool: (~/qa-test-tools/koha-qa.pl -v 2 -c 1)
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The return from GetReservesFromBiblionumber contains an unnecessary
extra variable. In scalar context an array returns its element count.
Maintaining a separate count can lead to unforeseen bugs
and imposes ugly constructions on the subroutine's users.
Remove the useless count variable from the return
This patch also changes the parameters: now the routine takes a hashref.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Placed biblio holds, future holds and item holds. Works as expected.
Tested Holds.t and Reserves.t. Pass.
Tested /cgi-bin/koha/ilsdi.pl?service=GetRecords&id=999 with two holds on
one item. Fine.
C4/SIP/ILS/Item.pm: Looked for "whatever" and "arrayref" and could not find
them anymore. Looks good.
Handled a few unneeded calls in QA follow-up.
Left only one point to-do for serials/routing-preview.pl. See Bugzilla.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
On receiving orders, the librarian has to filter again the pending
orders list.
This patch stores the filters in a cookie in order to apply them when
the librarian finish a receive and come back on the pending orders list.
Test plan:
1/ choose a vendor with several baskets and orders.
2/ start to receive an item.
3/ on the pending orders page, add some relevant filters.
4/ receive an item.
5/ you are back on the pending orders page and filters are directly
applied.
Signed-off-by: Nicolas Bravais <nicolas.bravais@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Tested with receiving and cancelling the receive process the
filters are kept.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In basketgroup.pl, some code is supposed to be executed if
$op = "validate". But this value is no longer assigned to
the $op variable since 2009.
This patch suppressed dead code, along with parseinputbaskets
and parseinputbasketgroups subs, which are obsolete.
No functional changes expected
Regression test :
* Check basketgroup are shown as before the patch, and can be closed
and reopened.
* Check you can add or remove a basket from a basketgroup, and change
information about it (like delivery place)
* Check you can create a basketgroup when you close a basket.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
The following commands return nothing:
- grep validate acqui/basketgroup.tt
- grep -R basketgroup.pl -C 2 | grep validate
- git grep parseinputbaskets
- git grep parseinputbasketgroups
- git grep basketgroup.pl | grep validate
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Weird behavior:
When an import is undone into catalog, the status is set to "reverted".
But if you open the add orders from iso2709, the status is automatically
set to "imported" and does not appear in the list.
So it is not possible to import a reverted batch.
[RM note: since a reverted batch is nonetheless a staged batch, and
could be reused, allowing orders to be placed by taking bibs
from a reverted batch is not as odd as it might sound. It *can* look
odd for a staged or reverted batch to contain records that are
imported, but that's a long-standing oddity.]
Test plan:
- verify you reproduce the weird behavior
- apply this patch
- import a file and the batch into the catalog
- verify (in the your mysql/MariaDB cli) the status is "imported"
- verify it does not appears in the add orders from iso2809 page
- undo the import
- verify (in the your mysql/MariaDB cli) the status is "reverted"
- verify it appears in the add orders from iso2809 page and the status
is always "reverted"
- finish the order
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Changed:
$total .= $bookseller->{invoiceprice} // 0;
Into:
$total .= " " . ($bookseller->{invoiceprice} // 0);
in order to add a space between the total and currency in
the basket group.
Revised test plan:
1) Log into staff client
2) Acquisitions
3) Click 'Search' in the 'Manage orders' box.
4) Click '+ New basket' beside a vendor name.
5) Type 'Bug 9654 Test 1' into basket name.
6) Click 'Save'
7) Click 'Add to basket'
8) Click 'From an external source'
9) Type 'Green Eggs and Ham' into the Title text box.
10) Click 'Search'
11) Click 'Order' on any one of the results.
12) Click 'Add Item' in the 'Item' box.
13) Select a Fund from the dropdown in the
'Accounting details' box.
14) Click 'Save'
15) Click 'Close this basket'
16) Click 'Yes, close (Y)' without checking the attach to a
basket group.
17) Click the 'Basket groups' tab.
18) Click '+ New basket group'
19) Notice the listing in 'Ungrouped baskets' lacks a space
between the number and the currency. (e.g. Total: 0USD)
20) Apply patch (git bz apply 9654)
21) Refresh the page
22) Notice there is now a space. (e.g. Total: 0 USD)
23) Run the Koha QA Tool: (~/qa-test-tools/koha-qa.pl -v 2 -c 1)
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The method of checking the logged in user for superlibrarian privileges
is obtuse ( $userenv && $userenv->{flags} % 2 != 1 ) to say the least.
The codebase is littered with these lines, with no explanation given. It
would be much better if we had one subroutine that returned a boolean
value to tell us if the logged in user is a superlibrarian or not.
Test Plan:
1) Apply this patch
2) Verify superlibrarian behavior remains unchanged
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on second patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Problem summary: when doing partial receives for the given order -
1) if AcqCreateItem is set to 'ordering', various item data (price,
dateaccessioned, replacementprice, replacementpricedate) are getting
erroneously updated on the wrong (yet to be received == not the ones
being currently received) item records
2) if AcqCreateItem is set to 'receiving', newly received
item records are being created without the aforementioned fields
set to the proper values
This (trivial) patch should deal with both cases, hopefully without
breaking enything else.
To test:
- apply the patch,
- create some orders with 2+ quantity
- test partial & non-partial receives for those orders
- ensure the received item records are getting modified
(for AcqCreateItem set to 'ordering') and/or created (for AcqCreateItem
set to 'receiving') correctly for both partial and non-partial receives
- receiving orders with quantity = 1 / receiving orders in non-partial
mode should be still working fine for 1) & 2) scenarios (i.e.,
AcqCreateItem set to 'ordering' / AcqCreateItem set to 'receiving')
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Works as I'd expect now! Awesome patch.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Also: t/db_dependent/Acquisition/
t/db_dependent/Acquisition.t
Created 2 orders with 3 items each for both settings
of AcqCreateItem (on receive, on order) with the patches
applied. No regressions found.
Closed baskets and received shipments for each, with
AcqCreateItem set according to how the order was created.
First recreated the problem without the patches, reloaded
database and confirmed that the patch fixes it.
No problems found.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch make possible to view an individual closed basket group
without reopening it.
- It adds a new "View" button on closed basket group list
- It creates a view for closed basket groups, with 3 buttons (reopen,
print, export)
- It adds a "delete" button on standard "edit" view (for open
basket groups)
To test :
1/ regression test :
- create some empty basket groups
- create some basket groups by closing baskets
- in the list of basket groups closed and opened, check you can use
the buttons that existed before the patch (close and print, delete,
export, print, reopen)
- click on "Edit" to edit a opened basket group : check everything is
like before :
-- change the billing and delivery places,
-- add a note,
-- put some new baskets in the bg,
-- remove baskets from it
-- save it without checking "close" box => it should be saved but kept
open
-- edit it again, and make other some changes (define a freetext
delivery place for example)
-- save it with checking "close" => it should be saved but closed
2/ new feature test
- click on "view" button on top right column of some closed basket group
- check all the displayed informations are correct (places, free place,
note, list of baskets)
- check you can not change anything
- click on "print" button => check a pdf is created
- click on "export" button => check a csv is created
- click on "reopen" button => you should stay on the same basket group, but
it is now open and you can make some changes
- go back to the basket group list of the vendor. Check the reopened bg
is in "open" tab
- click on "edit"
- click on new "delete" button => the bg should be deleted, and you are
redirected to the bg list of the vendor.
Signed-off-by: cedric.vita@dracenie.com <cedric.vita@dracenie.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, t and xt. Works as advertised.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Under Plack/mod_perl wrapping, sub update_item() will become a closure,
so after the 1st run it will retain its own private instances of the
following variables: $booksellerid, $datereceived, $unitprice, $rrp,
$biblionumber.
I.e., in case update_item() gets invoked 2nd+ time (inside
the same process, but for different-subsequent receives) it may
incorrectly flag the (old, wrong) biblionumber for Zebra reindexing,
and erronously modify the current item[s] with the previously
used (wrong) values.
This simple patch should make acqui/finishreceive.pl Plack-compatible.
Test plan:
Test patched acqui/finishreceive.pl script (create and receive some
orders w/ items, etc.). Ensure items are gettting added and/or modified
correctly during receiving process.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised, no regressions found.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This followup add some warnings after deletion if some items were not
deleted.
4 types of messages are possible :
- x item(s) attached.
- x subscription(s) attached.
- x order(s) attached.
- Unknown error.
To test :
test a
1. create a basket with
- an order using a record A which has already an item, which is used in
a subscription, and in other order (in an other basket)
- an order using a record B used nowhere elese
2. click on "Delete basket"
3. choose button "Delete basket, orders and records"
4. you should see a page anouncing basket deletion, and that record A was
not deleted because of its item, subscription and order.
5. check the link around the title of record B takes you to the record
6. check the link under the warning box ("Click here to go back to
booksellers page") takes you to booksellers page
5. check record B is deleted
test b
1. suppress the subscription linked with record A
2. create an other basket using record A
3. delete the basket on the same way as for test a
4. you should see a page anouncing basket deletion, and that record A was
not deleted because of its item and order
test c
1. suppress the item attached under record A
2. create an other basket using record A
3. delete the basket on the same way as for test a
4. you should see a page anouncing basket deletion, and that record A
was not deleted because of its orderBug 7791 Followup: add warning
after deletion if some records were not deleted
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch
- delete warns
- add a missing }
- add a condition in template of avoiding asking to delete orders or
records if the basket is empty
To test :
1. Make the same tests as defined in test plan of main patch. It should
behave the same way
2. Try to delete a basket with no records inside. You will only have a
"Delete basket" button, with fewer warnings
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently, when a basket is deleted, all the orders are deleted (there
is a foreign key in aqorders table on basketno).
This could be dangerous, and there is no warning.
After the deletion, unused biblios are left in the catalogue.
This patch
- adds a more detailed message describing the consequences of deletion
- give the choice of also deleting biblio records if possible
To test :
Test A :
1. create a basket with 4 orders:
- an order from a new record A
- an order from a record B which has already an item
- an order from a record C used in a subscription
- an order from a record D used in an other order
2. note the biblionumbers of the records used (or open them in other
tabs in your browser)
3. click on "Delete basket"
4. choose button "Delete basket and orders"
5. check the catalogue : records A,B,C,D should still be there
Test B:
1. create a basket with 4 orders:
- an order from a new record A
- an order from a record B which has already an item
- an order from a record C used in a subscription
- an order from a record D used in an other order
2. note the biblionumbers of the records used (or open them in other
tabs in your browser)
3. click on "Delete basket"
4. choose button "Delete basket, orders and records"
5. check the catalogue : records B,C,D should still be there. Record A
should be deleted
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch improves the sorting of staged import batches by date,
particularly when the dateformat system preference is set to anything
other than YYYY-MM-DD.
Adds title-string sorting type to enable this.
To test:
[1] Ensure that there are at least three staged
bib import batches, with upload timestamps such that
date sorting errors would be apparent.
[2] Set the dateformat system preference to either DD/MM/YYYY
or MM/DD/YYYY.
[3] Create a new basket in acquisitions, then chose to add
a new order line from a staged record batch.
[4] In the list of batches, click on the 'staged' column
heading to sort by date.
[5] Observe that dates are sorted in alphanumeric order, not date
order.
[6] Apply the patch and refresh. This time, dates should sort
correctly.
Signed-off-by: Fridolyn SOMERS <fridolyn.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
Search supplier and verify the basket group column is filled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works as described.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If items are created when ordering, this patch allows to add a value for
some items subfields.
Test plan:
Define status for items.notforloan (mapping 995$o in unimarc), for
example 4:On order, 5:On treatment
Set the Syspref AcqCreateItem on "ordering".
ACQ framework : set default value = 4 for 995$o (in unimarc)
Syspref AcqItemSetSubfieldsWhenReceived : set "o=5|b='foo bar'"
When ordering the item, default status will be 4 ; when receiving the
item, status will be changed from 4 to 5. The subfield b have to contain
'foo bar'
Signed-off-by: Frederic Durand <frederic.durand@unilim.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
- List of libraries in basket.pl is now sorted by branch name, not code
- When IndependantBranches is ON, user has only the possibility to set
basket branch to its own branch, or to no branch at all.
- When basket do not belong to any branch, selected branch by default is
connection branch (was 'no branch')
- added id attributes to both added li elements
- change description of 'order_manage_all' permission to make it
clearer.
- remove Test::MockModule dependency
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- Add branch info to baskets
- Add a list of borrowers that are allowed to manage a basket (one list
for each basket).
- Add a new subpermission: acquisition => order_manage_all
If user is superlibrarian, or if that user has permission acquisition = 1
(GranularPermissions = OFF), or subpermission acquisition =>
order_manage_all (GranularPermissions = ON), that user is authorised to manage
all baskets.
Depending on syspref AcqViewBaskets:
'all': user can manage all baskets
'branch': user can manage baskets of their branch (the basket branch is
taken into account, not the branch of the basket's creator).
If basket branch is not defined, all users can manage this
basket.
'user': user can manage baskets she created, and baskets in their
user list
There are unit tests in t/Acquisition/CanUserManageBasket.t, which
require Test::MockModule
You can edit basket's branch and users list in basket modification page
(acqui/basket.pl)
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- use Modern::Perl;
- GPL version
- tabs
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes QA script and all tests.
Testing notes:
- CSV header row is now translatable.
Tested by updating the German po files and checking for the line.
- Tested that claiming for late serial issues still works as
expected, as one file has been renamed. Filed 10931 for
untranslatable CSV contents.
- Tested that claiming late orders still works:
* Table searching and sorting
Works nicely, but some columns could be split up for better
searching and sorting:
* Order date: 20/01/2013 (245 days)
* Total cost: 10.00x1 = 10.00 Books
=> item type should be separate
* Basket: 10 MPL
=> Library and basket number could be separate columns
* Filters
* Combined various filters, search results look correct.
* Selecting order for claiming
* Limiting by vendor makes it possible to check/uncheck all
* With no vendor limit, entries for other vendors will be
locked after the first checkbox is checked for one vendor
* Exporting as CSV
* Exported single line > CSV appears correct.
* Exporting multiple lines > CSV appears correct.
PROBLEM: Translated CSV don't work correctly, as line
breaks are lost in the translation process.
Needs to be fixed in a follow-up.
* Sending serial claim email
* No regressions found - there are some problems with the
email contents noted on bug 7298.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Using a template file, the CSV headers become translatable.
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Fixes a few capitalization errors on the late orders page like
- Claim orders
- filter
- Search results
Also moves the supplierid from the order date column to the
vendor column.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch allows to export late orders as CSV.
Test plan:
- Go on the late orders page (acqui/lateorders.pl)
- Select one or more order and click on the button "Export as CSV".
- The generated file should contains some information on the orders
(order date, estimated delivery date, vendor name, information field,
cost, basket name (and basketid), claims count and the claimed date)
The last line of the file is the total of orders.
- You are not allow to select order from different vendor.
- The check/uncheck all links appears only if a vendor is selected.
- Check that the check/uncheck works for all pages of the table.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing comments on last patch in this series.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The first patch does a left join on aqorders_items which returns too
much order lines.
This patch follows the Galen's suggestion: it removes the join and calls
the GetItemnumbersFromOrder routine for retrieving itemnumbers.
Bonus: the "parcelitems" variable is badly named and obfuscates the code.
I changed it for "orders".
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds a column to indicate holds on received items, as well as adding
a new column for fund and showing the subtotals per fund above
the total subtotal.
To test:
[1] Create an order basket containing at least one title and
ensure that an item is created for that title. Close the
basket.
[2] Place a hold on the title.
[3] Receive the order. After receiving it, but before finishing
the invoice, the table of already received orders should now
have columns for the order budget and number of holds on the
title as well as lines with the subtotal per fund.
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2 DB fields are not used: aqbudgets.encumb and aqbudgets.expend.
This patch uses these fields in order to show a warning message if the
budget selected for an order has exceeded.
Test plan:
- Create a new active fund with at least 1 of both warning fields
('Warning at (%)' and 'Warning at (amount)').
- Create a new order for a basket with this new fund and a cost >
warning amount defined for the fund (or using %).
- Save and check that a warning message appears
- Retry playing with all combinations of warning fields
Signed-off-by: Koha Team Lyon 3 <koha@univ-lyon3.fr>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Since the parcel.pl script get *all* pending orders, there is no reason
not to display all of them.
Like that, DataTable manages pagination and sorting correctly (on all
data).
This patch adds filters on the table header (using columnFilter).
Test plan:
Try filters on the left of the screen and filters on the table header.
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Searching and sorting the table works correctly.
Larger result sets are a performance problem on this page,
I have filed bug 10595 for that.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
After receiving an order basket, before finishing receiving the shipment,
one has an option to cancel the receipt. This patch fixes a bug where
a basket whose receipt was just cancelled displays on both the pending orders
and already received tabs.
This patch also fixes a minor unitialized variable warning.
To test:
[1] Create a basket with at least one order and close it.
[2] Receive the order, then on the row in the 'Already received'
table, click the cancel receipt link.
[3] In the page that displays, the basket just cancelled displays
on both tables. Clicking the cancel receipt link again results
in an error message.
[4] Apply the patch.
[5] Repeat steps 1 and 2. This time, the cancelled basket displays
only in the pending orders table, as expected.
[6] Verify that after applying the patch, the following no longer
is logged in the Apache error log:
parcel.pl: Use of uninitialized value in string eq at acqui/parcel.pl line...
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Ed Veal <ed.veal@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes test plan, all tests and QA script.
Works as described.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- add a message if the search returns no result
- keep selected values if the search returns no result (for fund and
order status)
- remove plurals in order status
- move the order status column in the search results table
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
New tests also pass:
t/db_dependent/Acquisition/close_reopen_basket.t
1) Database update - I end up with too many partials. My test cases:
- New orders, basket still open
OK Expected: new, Result: partial
- Ordered orders, basket and basketgroup closed
OK Expected: ordered, Result: partial
- Partially received orders
OK Expected: partial/complete, Result: partial/complete
- Received orders
OK: Expected: complete, Result: complete
- Cancelled orders
* cancelled from open basket before order
OK: Expected: cancelled, Result: cancelled
* cancelled from closed basket before receive
OK: Expected: cancelled, Result: cancelled
All aqorders where updated with the correct status.
I have saved my 'pre-updatedatabase' and can repeat the test anytime you have a follow up.
2) Testing search functionality
a) Order search - result list
Order search shows a new column, I think it would be a bit better if the
status there was singular instead of plural - new order, partially received
order etc. - maybe we could even leave out the 'order'? (minor)
The column seems a bit lost in the middle, not sure where it would make more
sense (just saying)
b) Order search - advanced search form
The advanced search form now shows a new filter: Order status
All new status can be searched.
- an "empty" search will find all but cancelled orders
- searching for cancelled orders works correctly and shows results
Search works correctly, no regressions found.
If no result is found a message is shown.
All search input is kept, so you can modify your search terms easily.
3) Testing setting of status after applying the patch
a) Create a new order with 2 items - status is new. OK
b) Close the basket - status is ordered. OK
c) Receive both items - status is completed. OK
d) Undo receipt - status is ordered. OK
e) Receive only 1 item - order is split up into 2 orders:
- status is partial OK
- status is completed OK
f) Undo receipt of received item - order is combined into 1 again
- status is ordered OK!
g) Receive only 1 item again - status ordered/partial.
h) Delete order.
- status is completed
- status is cancelled
OK!
i) Undo receipt of 1 item again.
Refresh page.
This results in the following behaviour, that has been reported as
bug 10984. After refreshing the page follow message is shown:
Cannot cancel receipt. Possible reasons :
- The order line you trying to cancel was created from a partial
receipt of another order line which is already received.
Try to cancel this one first and retry.
- The order line you trying to cancel was created from a partial
receipt of another order line which has been deleted.
Cancellation is not possible.
BUT: The receipt is undone, but you are left with a
line with 2 items, a cancellation date and the status ordered.
Because of the cancellation date the order is not visible in pending orders.
The status is correct - so I feel this should not stop this patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
You can now search orders by
- order status
- fund
The patch series also adds a new field, aqorders.orderstatus, which can
contain following values:
new
ordered
partial (for partially received orders)
complete
cancelled
To test: Search and check if results are consistent in histsearch.pl
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on last patch.
Note: status are no longer numeric, but strings now.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
I have heard from several libraries that at the end of the budget
year even though a budget is inactive for new acquisitions, an
inactive budget should remain modifiable until the books are
closed and the budget is marked inactive. This patch makes it so
that all budgets that are unlocked are available on the order
receipt page (only).
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Right now there is no way to change the budget or fund when receiving an
item, which is annoying, particularly at the end of the fiscal year when
every item not already received has to be switched to the following
year's budget. This patch adds the ability to change the budget and fund
when receiving.
To test:
1) Apply patch.
2) Create an order for a vendor, choosing a fund to use for that order.
3) Receive the order, leaving the fund unchanged. Make sure the fund
did not change.
4) Create another order for a vendor, choosing a fund to use for that
order.
5) Receive the order, this time changing the fund. Make sure the fund
is changed.
6) Run the unit test:
> prove t/db_dependent/Acquisition.t
7) Sign off.
(Notes: this patch depends on the Acquisitions.t unit test improvements
in bug 10274; the seemingly-unrelated change in SQLHelper quiets an
irritating warning caused by the NewOrder call in ModReceiveOrder)
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Given how easy it is to accidentally receive items from one invoice on
multiple invoices, the ability to merge invoices can be quite handy.
This patch adds that ability to Koha's Acquisitions module.
To test:
1) Apply patch.
2) Run unit test:
> prove t/db_dependent/Acquisition/Invoices.t
3) Create two invoices from the same vendor for merging, and receive at
least one order on each.
4) Do a search on the Invoices page that brings up both the invoices you
created.
5) Check the boxes next to the two invoices.
6) Click "Merge selected invoices."
7) Choose which invoice you want to keep (the default will be the first).
8) Click "Merge."
9) Confirm that the resulting invoice has all the orders you received
listed on it.
10) Sign off.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Merged several invoices sucessfully - with and without received
orders, open and closed. Works nicely.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a new filter "basket group name" for pending orders
searches.
Test plan:
Try different filters and check that results are consistent.
Try to filter by basket group name.
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Applied on top of patches for bug 10723.
Passes all tests and QA script.
Note: It's a bit irritating that the basket name is not shown
in the list of pending orders, so there is no way to check the
results are correct without checking from another page.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In the C4::Acquisition module, 2 routines do the same work. This patch
merges these 2 routines.
Test plan:
test the acqui/orderreceive.pl, acqui/uncertainprice.pl
and serials/acqui-search-result.pl, acqui/parcel.pl scripts.
Note: on acqui/parcel the basket filter is a search on basket name (was
on basket id, which was not relevant).
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pm, no adverse bahaviors noted. All sub calls updated.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Koha::DateUtils::output_pref took 4 parameters and the last one is a
boolean, so some calls were:
output_pref($dt, undef, undef, 1)
This patch changes its prototype to
output_pref({
dt => $dt,
dateformat => $dateformat,
timeformat => $timeformat,
dateonly => $boolean
});
An alternative is to call the output_pref routine with a datetime
object, without using an hashref:
output_pref($dt);
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch introduces a new Z39.50 interface for searching Z39.50
compliant databases for MARC authority records.
These databases aren't as common as their bibliographic equivalents,
but they're out there and very useful. I have included info at the
bottom of this messsage for sample authority databases you can try.
To test this patch:
1) Set up Z39.50 client targets for authority databases. (I've included
information at the bottom of this message for LibrariesAustralia's
test server for authorities as well as instructions on how to use
your Koha's z39.50 authority server as well. The Library of Congress
also has authority databases available (unsure if these are test or
prod), and you might have access to others through OCLC or RLIN. OCLC
provides login credentials for their test databases.
2) Go to the Authorities module
3) Click on the new "Z39.50 search button"
4) Select your authority search targets from the list.
5) Do a search for an authority you would like using either the "Raw"
input box or the more specific input boxes for names, subjects, subject
sub divisions, or titles. (I like searching Name (personal): Eric on
the LibrariesAustralia test DB.)
6) You should see a table listing the server, heading, authority type,
and two other columns (MARC and a nameless column). "Authority type"
is the type of authority it will become when imported in to Koha. In
the Eric example, "PERSO_NAME".
7) Click on "MARC" next to the results of interest to review the MARC
authority record.
8) When you're satisfied with a record, click on "Import".
9) The pop-up window will close and your original Koha window will
change to the "Adding authority Personal Name" screen (in the Eric
example).
10) All the relevant fields should be filled out for the record. Review
them and make any changes as necessary. (N.B. The 001 will be cleared
when saved, so if you have a use for the imported control number, move
it to the 010, 016, or 035 as appropriate. If you have a default value
for the 003, this will also likely be overwritten. Move it if necessary.
The 005 will also be updated when saved, so do not worry about that.)
11) When you're satisfied, click save.
12) Presto! You've imported your first authority record via Z39.50!
--
Here is the info for the LibrariesAustralia test Z39.50 authority
database:
Z39.50 server: LibrariesAustralia Authorities
Hostname: z3950-test.librariesaustralia.nla.gov.au
Port: 210
Database: AuthTraining
Userid: ANLEZ
Password: z39.50
Syntax: MARC21/USMARC
Encoding: utf8
-
The U.S.A. Library of Congress also provides Z39.50 access to its Name
and Subject Authorities (http://www.loc.gov/z3950/lcserver.html).
Name Authority:
Z39.50 server: Library of Congress Name Authority File
Hostname: lx2.loc.gov
Port: 210
Database: NAF
Syntax: MARC21/USMARC
Encoding: utf8
Subject Authority:
Z39.50 server: Library of Congress Subject Authority File
Hostname: lx2.loc.gov
Port: 210
Database: SAF
Syntax: MARC21/USMARC
Encoding: utf8
(N.B. Both of these databases also include title authorities.)
-
For testing purposes, you can also set up a Z39.50 client target,
which points at your own Koha instance's Z39.50 authority server.
To find the hostname, go to /etc/koha-conf.xml and find the value for
the <listen id="authorityserver"> element. Depending on your
configuration, this could be something like the following:
unix:/zebra/koha/var/run/zebradb/authoritysocket
(N.B. You might be using a different scheme than unix sockets...)
To find the database, scroll down to the bottom of koha-conf.xml until
you reach the <config> element. Within this, look for the value of the
element <authorityserver>. It should probably be "authorities".
To set up this Z39.50 client target in Koha...
Z39.50 server: my koha authorities
Hostname: unix:/zebra/koha/var/run/zebradb/authoritysocket
Port:
Database: authorities
Userid:
Password:
Syntax: MARC21/USMARC (or whichever flavour you need)
Encoding: utf8
Signed-off-by: Mason James <mtj@kohaaloha.com>
Bug 10096 [FOLLOW-UP] - Add a z39.50 interface for authority searching
This patch adds the "recordtype" column to the "z3950servers" table.
The value in this column (biblio or authority) then controls whether
the z3950 server shows up in a bibliographic search (through the
Acq and Cataloguing modules) or in an authority search (through
the Authorities module).
I also edited the z3950 management console to show this value
and allow users to edit it. The default value is "biblio", since
the vast majority of z3950 targets will be bibliographic. However,
there is an option to add/edit a z3950 target as a source of
authority records.
Test Plan:
1) Apply both patches
2) Run updatedatabase.pl (after setting your KOHA_CONF and PERL5
environmental variables)
3) Use the test plan from the 1st patch
N.B. Make sure that your Z39.50 client target has a Record Type
of Authority, otherwise it won't display when you're doing a
Z3950 search for authorities.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Bug 10096 [FOLLOW-UP] - fix tabs/whitespace errors to pass QA
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No koha-qa errors.
Fixes problem, but I think is better to remove
=back than to add nother =over 4, but I'm not
a POD expert
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adapts the fund-handling code from neworderempty.pl
in order to limit the display of funds by default to active ones,
with the option to check a box to display all funds.
This patch also adds "(inactive)" to the display of funds on this and
the neworderempty.tt template because it seemed like that was useful
information.
To test, make sure you have both active and inactive funds.
Start the process of receiving a shipment. The "fund" option
in the receive shipment form should show only active funds.
Checking the "show all" checkbox should allow you to choose
from both active and inactive funds.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch introduces a DataTables sorting plugin, title-numeric,
for sorting cells based on a decimal number embedded in a span title
attribute. This allows currency amounts to be formatted properly
for display without having to writing a sorting plugin that's
super-smart about removing the formatting, particularly for locales
that use a comma as the decimal mark.
The sorter plugin can be used like this:
- In the DataTables config:
"aoColumns": [
{ "sType": "title-numeric" },
]
- In the table data
<td><span title="[% decimal_number_that_JS_parseFloat_accepts %]">
[% formatted currency %]
</span></td>
To test:
[1] Ensure that there is at least one active budget and at least
one inactive one.
[2] Go to the acquisitions home page. Note that changing the sort order
on the amount, ordered, spent, or avail columns results in incorrect
sorting that is either ASCII-betical or which ignores any component
of large numbers that occur after the thousands separator.
[3] Apply the patch.
[4] Verify that the sorting now works correctly and that no JavaScript
errors appear in the JS debug console of your choice.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Sorting now works correctly, for active and inactive funds.
Passes all tests and QA script.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch implements some of the suggestions made
by Owen Leonard and brings the form closer in line
with other popup forms. In particular:
- sets dimensions for the popup so that clicking on the
link is more likely to open a new browser window, not
a tab.
- ensures that the vendor search form is always visible
- adds a cancel link to make it more clear to library
staff that they can abort the process.
- tweaks markup to better match the patron guarantor
popup search form
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This allow to keep transfers informations without having untranslatable
strings in database.
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
On basket.pl and parcel.pl there is a 'Transfer' link which allow you to
transfer order lines from a basket to another.
The link leads to a new page which allow you to search for a bookseller,
then display this bookseller's baskets. Then you can pick a basket and
the transfer will be done.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds an "add to basket" link to the vendor search results
page for each open basket associated with each vendor. Clicking it
triggers a modal window with the "add to basket" choices for that vendor
and basket.
Other changes in this patch:
- The add-to-basket include has been modified in order to make it more
useful in this context.
- booksellers.pl has been modified to check for an existing budget so
that the add-to-basket include can properly display a warning if there
are none.
- "New basket" and "Receive shipment" buttons associated with each
vendor search result have been converted to Bootstrap-styled buttons.
- Basket closed date has been moved into its own column so that the
table can be sorted by that value.
- Table columns containing dates now use the "title-string" sort option,
eliminating the need for a special date sorting algorithm.
- Converted some &'s to &'s
To test, apply the patch and search for a vendor. For each vendor in
your search results baskets which are open should include an "add to
basket" link. Clicking it should open a modal dialog with the same "add
to basket" options offered on the basket page. The correct vendor ID and
basket number should be associated with each link.
The newly-styled "new basket" and "receive shipment" buttons should work
correctly. Table sorting should work correctly, including the new
"closed" column.
Since the add-to-basket include file was modified, the "add to basket"
button on the basket view page should also be tested (acqui/basket.pl).
Signed-off-by: Campbell Reid-Tait <campbellreidtait@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If you want to print a basketgroup with pdf format, it will be in
English. The pdf is done with layout2pages.pm or layout3pages.pm,
which call layout2pages.pdf or layout3pages.pdf.
This patch adds layout3pagesfr.pm in src/acqui/pdfformat/ which
calls layout3pagesfr.pdf.
And adds in basketgroup.pl the check for layout3pagesfr
To use it you have to change the systempreferences to pdfformat::layout3pagesfr
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described, koha-qa reports some tab errors.
Corrected in a followup.
Please, always add a test plan, it's easier to test.
Test:
1) apply the patch
2) change syspref OrderPdfFormat to pdfformat::layout3pagesfr
3) select a vendor
4) create a basket group (empty works)
5) close basket group
6) print basket group
7) PDF is in french
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works nicely, although it would be better if we could
find a more general solution to make the templates editable
and translatable.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If you have AcqWarnOnDuplicateInvoice set to warn it only warns if you have 2
or more invoices with the same number. It should warn if you're trying to
create a duplicate.
To test:
1) Turn on AcqWarnOnDuplicateInvoice.
2) Try to create an invoice that duplicates an invoice number you are already
using exactly once.
3) Note that you get a warning after applying this patch.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
all tests pass
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When syspref "UniqueItemFields" is defined, the item uniqueness is
tested in acquisition by an AJAX call to check_uniqueness.pl. This
patch fixes an issue where check_uniqueness.pl wasn't looking
at the correct CGI parameters.
Test plan :
- Select an existing item with barcode
- Add "barcode" to "UniqueItemFields" syspref (use space as separator
for multiple values)
- Set "AcqCreateItem" syspref to "Create an item when placing an order"
- Go to an acquisition basket
- Create a new order from empty
- Enter existing barcode in item form and save
=> You get an alert that barcode already exists and order is not saved
- Enter a non-existing barcode in item form and save
=> Order and item are created
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Refactors Z3950Search.
Disable batch record counts for z3950 records.
Test plan:
Do various Z3950 searches on multiple targets from Cataloging and Acquisition.
Behavior should not have changed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
C4::Booksellers::GetBooksellersWithLateOrders has an unused parameter.
The $branch variable is never used in the routine.
Test plan:
Check that no behavior changes on the late orders page.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I couldn't find any use of the branch parameter apart from
the one corrected by this patch. Also tested late orders,
couldn't find any problems.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Improve the code that displays and allows staff to
set the basket group from the basket details page
for a closed basket.
Prior to this patch, a staff member who did not
have the group_manage acquisition permission would
still see a control to change the group that the
basket belongs to; attempting to change the group
would present with with a login page.
This patch also does some tidying of how basket group
details are passed to the template.
To test:
[1] Create an order basket and close it. Do
not assign it to a basket group.
[2] View the basket details while logged in as
a staff user who has the order_manage acquisitions
permission but not the group_manage. The
displayed basket group should be "No group".
[3] Switch to a staff user who also has the
group_manage permission, then view the basket
details again. The basket group field should
now be a select input that allows you to change
the basket group.
[4] Change the basket group. Verify that the basket group
you selected is now displayed as the current group
for that order basket. The basket group delivery and
billing place fields should also now be displayed.
[5] Close the basket group set in the previous step, then
view the basket details again. This time, the basket
group name should be displayed with a suffix of " (closed)",
and no input to change the group should be displayed.
[6] Swith to a staff user who does not have the group_manage
permission, view the basket details, and verify that
the basket name is displayed with a suffix of " (closed)".
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Some vendors ship materials from the same invoice in multiple packages.
In those cases, it would be good to notify the librarian when they enter
a duplicate invoice number, so that they can continue receiving on the
previously-created invoice, rather than creating an invoice with a
duplicate number.
To test:
1) Apply patch and run database update.
2) Make sure that you have created at least one invoice on
acqui/parcels.pl and take note of the invoice number.
3) Try to create an invoice with the same invoice number.
4) Note that without changing your configuration this works exactly
the same as before.
5) Turn on the AcqWarnOnDuplicateInvoice system preference.
6) Try to create a new invoice with the same number as the one you
noted earlier.
7) Make sure you get a warning about a duplicate invoice.
8) Choose to receive on the existing invoice.
9) Confirm that you are receiving on said existing invoice.
10) Start the receiving process over, and this time choose "Create new
invoice anyway."
11) Confirm that you are now receiving on a new invoice.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
I have followed the test plan, but also checked some more things:
- Checking the duplicate check works when you have the entered
invoice number in your database multiple times already.
- Checking that no duplicate message is shown if you enter the
invoice number and it's already been used for an invoice from
another vendor.
Looks all good. I think the only thing we could argue about here
is if this could be activated by default for new installations.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
There is currently no way to delete unused invoices (for example,
invoices created by mistake), and there really should be, since errors
and absent-mindedness can result in numerous empty invoices over the
course of years.
To test:
1) Apply patch.
2) Create three invoices in the Acquisitions module. For one of them,
receive at least one item. For the other two, do not receive any
items.
3) View one of the invoices that does not have any items on it.
4) Try to delete it. This should succeed.
5) View the invoice that has an item. There should not be any option
to delete it.
6) Do an invoice search that brings up the other invoice with no items
on it. Try to delete it from the results page. This should succeed.
7) Run the unit test:
> prove t/Acquisition/Invoice.t
8) Sign off.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass. I also did another test:
I cancelled all receipts from an existing invoice and then could
successfully delete it in the last step.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes some things on the order receiving/parcel page.
1/ Removes dead code
2/ Displays an error message if invoiceid is unset or does not refer to an
invoice
3/ Fixes a bug in the note ("change note" and "add note" links)
Test plan:
1/ Try to call the invoice page with an existing invoiceid and check
that order results are consistent.
2/ Try without invoiceid or a bad invoiceid and check that an error
message is displayed.
3/ Add and change notes.
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely for all tests done.
- parcel.pl with invalid invoicenumber gives a nice error message
- parcel.pl with a valid invoicenumber looks normal
- changing and editing order notes works well
Passes QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The DB field aqorders.biblioitemnumber seems to be unused except to get
the itype on the spent.pl page.
This information can be retrieved uising another SQL join.
Test plan:
Try a complete workflow in the acquisition module: create an order,
receive it, play with the syspref AcqCreateItem.
Check that no regression is found and that the data for existing
orders don't change.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch offers an alternative option to fix Bug 9744. In this version
the table of funds swaps positions with the suggestions block so that
the table has the whole width of the screen. This eliminates the need to
adjust its float property.
Other changes:
- Simplification of the column and row-hiding JavaScript
- The addition of an "Active" column to be shown when all funds
are shown (this helps indicate to the user which rows were hidden)
- Linking the fund owner to their patron record
- Linking the fund id, given the correct permissions, to the view of all
funds for that budget (the best alternative to linking to a view of
the fund details, which we do not have).
- Correcting permission level required to add a budget
To test, view the acquisitions home page. The layout should feel
comfortable. The table of available funds should show the fund name.
The checkbox to show all funds should work correctly.
Signed-off-by: caroline very-mathieu <caroline.very-mathieu@nimes-ville.fr>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
- Remove an unnecessary loop where output just
recreated input.
- Remove unnecessary temp variables that obscure code purpose.
- Call the variable containing invoices, invoices
rather than anonymous and ambiguous results
reflect namechange in template.
- Lists are passed to template as array refs;
declare them as scalars as that is how we use them.
- No need to introduce the whole namespace of some C4
modules for 1 routine.
Test plan:
Note that this patch should not change any visible behavior.
[1] Open the invoice search page.
[2] Verify that the list of suppliers in the drop-down
on the search form is complete.
[3] Verify that the list of libraries in the drop-down
on the saerch form is complete.
[4] Perform a search. Verify that the list of invoices
is correct.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
With this followup, instead of passing the real names of the branches to template file, only the branchcodes are passed.
The branchcodes are translated into branchnames in template file, using the KohaBranchName template plugin.
To test :
do the same test as for main patch :
1) make some basketgroups with 0, 1, 2 baskets
2) make some basketgroups with different billing and deliveryplace
3) check the list of open and closed basketgroups
4) check action buttons are working like before
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Revised to fix whitespace problems. Cosmetic changes put in an other patch.
In the list of all the open/closed basketgroups for a vendor, you just
have the name of each basketgroup, and 3 action buttons.
It is not sufficient for libraries using basketgroup.
This patch adds the following columns :
- number (id of basketgroup)
- billingplace (name of the library)
- deliveryplace (name of the library, or "free delivery place")
- number of baskets in each basketgroup
To test :
1) make some basketgroups with 0, 1, 2 baskets
2) make some basketgroups with different billing and deliveryplace
3) check the list of open and closed basketgroups
4) check action buttons are working like before
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This is a nice improvement!
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Enable IndependantBranches
2) Apply this patch
3) Run updatedatabase.pl
4) Verify that the system preference still functions correctly
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
