Commit graph

628 commits

Author SHA1 Message Date
Galen Charlton
b91efb3b66 Bug 12111: (follow-up) ensure that vendor note is not editable during order receiving
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>
2014-04-28 15:37:43 +00:00
Julian Maurice
65748d05b5 Bug 11551: Allow to search on parent ordernumber in histsearch.pl
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>
2014-04-21 04:23:09 +00:00
Galen Charlton
9f3e1c4947 Bug 9416: (follow-up) teach ordering from staged files about the notes fields
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-19 16:05:17 +00:00
Galen Charlton
58b5b384f6 Bug 9416: (follow-up) reconcile with work done on bug 11699
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>
2014-04-19 15:55:38 +00:00
Mathieu Saby
138f14c2b9 Bug 9416: (follow-up) fix neworderempty and templates
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>
2014-04-19 15:55:37 +00:00
Mathieu Saby
36074fba65 Bug 9416: add new order vendor note field
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>
2014-04-19 15:55:36 +00:00
Jonathan Druart
36fc9a3e64 Bug 11699: change ModReceiveOrder to used named parameters
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>
2014-04-19 15:08:21 +00:00
Jonathan Druart
ab1a74897e Bug 11699: fixed saving notes entered when receiving orders
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>
2014-04-19 14:59:17 +00:00
Jacek Ablewicz
f3cb186de5 Bug 11680: (follow-up) fix unexpected tax rate changes on edit
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>
2014-04-18 22:14:21 +00:00
Jacek Ablewicz
471215dc46 Bug 11680: fix case where tax rate changes unexpectedly on editing an order
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>
2014-04-18 22:13:48 +00:00
Jacek Ablewicz
1b0c02376e Bug 11914: fix two issues when creating an order from a suggestion
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>
2014-04-18 21:59:14 +00:00
ae030272a4 Bug 7267: Add account number to German PDF template
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>
2014-04-11 15:06:07 +00:00
62151ced35 Bug 7267: Add account number to English PDF templates
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>
2014-04-11 15:05:55 +00:00
a4841aae08 Bug 7267: Add account number to French PDF template
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>
2014-04-11 15:05:42 +00:00
ffeb666994 Bug 11828: Add German translation of layout2pages PDF template
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>
2014-04-11 14:58:47 +00:00
21e6518d32 Bug 11366: make "no group" option in acq basket group drop-down translatable
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>
2014-03-13 14:43:01 +00:00
Galen Charlton
cd21ac7542 Bug 11820: remove dead code in basket group management
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>
2014-03-12 14:27:39 +00:00
Jonathan Druart
fe520d5b14 Bug 11170: make the pending order list only display orders to receive
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>
2014-03-11 15:09:56 +00:00
daf2ebc4f5 Bug 11096: support the retrieval of large MARCXML records
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>
2014-02-28 19:50:09 +00:00
Jonathan Druart
7a2dec05ed Bug 11471: Display the currency for baskets in a basketgroup
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>
2014-02-21 19:41:07 +00:00
Jonathan Druart
8b685c1e80 Bug 9823: Refactor return from GetReservesFromBiblionumber
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>
2014-01-30 16:19:55 +00:00
Jonathan Druart
795421a643 Bug 11141: retain pending order filters during receiving.
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>
2014-01-23 16:03:49 +00:00
Mathieu Saby
59c0a0e02b Bug 11056: Delete dead code in basketgroup.pl
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>
2014-01-17 21:17:58 +00:00
Jonathan Druart
4bd730d4c2 Bug 11018: allow adding order from a reverted MARC batch
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>
2014-01-17 05:32:42 +00:00
Samuel Crosby
d4daf32d1d Bug 9654: add space between amount and currency symbol in basket group display
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>
2014-01-02 15:46:42 +00:00
fb4025b67b Bug 10277 - Add C4::Context->IsSuperLibrarian()
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>
2013-12-30 15:47:23 +00:00
Jacek Ablewicz
95e2754af6 Bug 9948: fix creation/updating of items when partially receiving an order
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>
2013-12-23 16:02:32 +00:00
Galen Charlton
231f26b248 Bug 9807: (follow-up) quell warning if invoice price not set
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-12-17 17:40:31 +00:00
Mathieu Saby
fc250be538 Bug 9807 : Make it possible to view a basket group without reopening it
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>
2013-12-17 17:35:12 +00:00
Jacek Ablewicz
6dcc34c1b4 Bug 9224: Make acqui/finishreceive.pl Plack-compatible
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>
2013-12-13 18:23:26 +00:00
Mathieu Saby
de2bfb6799 Bug 7791: (follow-up) add warning after deletion if some records were not deleted
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>
2013-12-02 16:17:18 +00:00
Mathieu Saby
2c307f3e92 Bug 7791: (follow-up) tidy up some cruft in the main patch
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>
2013-12-02 16:07:28 +00:00
Mathieu Saby
09953f836d Bug 7791: add ability to delete records when deleting a basket
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>
2013-12-02 16:05:33 +00:00
Lyon3 Team
097a92b318 Bug 11059: fix date sorting of import batches in basket add form
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>
2013-12-02 15:41:46 +00:00
Jonathan Druart
c9b873ff10 Bug 11171: Display basket group name on the supplier list page
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>
2013-11-27 18:02:21 +00:00
0d24afb92c Bug 8307: QA Followup for finishreceive.pl
Only split the expression a=b on the first = sign.
Tested with the very unlikely z=x=1 :)

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
2013-10-31 23:37:04 +00:00
Jonathan Druart
4b36244c73 Bug 8307: Set a value for subfields when receiving
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>
2013-10-31 23:36:59 +00:00
Julian Maurice
fe777ef937 Bug 7295: (follow-up) several fixes
- 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>
2013-10-31 16:37:08 +00:00
Julian Maurice
54616c37e2 Bug 7295: More granular permissions for baskets
- 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>
2013-10-31 16:35:35 +00:00
Galen Charlton
9706908b26 Bug 7298: (follow-up) fix uninitialized variable warning
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-31 15:52:47 +00:00
Jonathan Druart
43adbda007 Bug 7298: (follow-up) various QA fixes
- 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>
2013-10-31 15:51:25 +00:00
Jonathan Druart
58111f8ece Bug 7298: (follow-up) make CSV strings translatables.
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>
2013-10-31 15:50:58 +00:00
Katrin Fischer
92aa1246e2 Bug 7298: (follow-up) fix capitalization and moving supplier id
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>
2013-10-31 15:50:08 +00:00
Jonathan Druart
fd2c751a86 Bug 7298: add option to export late orders as CSV
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>
2013-10-31 15:49:24 +00:00
Jonathan Druart
380bfcedd5 Bug 8037: (follow-up) bad sql query and variable renaming
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>
2013-10-31 14:53:17 +00:00
3910d5e8b4 Bug 8037: Display holds & fund on the already received table on order receipt summary
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>
2013-10-31 14:53:07 +00:00
Jonathan Druart
ea3b5aad21 Bug 9822: Alert on adding an order to a basket if budget s exceeded
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>
2013-10-30 15:10:11 +00:00
Jonathan Druart
5d7aa7e435 Bug 10725: Add filters on the pending orders table
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>
2013-10-30 05:10:11 +00:00
Galen Charlton
0010c27ea1 Bug 11108: fix duplicate display of basket whose receipt has just been cancelled
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>
2013-10-28 15:06:20 +00:00
Jonathan Druart
489d480042 Bug 5336: (follow-up) multiple QA fixes
- 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>
2013-10-22 13:30:34 +00:00