If items are created when ordering, this patch allows to add a value for
some items subfields.
Test plan:
Define status for items.notforloan (mapping 995$o in unimarc), for
example 4:On order, 5:On treatment
Set the Syspref AcqCreateItem on "ordering".
ACQ framework : set default value = 4 for 995$o (in unimarc)
Syspref AcqItemSetSubfieldsWhenReceived : set "o=5|b='foo bar'"
When ordering the item, default status will be 4 ; when receiving the
item, status will be changed from 4 to 5. The subfield b have to contain
'foo bar'
Signed-off-by: Frederic Durand <frederic.durand@unilim.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
- List of libraries in basket.pl is now sorted by branch name, not code
- When IndependantBranches is ON, user has only the possibility to set
basket branch to its own branch, or to no branch at all.
- When basket do not belong to any branch, selected branch by default is
connection branch (was 'no branch')
- added id attributes to both added li elements
- change description of 'order_manage_all' permission to make it
clearer.
- remove Test::MockModule dependency
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- Add branch info to baskets
- Add a list of borrowers that are allowed to manage a basket (one list
for each basket).
- Add a new subpermission: acquisition => order_manage_all
If user is superlibrarian, or if that user has permission acquisition = 1
(GranularPermissions = OFF), or subpermission acquisition =>
order_manage_all (GranularPermissions = ON), that user is authorised to manage
all baskets.
Depending on syspref AcqViewBaskets:
'all': user can manage all baskets
'branch': user can manage baskets of their branch (the basket branch is
taken into account, not the branch of the basket's creator).
If basket branch is not defined, all users can manage this
basket.
'user': user can manage baskets she created, and baskets in their
user list
There are unit tests in t/Acquisition/CanUserManageBasket.t, which
require Test::MockModule
You can edit basket's branch and users list in basket modification page
(acqui/basket.pl)
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- use Modern::Perl;
- GPL version
- tabs
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes QA script and all tests.
Testing notes:
- CSV header row is now translatable.
Tested by updating the German po files and checking for the line.
- Tested that claiming for late serial issues still works as
expected, as one file has been renamed. Filed 10931 for
untranslatable CSV contents.
- Tested that claiming late orders still works:
* Table searching and sorting
Works nicely, but some columns could be split up for better
searching and sorting:
* Order date: 20/01/2013 (245 days)
* Total cost: 10.00x1 = 10.00 Books
=> item type should be separate
* Basket: 10 MPL
=> Library and basket number could be separate columns
* Filters
* Combined various filters, search results look correct.
* Selecting order for claiming
* Limiting by vendor makes it possible to check/uncheck all
* With no vendor limit, entries for other vendors will be
locked after the first checkbox is checked for one vendor
* Exporting as CSV
* Exported single line > CSV appears correct.
* Exporting multiple lines > CSV appears correct.
PROBLEM: Translated CSV don't work correctly, as line
breaks are lost in the translation process.
Needs to be fixed in a follow-up.
* Sending serial claim email
* No regressions found - there are some problems with the
email contents noted on bug 7298.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Using a template file, the CSV headers become translatable.
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Fixes a few capitalization errors on the late orders page like
- Claim orders
- filter
- Search results
Also moves the supplierid from the order date column to the
vendor column.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch allows to export late orders as CSV.
Test plan:
- Go on the late orders page (acqui/lateorders.pl)
- Select one or more order and click on the button "Export as CSV".
- The generated file should contains some information on the orders
(order date, estimated delivery date, vendor name, information field,
cost, basket name (and basketid), claims count and the claimed date)
The last line of the file is the total of orders.
- You are not allow to select order from different vendor.
- The check/uncheck all links appears only if a vendor is selected.
- Check that the check/uncheck works for all pages of the table.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing comments on last patch in this series.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The first patch does a left join on aqorders_items which returns too
much order lines.
This patch follows the Galen's suggestion: it removes the join and calls
the GetItemnumbersFromOrder routine for retrieving itemnumbers.
Bonus: the "parcelitems" variable is badly named and obfuscates the code.
I changed it for "orders".
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds a column to indicate holds on received items, as well as adding
a new column for fund and showing the subtotals per fund above
the total subtotal.
To test:
[1] Create an order basket containing at least one title and
ensure that an item is created for that title. Close the
basket.
[2] Place a hold on the title.
[3] Receive the order. After receiving it, but before finishing
the invoice, the table of already received orders should now
have columns for the order budget and number of holds on the
title as well as lines with the subtotal per fund.
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2 DB fields are not used: aqbudgets.encumb and aqbudgets.expend.
This patch uses these fields in order to show a warning message if the
budget selected for an order has exceeded.
Test plan:
- Create a new active fund with at least 1 of both warning fields
('Warning at (%)' and 'Warning at (amount)').
- Create a new order for a basket with this new fund and a cost >
warning amount defined for the fund (or using %).
- Save and check that a warning message appears
- Retry playing with all combinations of warning fields
Signed-off-by: Koha Team Lyon 3 <koha@univ-lyon3.fr>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Since the parcel.pl script get *all* pending orders, there is no reason
not to display all of them.
Like that, DataTable manages pagination and sorting correctly (on all
data).
This patch adds filters on the table header (using columnFilter).
Test plan:
Try filters on the left of the screen and filters on the table header.
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Searching and sorting the table works correctly.
Larger result sets are a performance problem on this page,
I have filed bug 10595 for that.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
After receiving an order basket, before finishing receiving the shipment,
one has an option to cancel the receipt. This patch fixes a bug where
a basket whose receipt was just cancelled displays on both the pending orders
and already received tabs.
This patch also fixes a minor unitialized variable warning.
To test:
[1] Create a basket with at least one order and close it.
[2] Receive the order, then on the row in the 'Already received'
table, click the cancel receipt link.
[3] In the page that displays, the basket just cancelled displays
on both tables. Clicking the cancel receipt link again results
in an error message.
[4] Apply the patch.
[5] Repeat steps 1 and 2. This time, the cancelled basket displays
only in the pending orders table, as expected.
[6] Verify that after applying the patch, the following no longer
is logged in the Apache error log:
parcel.pl: Use of uninitialized value in string eq at acqui/parcel.pl line...
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Ed Veal <ed.veal@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes test plan, all tests and QA script.
Works as described.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- add a message if the search returns no result
- keep selected values if the search returns no result (for fund and
order status)
- remove plurals in order status
- move the order status column in the search results table
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
New tests also pass:
t/db_dependent/Acquisition/close_reopen_basket.t
1) Database update - I end up with too many partials. My test cases:
- New orders, basket still open
OK Expected: new, Result: partial
- Ordered orders, basket and basketgroup closed
OK Expected: ordered, Result: partial
- Partially received orders
OK Expected: partial/complete, Result: partial/complete
- Received orders
OK: Expected: complete, Result: complete
- Cancelled orders
* cancelled from open basket before order
OK: Expected: cancelled, Result: cancelled
* cancelled from closed basket before receive
OK: Expected: cancelled, Result: cancelled
All aqorders where updated with the correct status.
I have saved my 'pre-updatedatabase' and can repeat the test anytime you have a follow up.
2) Testing search functionality
a) Order search - result list
Order search shows a new column, I think it would be a bit better if the
status there was singular instead of plural - new order, partially received
order etc. - maybe we could even leave out the 'order'? (minor)
The column seems a bit lost in the middle, not sure where it would make more
sense (just saying)
b) Order search - advanced search form
The advanced search form now shows a new filter: Order status
All new status can be searched.
- an "empty" search will find all but cancelled orders
- searching for cancelled orders works correctly and shows results
Search works correctly, no regressions found.
If no result is found a message is shown.
All search input is kept, so you can modify your search terms easily.
3) Testing setting of status after applying the patch
a) Create a new order with 2 items - status is new. OK
b) Close the basket - status is ordered. OK
c) Receive both items - status is completed. OK
d) Undo receipt - status is ordered. OK
e) Receive only 1 item - order is split up into 2 orders:
- status is partial OK
- status is completed OK
f) Undo receipt of received item - order is combined into 1 again
- status is ordered OK!
g) Receive only 1 item again - status ordered/partial.
h) Delete order.
- status is completed
- status is cancelled
OK!
i) Undo receipt of 1 item again.
Refresh page.
This results in the following behaviour, that has been reported as
bug 10984. After refreshing the page follow message is shown:
Cannot cancel receipt. Possible reasons :
- The order line you trying to cancel was created from a partial
receipt of another order line which is already received.
Try to cancel this one first and retry.
- The order line you trying to cancel was created from a partial
receipt of another order line which has been deleted.
Cancellation is not possible.
BUT: The receipt is undone, but you are left with a
line with 2 items, a cancellation date and the status ordered.
Because of the cancellation date the order is not visible in pending orders.
The status is correct - so I feel this should not stop this patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
You can now search orders by
- order status
- fund
The patch series also adds a new field, aqorders.orderstatus, which can
contain following values:
new
ordered
partial (for partially received orders)
complete
cancelled
To test: Search and check if results are consistent in histsearch.pl
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on last patch.
Note: status are no longer numeric, but strings now.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
I have heard from several libraries that at the end of the budget
year even though a budget is inactive for new acquisitions, an
inactive budget should remain modifiable until the books are
closed and the budget is marked inactive. This patch makes it so
that all budgets that are unlocked are available on the order
receipt page (only).
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Right now there is no way to change the budget or fund when receiving an
item, which is annoying, particularly at the end of the fiscal year when
every item not already received has to be switched to the following
year's budget. This patch adds the ability to change the budget and fund
when receiving.
To test:
1) Apply patch.
2) Create an order for a vendor, choosing a fund to use for that order.
3) Receive the order, leaving the fund unchanged. Make sure the fund
did not change.
4) Create another order for a vendor, choosing a fund to use for that
order.
5) Receive the order, this time changing the fund. Make sure the fund
is changed.
6) Run the unit test:
> prove t/db_dependent/Acquisition.t
7) Sign off.
(Notes: this patch depends on the Acquisitions.t unit test improvements
in bug 10274; the seemingly-unrelated change in SQLHelper quiets an
irritating warning caused by the NewOrder call in ModReceiveOrder)
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Given how easy it is to accidentally receive items from one invoice on
multiple invoices, the ability to merge invoices can be quite handy.
This patch adds that ability to Koha's Acquisitions module.
To test:
1) Apply patch.
2) Run unit test:
> prove t/db_dependent/Acquisition/Invoices.t
3) Create two invoices from the same vendor for merging, and receive at
least one order on each.
4) Do a search on the Invoices page that brings up both the invoices you
created.
5) Check the boxes next to the two invoices.
6) Click "Merge selected invoices."
7) Choose which invoice you want to keep (the default will be the first).
8) Click "Merge."
9) Confirm that the resulting invoice has all the orders you received
listed on it.
10) Sign off.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Merged several invoices sucessfully - with and without received
orders, open and closed. Works nicely.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a new filter "basket group name" for pending orders
searches.
Test plan:
Try different filters and check that results are consistent.
Try to filter by basket group name.
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Applied on top of patches for bug 10723.
Passes all tests and QA script.
Note: It's a bit irritating that the basket name is not shown
in the list of pending orders, so there is no way to check the
results are correct without checking from another page.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In the C4::Acquisition module, 2 routines do the same work. This patch
merges these 2 routines.
Test plan:
test the acqui/orderreceive.pl, acqui/uncertainprice.pl
and serials/acqui-search-result.pl, acqui/parcel.pl scripts.
Note: on acqui/parcel the basket filter is a search on basket name (was
on basket id, which was not relevant).
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pm, no adverse bahaviors noted. All sub calls updated.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Koha::DateUtils::output_pref took 4 parameters and the last one is a
boolean, so some calls were:
output_pref($dt, undef, undef, 1)
This patch changes its prototype to
output_pref({
dt => $dt,
dateformat => $dateformat,
timeformat => $timeformat,
dateonly => $boolean
});
An alternative is to call the output_pref routine with a datetime
object, without using an hashref:
output_pref($dt);
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch introduces a new Z39.50 interface for searching Z39.50
compliant databases for MARC authority records.
These databases aren't as common as their bibliographic equivalents,
but they're out there and very useful. I have included info at the
bottom of this messsage for sample authority databases you can try.
To test this patch:
1) Set up Z39.50 client targets for authority databases. (I've included
information at the bottom of this message for LibrariesAustralia's
test server for authorities as well as instructions on how to use
your Koha's z39.50 authority server as well. The Library of Congress
also has authority databases available (unsure if these are test or
prod), and you might have access to others through OCLC or RLIN. OCLC
provides login credentials for their test databases.
2) Go to the Authorities module
3) Click on the new "Z39.50 search button"
4) Select your authority search targets from the list.
5) Do a search for an authority you would like using either the "Raw"
input box or the more specific input boxes for names, subjects, subject
sub divisions, or titles. (I like searching Name (personal): Eric on
the LibrariesAustralia test DB.)
6) You should see a table listing the server, heading, authority type,
and two other columns (MARC and a nameless column). "Authority type"
is the type of authority it will become when imported in to Koha. In
the Eric example, "PERSO_NAME".
7) Click on "MARC" next to the results of interest to review the MARC
authority record.
8) When you're satisfied with a record, click on "Import".
9) The pop-up window will close and your original Koha window will
change to the "Adding authority Personal Name" screen (in the Eric
example).
10) All the relevant fields should be filled out for the record. Review
them and make any changes as necessary. (N.B. The 001 will be cleared
when saved, so if you have a use for the imported control number, move
it to the 010, 016, or 035 as appropriate. If you have a default value
for the 003, this will also likely be overwritten. Move it if necessary.
The 005 will also be updated when saved, so do not worry about that.)
11) When you're satisfied, click save.
12) Presto! You've imported your first authority record via Z39.50!
--
Here is the info for the LibrariesAustralia test Z39.50 authority
database:
Z39.50 server: LibrariesAustralia Authorities
Hostname: z3950-test.librariesaustralia.nla.gov.au
Port: 210
Database: AuthTraining
Userid: ANLEZ
Password: z39.50
Syntax: MARC21/USMARC
Encoding: utf8
-
The U.S.A. Library of Congress also provides Z39.50 access to its Name
and Subject Authorities (http://www.loc.gov/z3950/lcserver.html).
Name Authority:
Z39.50 server: Library of Congress Name Authority File
Hostname: lx2.loc.gov
Port: 210
Database: NAF
Syntax: MARC21/USMARC
Encoding: utf8
Subject Authority:
Z39.50 server: Library of Congress Subject Authority File
Hostname: lx2.loc.gov
Port: 210
Database: SAF
Syntax: MARC21/USMARC
Encoding: utf8
(N.B. Both of these databases also include title authorities.)
-
For testing purposes, you can also set up a Z39.50 client target,
which points at your own Koha instance's Z39.50 authority server.
To find the hostname, go to /etc/koha-conf.xml and find the value for
the <listen id="authorityserver"> element. Depending on your
configuration, this could be something like the following:
unix:/zebra/koha/var/run/zebradb/authoritysocket
(N.B. You might be using a different scheme than unix sockets...)
To find the database, scroll down to the bottom of koha-conf.xml until
you reach the <config> element. Within this, look for the value of the
element <authorityserver>. It should probably be "authorities".
To set up this Z39.50 client target in Koha...
Z39.50 server: my koha authorities
Hostname: unix:/zebra/koha/var/run/zebradb/authoritysocket
Port:
Database: authorities
Userid:
Password:
Syntax: MARC21/USMARC (or whichever flavour you need)
Encoding: utf8
Signed-off-by: Mason James <mtj@kohaaloha.com>
Bug 10096 [FOLLOW-UP] - Add a z39.50 interface for authority searching
This patch adds the "recordtype" column to the "z3950servers" table.
The value in this column (biblio or authority) then controls whether
the z3950 server shows up in a bibliographic search (through the
Acq and Cataloguing modules) or in an authority search (through
the Authorities module).
I also edited the z3950 management console to show this value
and allow users to edit it. The default value is "biblio", since
the vast majority of z3950 targets will be bibliographic. However,
there is an option to add/edit a z3950 target as a source of
authority records.
Test Plan:
1) Apply both patches
2) Run updatedatabase.pl (after setting your KOHA_CONF and PERL5
environmental variables)
3) Use the test plan from the 1st patch
N.B. Make sure that your Z39.50 client target has a Record Type
of Authority, otherwise it won't display when you're doing a
Z3950 search for authorities.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Bug 10096 [FOLLOW-UP] - fix tabs/whitespace errors to pass QA
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No koha-qa errors.
Fixes problem, but I think is better to remove
=back than to add nother =over 4, but I'm not
a POD expert
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adapts the fund-handling code from neworderempty.pl
in order to limit the display of funds by default to active ones,
with the option to check a box to display all funds.
This patch also adds "(inactive)" to the display of funds on this and
the neworderempty.tt template because it seemed like that was useful
information.
To test, make sure you have both active and inactive funds.
Start the process of receiving a shipment. The "fund" option
in the receive shipment form should show only active funds.
Checking the "show all" checkbox should allow you to choose
from both active and inactive funds.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch introduces a DataTables sorting plugin, title-numeric,
for sorting cells based on a decimal number embedded in a span title
attribute. This allows currency amounts to be formatted properly
for display without having to writing a sorting plugin that's
super-smart about removing the formatting, particularly for locales
that use a comma as the decimal mark.
The sorter plugin can be used like this:
- In the DataTables config:
"aoColumns": [
{ "sType": "title-numeric" },
]
- In the table data
<td><span title="[% decimal_number_that_JS_parseFloat_accepts %]">
[% formatted currency %]
</span></td>
To test:
[1] Ensure that there is at least one active budget and at least
one inactive one.
[2] Go to the acquisitions home page. Note that changing the sort order
on the amount, ordered, spent, or avail columns results in incorrect
sorting that is either ASCII-betical or which ignores any component
of large numbers that occur after the thousands separator.
[3] Apply the patch.
[4] Verify that the sorting now works correctly and that no JavaScript
errors appear in the JS debug console of your choice.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Sorting now works correctly, for active and inactive funds.
Passes all tests and QA script.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch implements some of the suggestions made
by Owen Leonard and brings the form closer in line
with other popup forms. In particular:
- sets dimensions for the popup so that clicking on the
link is more likely to open a new browser window, not
a tab.
- ensures that the vendor search form is always visible
- adds a cancel link to make it more clear to library
staff that they can abort the process.
- tweaks markup to better match the patron guarantor
popup search form
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This allow to keep transfers informations without having untranslatable
strings in database.
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
On basket.pl and parcel.pl there is a 'Transfer' link which allow you to
transfer order lines from a basket to another.
The link leads to a new page which allow you to search for a bookseller,
then display this bookseller's baskets. Then you can pick a basket and
the transfer will be done.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: sonia <koha@univ-lyon3.fr>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds an "add to basket" link to the vendor search results
page for each open basket associated with each vendor. Clicking it
triggers a modal window with the "add to basket" choices for that vendor
and basket.
Other changes in this patch:
- The add-to-basket include has been modified in order to make it more
useful in this context.
- booksellers.pl has been modified to check for an existing budget so
that the add-to-basket include can properly display a warning if there
are none.
- "New basket" and "Receive shipment" buttons associated with each
vendor search result have been converted to Bootstrap-styled buttons.
- Basket closed date has been moved into its own column so that the
table can be sorted by that value.
- Table columns containing dates now use the "title-string" sort option,
eliminating the need for a special date sorting algorithm.
- Converted some &'s to &'s
To test, apply the patch and search for a vendor. For each vendor in
your search results baskets which are open should include an "add to
basket" link. Clicking it should open a modal dialog with the same "add
to basket" options offered on the basket page. The correct vendor ID and
basket number should be associated with each link.
The newly-styled "new basket" and "receive shipment" buttons should work
correctly. Table sorting should work correctly, including the new
"closed" column.
Since the add-to-basket include file was modified, the "add to basket"
button on the basket view page should also be tested (acqui/basket.pl).
Signed-off-by: Campbell Reid-Tait <campbellreidtait@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If you want to print a basketgroup with pdf format, it will be in
English. The pdf is done with layout2pages.pm or layout3pages.pm,
which call layout2pages.pdf or layout3pages.pdf.
This patch adds layout3pagesfr.pm in src/acqui/pdfformat/ which
calls layout3pagesfr.pdf.
And adds in basketgroup.pl the check for layout3pagesfr
To use it you have to change the systempreferences to pdfformat::layout3pagesfr
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described, koha-qa reports some tab errors.
Corrected in a followup.
Please, always add a test plan, it's easier to test.
Test:
1) apply the patch
2) change syspref OrderPdfFormat to pdfformat::layout3pagesfr
3) select a vendor
4) create a basket group (empty works)
5) close basket group
6) print basket group
7) PDF is in french
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works nicely, although it would be better if we could
find a more general solution to make the templates editable
and translatable.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If you have AcqWarnOnDuplicateInvoice set to warn it only warns if you have 2
or more invoices with the same number. It should warn if you're trying to
create a duplicate.
To test:
1) Turn on AcqWarnOnDuplicateInvoice.
2) Try to create an invoice that duplicates an invoice number you are already
using exactly once.
3) Note that you get a warning after applying this patch.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
all tests pass
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When syspref "UniqueItemFields" is defined, the item uniqueness is
tested in acquisition by an AJAX call to check_uniqueness.pl. This
patch fixes an issue where check_uniqueness.pl wasn't looking
at the correct CGI parameters.
Test plan :
- Select an existing item with barcode
- Add "barcode" to "UniqueItemFields" syspref (use space as separator
for multiple values)
- Set "AcqCreateItem" syspref to "Create an item when placing an order"
- Go to an acquisition basket
- Create a new order from empty
- Enter existing barcode in item form and save
=> You get an alert that barcode already exists and order is not saved
- Enter a non-existing barcode in item form and save
=> Order and item are created
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Refactors Z3950Search.
Disable batch record counts for z3950 records.
Test plan:
Do various Z3950 searches on multiple targets from Cataloging and Acquisition.
Behavior should not have changed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
C4::Booksellers::GetBooksellersWithLateOrders has an unused parameter.
The $branch variable is never used in the routine.
Test plan:
Check that no behavior changes on the late orders page.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I couldn't find any use of the branch parameter apart from
the one corrected by this patch. Also tested late orders,
couldn't find any problems.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Improve the code that displays and allows staff to
set the basket group from the basket details page
for a closed basket.
Prior to this patch, a staff member who did not
have the group_manage acquisition permission would
still see a control to change the group that the
basket belongs to; attempting to change the group
would present with with a login page.
This patch also does some tidying of how basket group
details are passed to the template.
To test:
[1] Create an order basket and close it. Do
not assign it to a basket group.
[2] View the basket details while logged in as
a staff user who has the order_manage acquisitions
permission but not the group_manage. The
displayed basket group should be "No group".
[3] Switch to a staff user who also has the
group_manage permission, then view the basket
details again. The basket group field should
now be a select input that allows you to change
the basket group.
[4] Change the basket group. Verify that the basket group
you selected is now displayed as the current group
for that order basket. The basket group delivery and
billing place fields should also now be displayed.
[5] Close the basket group set in the previous step, then
view the basket details again. This time, the basket
group name should be displayed with a suffix of " (closed)",
and no input to change the group should be displayed.
[6] Swith to a staff user who does not have the group_manage
permission, view the basket details, and verify that
the basket name is displayed with a suffix of " (closed)".
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Some vendors ship materials from the same invoice in multiple packages.
In those cases, it would be good to notify the librarian when they enter
a duplicate invoice number, so that they can continue receiving on the
previously-created invoice, rather than creating an invoice with a
duplicate number.
To test:
1) Apply patch and run database update.
2) Make sure that you have created at least one invoice on
acqui/parcels.pl and take note of the invoice number.
3) Try to create an invoice with the same invoice number.
4) Note that without changing your configuration this works exactly
the same as before.
5) Turn on the AcqWarnOnDuplicateInvoice system preference.
6) Try to create a new invoice with the same number as the one you
noted earlier.
7) Make sure you get a warning about a duplicate invoice.
8) Choose to receive on the existing invoice.
9) Confirm that you are receiving on said existing invoice.
10) Start the receiving process over, and this time choose "Create new
invoice anyway."
11) Confirm that you are now receiving on a new invoice.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
I have followed the test plan, but also checked some more things:
- Checking the duplicate check works when you have the entered
invoice number in your database multiple times already.
- Checking that no duplicate message is shown if you enter the
invoice number and it's already been used for an invoice from
another vendor.
Looks all good. I think the only thing we could argue about here
is if this could be activated by default for new installations.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
There is currently no way to delete unused invoices (for example,
invoices created by mistake), and there really should be, since errors
and absent-mindedness can result in numerous empty invoices over the
course of years.
To test:
1) Apply patch.
2) Create three invoices in the Acquisitions module. For one of them,
receive at least one item. For the other two, do not receive any
items.
3) View one of the invoices that does not have any items on it.
4) Try to delete it. This should succeed.
5) View the invoice that has an item. There should not be any option
to delete it.
6) Do an invoice search that brings up the other invoice with no items
on it. Try to delete it from the results page. This should succeed.
7) Run the unit test:
> prove t/Acquisition/Invoice.t
8) Sign off.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass. I also did another test:
I cancelled all receipts from an existing invoice and then could
successfully delete it in the last step.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes some things on the order receiving/parcel page.
1/ Removes dead code
2/ Displays an error message if invoiceid is unset or does not refer to an
invoice
3/ Fixes a bug in the note ("change note" and "add note" links)
Test plan:
1/ Try to call the invoice page with an existing invoiceid and check
that order results are consistent.
2/ Try without invoiceid or a bad invoiceid and check that an error
message is displayed.
3/ Add and change notes.
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely for all tests done.
- parcel.pl with invalid invoicenumber gives a nice error message
- parcel.pl with a valid invoicenumber looks normal
- changing and editing order notes works well
Passes QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The DB field aqorders.biblioitemnumber seems to be unused except to get
the itype on the spent.pl page.
This information can be retrieved uising another SQL join.
Test plan:
Try a complete workflow in the acquisition module: create an order,
receive it, play with the syspref AcqCreateItem.
Check that no regression is found and that the data for existing
orders don't change.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch offers an alternative option to fix Bug 9744. In this version
the table of funds swaps positions with the suggestions block so that
the table has the whole width of the screen. This eliminates the need to
adjust its float property.
Other changes:
- Simplification of the column and row-hiding JavaScript
- The addition of an "Active" column to be shown when all funds
are shown (this helps indicate to the user which rows were hidden)
- Linking the fund owner to their patron record
- Linking the fund id, given the correct permissions, to the view of all
funds for that budget (the best alternative to linking to a view of
the fund details, which we do not have).
- Correcting permission level required to add a budget
To test, view the acquisitions home page. The layout should feel
comfortable. The table of available funds should show the fund name.
The checkbox to show all funds should work correctly.
Signed-off-by: caroline very-mathieu <caroline.very-mathieu@nimes-ville.fr>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
- Remove an unnecessary loop where output just
recreated input.
- Remove unnecessary temp variables that obscure code purpose.
- Call the variable containing invoices, invoices
rather than anonymous and ambiguous results
reflect namechange in template.
- Lists are passed to template as array refs;
declare them as scalars as that is how we use them.
- No need to introduce the whole namespace of some C4
modules for 1 routine.
Test plan:
Note that this patch should not change any visible behavior.
[1] Open the invoice search page.
[2] Verify that the list of suppliers in the drop-down
on the search form is complete.
[3] Verify that the list of libraries in the drop-down
on the saerch form is complete.
[4] Perform a search. Verify that the list of invoices
is correct.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
With this followup, instead of passing the real names of the branches to template file, only the branchcodes are passed.
The branchcodes are translated into branchnames in template file, using the KohaBranchName template plugin.
To test :
do the same test as for main patch :
1) make some basketgroups with 0, 1, 2 baskets
2) make some basketgroups with different billing and deliveryplace
3) check the list of open and closed basketgroups
4) check action buttons are working like before
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Revised to fix whitespace problems. Cosmetic changes put in an other patch.
In the list of all the open/closed basketgroups for a vendor, you just
have the name of each basketgroup, and 3 action buttons.
It is not sufficient for libraries using basketgroup.
This patch adds the following columns :
- number (id of basketgroup)
- billingplace (name of the library)
- deliveryplace (name of the library, or "free delivery place")
- number of baskets in each basketgroup
To test :
1) make some basketgroups with 0, 1, 2 baskets
2) make some basketgroups with different billing and deliveryplace
3) check the list of open and closed basketgroups
4) check action buttons are working like before
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This is a nice improvement!
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Enable IndependantBranches
2) Apply this patch
3) Run updatedatabase.pl
4) Verify that the system preference still functions correctly
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
