When an already received order line is modified/edited,
we experience data loss. Most prominently, we will lose the
linked invoiceid. Therefore we should not allow editing an
order line that was already received. If something needs to be
changed, the receipt should be cancelled first.
To test:
* Create basket as standing order with items added in cataloguing
* Add an order line
* Receive shipment
* Go to the basket summary page, click on 'Modify'
* Change the actual cost
* Save
* Verify that the invoice is now empty
* In the database aqorders.invoiceid will be NULL
* Apply patch
* Receive another shipment for the standing order
* Go back to basket summary page
* Verify the 'Modify' link is no longer present
* Click 'Modify' on the unreceived order line
* Edit the URL parameter odernumber to have the number of an
already received order line
* Verify you see a nice error message:
This order cannot be edited, the basket is closed or the order was already received.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit a4b7490633)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The js that buils the new row after editing expects to receive a
value '_checked' indicating if theitem was selected. The 'item' variable
used to create the row after edit comes from the api and doesn't include this.
We need to inspect the previous html before building the new row to confirm the box wa checked
To test:
1 - Create a basket with 'items created on receive'
2 - Add an order line with multiple items to it
3 - Close basket
4 - Receive shipment
5 - Add invoice information
6 - Receive through receive link in the table
7 - Check some items
8 - Click on the "Edit" link and make some change to the item
9 - Save
10 - Checkboxes have disappeared
11 - Cancel receipt
12 - Apply patch
13 - Reload the page
14 - Repeat 7-9
15 - Checkbox is preserved
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 27cf76b484)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch fixed 2 small and recent regressions:
* The "Update adjustments" button used to always display. It's
required to save a new first adjustment, but also to save
changes to existing adjustments edited inline. It now would
only display after "Add adjustments" was clicked. We retore
to display it always. (bug 32746)
* We have several "Fund" pull downs on this page, but they are
for different things and require different labelling.
"Fund" was changed to "Shipping fund" which matches at the top,
but doesn't work for the adjustments table and single adjustment
form. Now we use "Shipping fund" "Fund" and no label in the table
as the table header covers it there. (bug 33721)
To test.
* Add a vendor
* Receive shipment
* Add invoice and save
* Click on "Finish receiving"
* Verify the button "Update adjustments" appears after clicking
"Add new adjustment"
* Verify the button is gone after you clicked it and the table shows
* Change something in the table - no button to save change :(
* Apply patch
* Repeat steps, button "Update adjustments" should not always be
visible.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 72ef65edbe)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Removes the unneded new form element as we have one big form for the whole page.
This should fix the situation where only the prices and information
of the first selected record carreid over into the order.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 71377c5e7b)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This is a first step towards more consistency and possibly supporting
multiple input formats as well in the future. It marks all input fields
for monetary values, such as prices, replacement prices etc. with a class
that is linked to a check for number format with the jQuery Validator plugin.
To test:
For any input field to test, try adding various false entries, like "abc" or "1,00".
It should only accept inputs with decimal dot, like: "1.00"
0) Apply patch, restart_all
1) Suggestion
* Add a new suggestion in the staff interface
* Test: price input field at the bottom of the form.
* Accept the suggestion
2) Order form
* Create a new basket
* Create an order line from an existing record
* Test: list price, replacement price, and actual price.
* Check the checkbox for uncertain price before you save
3) Uncertain prices
* Go to the uncertain prices page for this vendor
* Test: price field
Note: this form does its own validation, but the change should not change behaviour for now
* Resolve the uncertain price
* Close order
4) Receive shipment
* Test: Shipping cost
5) Receive the order
* Test: replacement price, actual price
* Check checkbox for price in foreign currency
* Test: price in foreign currency
* Receive order line
6) Invoice summary
* Finish receiving
* Test: shipping cost
* Test: invoice adjustments: amount in the form for the first entry, amount in the table after adding it
7) Merging invoices
* Receive another shipment and create and invoice
* Go to invoices and search all
* Check the 2 entries for merging
* Test: shipping cost
8) Adding orders from a staged/new file
* Export some records using the cart or list
* Create a new basket
* Order from new file
* Import your file, ignore item records
* Test: price and replacement price
+ Bonus: also test with items, test plan and file from bug 22802 are really helpful here
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit c943fddac6)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We are not saving the values of the input but a representation of the
form, contains in $("#order_edit").data('row');
To acchieve that it's preferable to reuse _update_unitprice and call it
when #change_currency is modified.
Some code cleaning slipped into the patch, for readability purpose.
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit e3a7202363)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 768702be7a)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We should not check "Change currency" if it has not modified in the
original order.
Test plan:
Create an order with 3+ items
Receive 1 item, don't check "change currency"
Receive an other item
=> "Change currency" is not checked
Check "Change currency", modify the currency and the price
Receive a third item
=> Change currency is checked, invoice currency and price are set
correctly to the previous values
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 140bad214c)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It was not consistent: indentation, bold, etc.
This patch is suggesting a new style using .page-section and .rows
Is it what we want?
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 4bd6abf9a2)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 5be54fc9e6)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When creating items at receiving, the generated data structure didn't
match what the code expected, so this patch adapts the code to match the
new data structure introduced by bug 8179.
Once I fixed that, I noticed that the $.ajax request payload, when it
contains an array parameter, it renames it like `param[]`. So the
finishreceive.pl controller is adjusted to this behaviour for the 'on
receiving' use case.
To test:
1. Apply this patch
2. Create a basket with 'create items on receive'
3. Create an order line
4. Close basket
5. Receive shipment
6. Enter invoice number
7. Click on Receive link in the table
8. Fill out item form, make sure all mandatory fields are set
9. Save
10. Verify that the order line is marked as 'received'
11. Verify that there item is created on the record
=> SUCCESS: Works as expected
12. Sign off :-D
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit a40c512bf0)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
JS error in the console was
Uncaught TypeError: row.creator is null
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 30d2ffd295)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch attempts to fix a UI issue on addorderiso2709.tt. It removes the <td> which contains the actoin buttons MARC, Card, and Add Order and adds them to the title line. This is so there is more space for the fieldsets.
1. Apply patch
2. Set MarcItemFieldsToOrder like this:
homebranch: 975$a
holdingbranch: 975$b
itype: 975$y
nonpublic_note: 975$x
public_note: 975$z
loc: 975$c
ccode: 975$8
notforloan: 975$7
quantity: 975$q
price: 975$g
replacementprice: 975$v
uri: 975$u
3. Stage a MARC file where the bibs have items attached
4. From acquisitions create a new basket and add 'From a staged file'.
5. Add the staged files to a basket.
6. Make sure the display looks correct.
7. Expand the data by clicking on the checkbox on the left hand side, or by clicking 'Select all'.
8. Make sure the display looks correct.
9. Tab over to 'Item informtion' and make sure that display looks correct.
10. Shrink the screen size down to less that 992px, ensuring the display remains correct.
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch corrects the behavior of the 'Confirm' button on the three
possible scenarios regarding item creation.
Ordering:
- 'Confirm' disabled, only gets enabled if quantity > 0
Receiving:
- Quantity gets locked (only changeable when creating items)
- 'Confirm' disabled, only gets enabled if quantity > 0
Cataloguing:
- It now defaults to 1
- 'Confirm' enabled by default (because of 1) if quantity is set to 0,
it gets disabled.
To test:
1. Verify the described behavior with the sample orders for the previous
patch.
=> SUCCESS: It does the job!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On b0aab2aeef the flatpickr default to
'today' was restored, but only for acqcreateitem='ordering'. This patch
moves the initialization to a different stop for broader reach.
To test:
1. Have 3 baskets on with each setting:
- create_item = 'cateloguing'
- create_item = 'ordering'
- create_item = 'receiving'
2. Close those baskets
3. Go to 'Receive shipments'
4. Choose things from the 3 baskets and then 'Receive selected'
5. Navigate through the different orders
=> FAIL: Only the one that has items created on ordering has the date
filled by default
6. Apply this patch
7. Reload the page
8. Repeat 5
=> SUCCESS: Dates are pre-filled!
9. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The original patch makes the form set the right values in the order row
(before storing it) but misses to load the right value on page load,
which is still a regression. This patch solves that.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This restores behavior prior to 8179 to use the estimated cost when receiving if the
actual cost is not set.
We set the unitprice in the table row so that it will be used when editing and will be saved even if not adjusted
To test:
1 - Add some orders to a basket, do not set actual cost field
2 - Close basket, receive orders
3 - Note actual cost field is blank
4 - Cancel receipt
5 - Apply patch
6 - Receive again
7 - Note actual cost is populated
8 - Complete receipt and confirm actual cost correctly saved
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes dismissing the modal equivalent to cancelling the
receipt and thus returning to parcel.pl.
The 'Save' button is renamed to 'Confirm' and is disabled when no items
are selected for receiving.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
With bug 8179, a new step was added when receiving a single item.
This extra step is not useful and adds clicks for the staff member who is receiving orders.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch
2. Follow the steps in Bug 8179 to generate the modal on orderreceive.tt
3. Check that the following issues have been corrected:
-The select2 dropdown for #bookfund is splitting onto multiple lines in the modal.
-The modal header has a green line extending through it.
-At smaller screen sizes the modal close button ( upper right corner of modal ) drops down below the h4. It should stay on the same line as the h4.
-The modal is not centered on the screen.
-The toogle inactive/active checkbox can become it's own list element.
-The #current-fund can become a hint
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch reintroduces the dropdown that got lost in some refactoring
of the patchset. It also introduces a couple minor fixes.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch fixed the following on orderreceive.tt:
-One of the <th> is closed with a </td>
-The #jobpanel element div is not properly closed
-Style tags are in the HTML body and they should be in the HTML head
-The #modal-order-main needs a class of 'row', this has been added.
Apply the pacth and follow the steps in 8179 until you get to the orderreceive.tt. There should be no visual changes but the markup has been corrected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When viewing an invoice, the elements in the 'Fund' line were out of order:
'Fund:' label, followed by 'Show inactive:' label, then the fund drop-down and then the show inactive checkbox.
The order should be:
'Fund:' label, fund drop-down, 'Show inactive:' label, show inactive checkbox.
This copies the markup that is used when you click on "Receive shipment".
It also changes 'Fund' to 'Shipping fund' to bring the forms even more in line.
To recreate:
1. In acquisitions, create an order and close the basket
2. Click 'Receive shipment' and receive the order
3. Click 'Finish receiving'
--> The Fund line in invoice.tt is out of order
4. Apply patch
5. Verify the order is now fixed
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds the document type (suggestions.itemtype) to the list
of accepted suggestions when creating an order from a suggestion.
To test:
* Add some suggestions and make sure to pick different document types.
* Accept those suggestions in the staff interface.
* Go to acquisitions
* Create a basket
* Add an 'order from a suggestion'
* Verify that the list shows the 'document type' nicely and correctly
* Order one, all good? sign off.
Signed-off-by: Juliet <jheltibridle@rcplib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Removed IS_OPAC param from AuthorisedValues.GetByCode
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch allows to create additional fields for order lines.
Once created, these fields can be filled during order line creation or
modification.
If additional field is linked to a MARC field, there are two possible
scenario:
- MARC field mode = get: The field cannot be modified and its value is
retrieved from the bibliographic record (current behaviour)
- MARC field mode = set: The field can be modified and its value is
saved to the bibliographic record (new behaviour)
If additional field is linked to an authorised value category, then
authorised values are used. If not directly linked to an authorised
value category, but linked to a MARC field, a search for an AV category
is made on MARC default framework.
This patch doesn't display additional fields value anywhere (except in
order line creation/modification). Future patches will do that.
Test plan:
1/ Go to Acquisitions home
2/ In the left menu, click on "Add order line fields"
3/ Click on "New field" button
4/ Give the field a name (unique), no AV category and no MARC field.
5/ Save.
6/ Create 5 other fields:
a/ no AV category, a MARC field not linked to AV category, MARC field
mode = get
b/ no AV category, a MARC field not linked to AV category, MARC field
mode = set
c/ no AV category, a MARC field linked to AV category, MARC field
mode = get
d/ no AV category, a MARC field linked to AV category, MARC field
mode = set
e/ an AV category, no MARC field
7/ Create everything you need to be able to create order lines
(supplier, basket, ...)
8/ Create an order line. At bottom of the page, you should see your
additional fields, with authorised values dropdrown list for fields
(c), (d) and (e). Fields (a) and (c) should be disabled.
9/ Fill these fields with some data and save order line
10/ check that data was correctly saved into biblio for fields (b) and
(d), but not for (a) and (c)
11/ modify the same order line, check that values you've filled are
correctly retrieved and that values for (a) and (c) were correctly
retrieved from the bibliographic record
12/ modify all values, save, and check biblio once again
Signed-off-by: Harold Dramer <harold.dramer@nyls.edu>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch implements the code to allow a patron to receive multiple
orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page
To test:
1. apply all patches
2. updatedatabase
3. Go to system preferences and allow AcqReceiveMultipleOrderLines
4. In acquisitions module, create a vendor if you don't have one and add
3 baskets.. one with create items on ordering, one with create items
on receiving and finally one with create items when cataloguing
5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods.
6. Close all baskets and receive shipment.
CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected"
7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page
8. Check some of the checkboxes
CHECK => "Receive selected" button shows how many rows are selected
9. Go to the next page and select some more rows
CHECK => Changing page does not modify how many rows where selected
10. Go back to previous page
CHECK => Previously selected rows are still selected
11. Reload the page to deselect all rows
12. Select only one row and click on "Receive selected" button
CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked.
13. Click on cancel to go back to parcel.pl page
14. Select all rows (even the ones from the next page of the table) and
click on "Receive selected"
CHECH => In orderreceive.pl page there is a table with all selected rows
15. Ensure table has more than one page, as in step 7
16. Click on the "edit" link in the last row of the current page
CHECK => A modal window is displayed with 4 tabs within: Info,
Accounting, Receipt history and Items
CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos
order, 'Cancel' to close the modal without keeping modifications, 'Save'
to close modal keeping modifications and 'Next' to go to the next order
CHECK => Even that we are at the end of the current page, 'Next' button
is still available
17. Click on 'Next' button
CHECK => The table behind the modal now displays the next page, and the modal was not closed
18. Click on 'Previous'
CHECK => The table behind the modal went back to the first page, and the modal was not closed
19. Click on 'Previous' button till you reach the first row of the first
page
CHECK => Only when you reach the first row of the first page 'Previous'
button gets disabled
20. Click on 'Next' button till you reach the last row of the last page
CHECK => Only when you reach the last button of the last page 'Next'
button gets disabled
21. Check that behaviour for the different types of order are still the
same
a. For orders that where created through suggestion, check that the
suggestion info is present in Info tab. If when suggestion was accepted
you set a reason, a dropdown to change the reason shoul display also.
b. For orders that where created through subscriptions, check that
the Items tab is disabled, and the Receipt history is enabled. On
accounting tab you should be able to change quantity ordered. If there
were less items received than ordered, the next time you receive this
order the child order generated from this one shoul appear in receipt
history.
c. For orders that don't come from subscription and creates there items on ordering, Receipt history
should be disabled, and a table with prefilled items shold appear in the
Items tab. You can edit them and the changes should appear in the item's
row.
d. For orders that don't come from subscription and creates there
items on receiving, Receipt history should be disabled, and a form to
create the items should appear in Items tab. When you add an item a
table should appear.
e. For orders that don't come from subscription and creates there
ites on cataloguing, Receipt history and Items tabs should be disabled.
f. Any changes made in quantity (received or ordered) or funds in the modal should be
reflected in the table if you click save from the modal.
22. Once you've done all you checking and verifications click save
23. While saving a progress bar should appear
24. If no error was detected, you should be redirected back to parcel.pl
page
25. If an error or warning was detected (like there is an order with 0
items to receive) the save button should be disabled and warnings
are dispayed.
26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
Sponsored-by: Virginia Polytechnic Institute and State University
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an id to z39.50 search interface submit buttons so that
the JavaScript event for changing the cursor can be linked to that
instead of the obsolete class.
The patch also adds code copied from Bug 33233 in order to make the
"waiting" cursor revert to the default if the user uses the back button
to return to the search form.
To test, apply the patch and go to Cataloging -> New from Z39.50
- Fill in a search term and click the submit button
- Your cursor should change to a "waiting" cursor while the search is
performed, before you're redirected to the results.
- From the results page, clicking the back button (or right-clicking the
page and choosing "Back") should return you to the search form and
your cursor should be a standard pointer.
Perform the same test from:
- Acquisitions -> Vendor -> Basket -> Add to basket -> From an external
source
- Authorities -> New from Z39.50/SRU
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We could then reuse it for the contacts code in this same template, on
another bug report.
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patchset is adding the ability to create interfaces for vendors.
An interface is a website, software, or portal that you use to manage orders or
gather statistics from the vendor/organisation.
It will help librarians to keep track of those different information
within Koha.
* new DB table aqbookseller_interfaces(id, vendor_id, type, name, uri,
login, password, account_email, notes)
* new AV category VENDOR_INTERFACE_TYPE with 3 example values ADMIN,
ORDERS, REPORTS
* new pair of Koha classes Koha::Acquisition::Bookseller::Interface[s]
* new method to retrieve the interfaces from the vendor
Koha::Acquisition::Bookseller->interfaces
* Add/Delete interfaces when editing a vendor
* Display the interfaces on the vendor show view
Test plan:
- Add a new vendor
=> Notice the new "Interfaces" block
- Create some interfaces
=> They are display on the vendor show view
=> The password is hashed and can displayed on the demand
QA Note:
The "contacts" code is not very nice and I didn't want to replicate it,
so I went another way and tried to make the code reusable, for further
reutilisation.
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run git grep "specifique key"
Run git grep "the fonction"
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Do not apply the patch yet
2. Make sure you have an ACQ biblio framework with some framework
plugins enabled. Create it if you don't.
3. Enable UseACQFrameworkForBiblioRecords system preference
4. Create a new acquisition basket.
5. On this new basket, click on "+ Add to basket", then "From a new
(empty) record"
6. You should see a simplified MARC editor based on ACQ framework.
Confirm that the plugins are not enabled (no visible buttons, nothing
happening on focus/blur)
7. Apply patch
8. Repeat step 5
9. You should now see the plugins' buttons (only if you enabled plugins
that use the 'click' event)
10. Confirm that the enabled plugins work correctly
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
