After editing an item on receiving, 'null' is displayed if no value is
defined for a field. It should be blank.
Test plan:
0/ Set AcqCreateItem to 'ordering'
1/ Go on the receipt page page
2/ Edit an item
3/ Does not fill all values
4/ Confirm that undefined values are replaced with an empty string
NOTE: I think you meant receive. Editing requires at least clicking
the dropdown value, even if you don't change it before
clicking save. null's appeared. Post patch application was
able to get nulls to disappear. :)
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To make Koha easier to use, we should use terms consistently.
This patch fixes some occurrences of 'stock number' to be
'inventory number' as this is also the term used in the frameworks.
Item search, accessible via the link from staff's advanced search
1) Do a search for items, but choose CSV as output
2) Verify that the header row says 'inventory number'
Acquisition
3) Set AcqCreateItem to 'order'
4) Create a new order, check the labels on the item table in the order
5) Receive the order, check the labels on the item table on receive
6) Set AcqCreateItem to 'receive'
7) Check the item table on receiving an order
Followed test plan (including item search with JavaScipt disabled). Headers / labels display as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12111 removes the vendor note edition on receiving.
The label should not be displayed when it's empty.
Test plan:
1/ Receive an order without a vendor note and verify that the label is not
displayed.
2/ Receive an order with a vendor note and verify that the note is
displayed.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, small template change.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.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>
This bug changes some lines in modordernotes.tt to make them more easily
translatable, especially in german (remark by K. Fisher on bug 9416).
No change should be visible
It also suppresses the ability to edit order "vendor note" in reception,
as the note for vendor is not made to be changed after the document is
received.
Test plan :
- in a basket, try to edit the notes (internal and vendor) of order.
Check the display is correct
- go in reception module (parcel.pl page) : in the list of all orders
to receive, you should have a link to change "internal note", but no
more link to change "vendor note"
- try to receive a specific order which have a "vendor note". On the
right panel of the page, you must have an editable textarea for
internal note, and a non-editable (colored in grey) textarea for
vendor note
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently translating Javascript strings with variables in them is hard,
because the strings are created from separate parts. For example:
_("Are you sure you want to delete the") + " " + count + " " +
_("attached items?")
This is translated in two different parts, and the translator cannot
affect the place where the count-variable is.
Now, if the javascript strings allowed placeholders, similar to how the
template strings do, the above could be written as:
_("Are you sure you want to delete the %s attached
items?").format(count)
This would make translation much easier.
Attached patch adds a Javascript string formatter, and changes all the
concatenated translatable JS strings used in intranet to use that.
To test:
1) cd misc/translator
2) perl translate update xx-YY
3) grep ^msgid po/xx-YY-i-staff-t-prog-v-3006000.po | sort | uniq >
xx-YY-pre
4) apply patch
5) perl translate update xx-YY
6) grep ^msgid po/xx-YY-i-staff-t-prog-v-3006000.po | sort | uniq >
xx-YY-post
7) compare the files: diff -Nurd xx-YY-pre xx-yy-post | less
should show the javascript strings that changed.
8) Test the UIs where the formatted js strings are used.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I tested *most* of the changed files. There were some instances where it
wasn't clear to me how to trigger the warnings which were modified,
especially tags/review.tt, admin/manage-marc-import.tt, and holidays.tt.
Everything I was able to test worked correctly.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely, no regressions found. Thx!
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>
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>
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>
Use of CheckMandatorySubfields from cataloging.js
everywhere an item cataloging form is checked for
mandatory fields.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
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 refactors some code in a js file.
Test plan:
On acqui/neworderempty.pl, acqui/orderreceive.pl and
serials/serials-edit.tt try to scan a barcode (or press enter) on the
form and check that it is not sent.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Have to note that the code for IE9 does not work. Before and after this patch.
If we refactor code, it would have been nice to resolve this too.
But I do not oppose pushing this patch.
The test uses 'an ancient Netscape property' window.Event (uppercase!) to make
the distinction between browers and event models. Some more documentation here
would be welcome too.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
For subscriptions, if items are created when receiving, the quantity
received is always 1, not 0.
+ UI: Show the subscription search form (instead of hidden)
Signed-off-by: Leila Arkab <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
DB changements:
- Adds 2 fields: subscription.reneweddate and aqorders.subscriptionid.
- Removes 2 unused fields: aqorders.serialid and aqorders.subscription.
Main test plan:
1) Create a subscription
2) Create a bookseller and a basket
3) Add a new order 'from a subscription'
4) Search your subscription and check if results are correct
5) Click on the "order" link
6) Check the biblio information are filled in the form
7) Select a budget and fill some price information.
8) retry steps 3 and 4. Verify you cannot order the same subscription.
Message:Outstanding order (only one order per subscription is allowed).
9) click on your subscription (already added) and check you have a new
table "Acquisition details" with your price information in the "Ordered
amount" line.
10) receive this order
11) On your subscription detail page, the "Spent amount" line must be
filled with your price information.
12) Re order the same subscription. Now you are allowed to. Prices
information have to be filled with the previous information.
13) Retry some orders and click on a maximum of links in order to find a
bug :)
Signed-off-by: Leila Arkab <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on last patch.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test plan:
- launch the test xt/single_quotes.t, there are 3 occurrences
- apply this patch
- launch the test. It will pass with success
- Check that there is no regression on the 2 modified intranet files and
the calendar still works at the OPAC.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests pass, also checked calendar still works.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I tested most scripts affected by this patch and visually verified
all changes. Functionality is unaffected.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This is an alternative to the original implementation - this one works in chrome as well as firefox.
To test:
1)
Set syspref 'AcqCreateItem' to 'Create Item when receiving an order.'
2)
Create a basket for a vendor, add an order line.
3)
Search for this vendor using Vendor search
4)
Receive Shipment for this vendor and choose the title you ordered in 2)
5) You will get the dialog to create related item(s)
6)
Fill in Item 0 through o (see screenshot)
7)
Scan Barcode for field p - Barcode
7)
Result: Scanner sends a [return], form closes and you had no chance to fill in fields t - z
Signed-off-by: Marc Veron <veron@veron.ch>
Tested with Chrome Version 23.0.1271.97 m and Firefox 17.0.1, both behave as expected.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested with Firefox and Chromium in Ubuntu.
Additional test done:
1) Add a new subscription, choose 'receive adds items'
2) Receive an issue, fill out $p with a barcode
3) Make sure hitting enter in the barcode field does not send the form.
All tests pass and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
If there is no errors, it should continue instead of returning true.
+ move a block of code at the end of Check function. This avoid
detaching and re-attaching a HTML block if there are errors.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
The following queries show us the issues:
select count(*) from items;
select * from aqorders_items where ordernumber=XX;
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
To test:
AcqCreateItem = receive
UniqueItemFields = barcode
1) Create a new basket
2) Create a new order with quantity > 1
3) Close the basket and create a new invoice/shipment
4) Receive only 1 item.
- Fill out the first item form with item type only. Click add.
- Don't change second item form at all.
- Click save.
Before patch:
2 items are created on the record, both with the selected itemtype.
After patch:
Only 1 item is created, which is correct.
Signed-off-by: Elliott Davis <elliott@bywatersolions.com>
Seems to work as described by the test plan
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patch removes a lot of code from acquisitions. I tested 2 complete
acquisition workflows from ordering the item to receiving it, with
AcqCreateItem set to 'on order' and to 'on receive'. Both worked
without any visible changes after applying the patch.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch corrects new and old instances of the use of the
term "branch" and replaces them with "library."
Signed-off-by: Melia Meggs <melia@test.bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests pass, changes look good.
Also inlcudes some bookseller > vendor changes.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
this patch prevents a scan machine to send 'enter' to the form when it is not expected.
The patch is on orderreceive.tt and serials-edit.tt.
Written by Alex Arnaud. MT6626.
Signed-off-by: Marc Veron <veron@veron.ch>
Tested with receiving orders and receiving serials. Could reporduce problem befor applying the patch. After applying the patch both forms behaved as expected.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Checked order receive and serials edit page, barcode + enter does
no longer submit the form.
All tests pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Larry Baerveldt <larry@bywatersolutions.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
- New pages:
- invoices.pl: allow to search in invoices on several criteria
- invoice.pl: permit to view and modify invoice details
- shipment date
- billing date
- shipment cost and budget used for shipment cost
Invoice informations are now stored in their own sql table and aqorders
have a link to it
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Just add a check in Jscript when the form is submited, the same as in additem.tt
On Owen's suggestion I have added the red color and 'Required', the same as in additem.
On Jonathan's suggestion I have used the CSS class for red and italic and I have changed a variable's name (alertString2).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Mandatory fields are now correctly checked on saving.
On other Jonathan's suggestion I have created a new class "missing" and I have added the background to staff-global.css.
The same for additem.tt.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Retested because of minor CSS change. Works nicely.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
If AcqCreateItem=ordering, when you receive an order, you now have a
list of all created items and checkboxes that permit you to choose which
items you want to receive.
A 'Edit' link open additem.pl page in a popup to allow you edit the
items before receiving them (popup is automatically closed after
modification, and items table is automatically updated)
If quantity is set manually in the text box, the appropriate number of
checkbox are checked from top to bottom and a warning shows up if
quantity is greater than order quantity
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
- Display a unique item block at once
On orderreceive.pl when AcqCreateItem is 'receiving', and on
neworderempty.pl when AcqCreateItem is 'ordering' it displays an
item block with item infos to fill, and a '+' button.
When user clicks on '+', the block is hidden and a list shows up with
the items that will be received. User can then edit or delete items in
the list and click 'Save' to receive items.
- PrepareItemrecordDisplay is now used for cloning block
Previous cloning function was duplicating ids, the side effect is that
plugins didn't work when several items were displayed.
PrepareItemrecordDisplay regenerate the form with new ids
- New system preference UniqueItemFields
Contains a space-separated list of sql column names (of items table).
This syspref is used in two ways:
- Values corresponding to fields in syspref are not duplicated when
adding a new item (button 'Add')
- When saving the form, a check is made on fields in syspref for
detecting duplicate (in DB and in the form)
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests done are noted on the bug report.
2012-03-23: Fixed conflict in updatedatabase.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This is the first patch for bug 7760 and touches all pages in acquisitions.
This adds a unique id "acq_<filename>" and a class "acq" to the body tag of
each page in acquisitions.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
New revision updates for current master and cleans up new
instances introduced by recent commits.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
2 problems found, fixing those in follo up patches:
- late orders don't allow more than 1 order to be selected
- basketgroups: 'Edit vendor' does the same as 'Manage orders'
Changing display from:
Suggested by Admin, Koha (from suggestion #2)
To:
Suggested by: Admin, Koha (suggestion #2)
Adding some missing parentheses and deleting some additional spaces.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Display suggestion info in acquisition module:
basket.pl
neworderempty.pl
orderreceive.pl
parcel.pl
To Test:
Create a suggestion and accept it.
Create a new order from this suggestion
Receive this order
For each step, check if suggestion info are visible.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Test provides more unit tests, all complete successfully.
perl t/db_dependent/Suggestions.t
Note: test case should be cleaned up after running tests.
Display changes are consistent and information about the suggestion
is shown on every important screen now.
I created an order from a suggestion and one from an existing record.
No problems found.
Reimplementing 3.0.x patch from
Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com>
To test:
1) Create basket
2) Order something, note your fund
3) Receive title
> Verify your name and selected fund display correctly
Additional tests:
1) Set borrowernumber in aqbasket.authorisedby to a nonexistant borrowernumber (like something really big)
> Created by should show "No name"
2) Set borrowernumber to NULL / empty
> Created by should show "No name"
Signed-off-by: Duncan Tyler <duncan@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
The problem was, that the script was looking for the first
and second <a> tag in the code. When using plugins in the framework
this can't work. The patch changes the script to select the correct
<a> tags by using a class.
Also changes + and - to 'Add' and 'Delete' to make the meaning clearer
and clicking on them a bit easier.
To test:
1) AcqCreateItem = order
- Create a basket
- Create an order line
- Create more than one item
- Delete items
- Check quantity is calculated correctly
- Check items are created correctly
2) AcqCreateItem = receive
- Create basket
- Create 2 order lines, order >1 items
- Do a partial item by removing items from the receive form
- Receive all missing items
- Receive more items than ordered
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
The item form on the order receive page (AcqCreateItem = on receive) contains a
lot of blank space which makes it hard to read and fill out.
To test:
- set AcqCreateItem = on receive
- create basket, order something, receive shipment
- check item form is nicely formatted and doesn't include lots of blank space
Note: It will be easier to test if you have an ACQ framework created to hide some
unnecessary subfields, because the hidden fields create the blank space.
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
Created an ACQ framework and hid some of the fields (hidden = 5). Before the
patch there were gaps between the fields as shown in the screenshot from
Katrin. After the patch fields line up nicely, with no extra space between
them.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
