Commit graph

78 commits

Author SHA1 Message Date
3d2e91a573 Bug 19754: Move template JavaScript to the footer: Acquisitions, part 2
This patch modifies some staff client acquisitions templates so that
JavaScript is included in the footer instead of the header.

To test, apply the patch and test the JavaScript-driven features of the
modified templates: All button controls, DataTables functionality, tabs,
etc.

- Acquisitions -> Invoices
  - Datepickers
  - Search for invoices
    - Datatable
- Acquisitions -> Late orders
  - Datepickers, datatables, selection controls (when searching by
    vendor)
- Acquisitions -> Vendor -> Basket -> Add to basket -> From an existing
  record -> Search
  - Datatables, View MARC modal
- Acquisitions -> Vendor -> Basket -> Add to basket -> From a new
  (empty) record
  - Form validation, inactive fund control, add users to notify on
    receiving.
- Acquisitions -> Vendor -> Basket -> Add to basket -> From a
  subscription -> Search
  - Datatables, show only renewed, show/hide search form
- Acquisitions -> Vendor -> Basket -> Add to basket -> From a suggestion
  - Datatables, "Show" controls
- Acquisitions
  - "Ordered" link in table of funds
    - Datatables
- Acquisitions -> Vendor -> Receive shipment -> Invoice -> Receive
  - Datepickers, item add form plugins (test with AcqCreateItem set to
    'receiving an order.'

Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-23 10:58:09 -03:00
90e0c0de5c Bug 20148: Prevent adding same user multiple times to an order
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-18 16:48:42 -03:00
0ad922011c Bug 12904: Force browser to load new javascript files after upgrade
This patch has been automatically generated using:
  perl kv.pl **/*.tt **/*.inc

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
2018-02-08 14:53:24 -03:00
9a3ad32e46 Bug 18525: (bug 14828 follow-up) FIX ordering from suggestion when item-level_itypes = biblio
When ordering from a suggestion with item-level_itypes = biblio the app
crashes with
Template process failed: undef error - The method selected is not
covered by tests! at /home/vagrant/kohaclone/C4/Templates.pm line 121.

C4::ItemTypes->all did not set a selected flag. The item type is only
display when ordering (and not modifying an order).
The flag is never set, the test can be removed.

Test plan: Confirm that the error is gone

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-05-12 08:50:40 -04:00
ba89de5837 Bug 16984: Do not clone the item block for standing orders
If AcqCreateItem is set to ordering and the basket is marked as
"standing orders", when ordering a JS error is raised:
additem.js:176 Uncaught TypeError: window[events[i]] is not a function

The item block should not be displayed in that case.

Test plan:
- Set AcqCreateItem to "ordering"
- Create a basket and tick the "Standing orders" checkbox
- Add an order to this basket
=> Without this patch you get the JS error
=> With this patch applied you will not get it

Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-02-14 13:55:05 +00:00
804677265e Bug 16239: Update templates
Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-01-13 14:41:22 +00:00
cb3d6625e8 Bug 14541: Do not truncate tax rate values
Tax rates are stored in decimal(6,4) fields which means that 4 decimals
are allowed.
If a tax rate is 8.42%, it is stored as 0.0842
If a tax rate has more precision than that, Koha won't deal correctly
with it. We will need to update the DB structure.

With this patch, the tax rate will be displayed with the same precision
as in the DB. So if you enter 8.42, you will see 8.42% instead of 8.4%
without this patch.

Test plan:
Do a full acquisition workflow with a tax rate like 8.42% and confirm
that it is correctly displayed.

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-12-09 16:29:33 +00:00
Katrin Fischer
917bdb5dce Bug 16123: Remove bold formatting from first level fund
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-10-28 15:26:00 +00:00
Blou
73d9557b13 Bug 16123 - Display budget hierarchy in the budget dropdown menu used when placing a new order
When placing a new order, the budget dropdown will display the budget hierarchy.

TEST PLAN :

1. Go to the Administration module
2. Add a new budget (ie : Budget 2016)
3. Add a fund to this budget (ie : Book)
4. Add a child fund (ie : Adult fiction)

You will have this hierarchy :

Budget 2016
 |____ Book
         |_____ Adult fiction

5. Go to the Acquisition module
6. Select a vendor and create a new basket
7. Place an order
8. Check the budget dropdown menu

BEFORE PATCH
Book
Adult fiction

AFTER PATCH
Book
   Adult fiction

Dropbown menu is hierarchical as expected.
Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Katrin Fischer  <katrin.fischer@bsz-bw.de>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-10-28 15:26:00 +00:00
Jonathan Druart
20d9ed618f Bug 13321: Rename variables
This patch renames the variable according to the new DB column names
 * gste => tax_excluded
 * gsti => tax_included
 * gstrate => tax_rate
 * gstvalue => tax_value

This patch also modify the ModReceiveOrder subroutine:
 * Edit vendor note on receiving is not possible, so the code should not
   permit that.
 * Update ModReceiveOrder to pass a hashref

And that's all!
git grep on gste, gsti, gstrate and gstvalue should not return any code
that can be executed.

Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>

Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com>

Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-10-28 13:45:59 +00:00
1d546c57b1 Bug 14752 - (QA followup) Remove annoying modal, use dialog box instead
- Uses a dialog box to warn of unique fields not copying, dialog was in
place for barcode generation so removed the extar modal completey
- Fixes a problem when barcode was undefined and autobarcode on
- deleted an extra space in Barcodes/hbymmincr.pm

Signed-off-by: sonia BOUIS <sonia.bouis@univ-lyon3.fr>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-09-13 17:21:05 +00:00
bdcbada8b8 Bug 14752 - Add multiple copies to a basket at once
This patch add an 'Add multiple copies' button on the new order page in
acquisitions.  While processing the multiple copies a modal is
displayed.

To test:
1 - Add an order to an acquisitions basket
2 - Choose to add multiple items
3 - A modal shouold warn about ignoring UniqueItemFields from syspref
4 - When submitting the modal should popup until all items are processed.
5 - The modal should disappear after items are added.
6 - Items should be cloned, minus unique fields
7 - Enable autoBarcode for various formats, ensure you are warned that
barcodes will be generated, and ensure they are generated correctly

Sponsored by: Middletown Township Public Library (http://www.mtpl.org)

Signed-off-by: sonia BOUIS <sonia.bouis@univ-lyon3.fr>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-09-13 17:21:04 +00:00
5e1bcc4aa7 Bug 16242 - Move staff client JavaScript out of language directory
This patch moves the JavaScript files in prog/en/js to prog/js.
JavaScript files do not need to be in the directory which is processed
by the translator.

To test, apply the patch and visit various pages in the staff client to
confirm that JavaScript files are still loading correctly.

Revised: I intended for this to be built on top of Bug 15883 as well as
Bug 16242. Now it is.

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
On top of 15883 and 16241
All seems to work, js files pulled from new dir.
No errors

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-04-29 14:32:42 +00:00
Jesse Weaver
97d988b54f Bug 15531: (followup) Use a quantity of 1, not null, for standing orders
This seems to cause fewer problems with the existing acquisitions code.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-04-29 13:07:18 +00:00
Jesse Weaver
9501ac2fef Bug 15531: Add support for standing orders
This allows creation of special baskets that include standing orders.
These orders do not have a known quantity (and may not have a known
price in advance). Upon receipt, the received items are split into a new
completed order.

Test plan:
  1) Run updatedatabase.pl.
  2) Run prove t/db_dependent/Acquisition/StandingOrders.t . (and the
     other Acquisition tests).
  3) Create a new basket, mark it as a standing order basket.
  4) Add an order to this basket, and notice that the quantity field is
     missing (and thus not required).
  5) Receive items for this order, and notice that the original order is
     unchanged. The new child order line should have the correct price
     and quantity information.

(Note: the QA tools output what seems to be a spurious spelling error
for Test::More's "isnt" in StandingOrders.t.)

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-04-29 13:07:17 +00:00
fd9f9f9be1 Bug 16227: Fix regression from bug 15084 - select currencies correctly
This patch fixes a regression introduced by bug 15084: The currency
dropdown lists are not correctly built.
The selected currencies are wrong.

Test plan:
Create a vendor, the selected currencies should be the default one
Edit the vendor, the selected currencies should be the ones defined for
 this vendor
Create an order, the selected currency should be the 'List prices' of
 the vendor
Edit an order, the selected currency should be the one defined for this
 order

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
2016-04-20 18:35:38 +00:00
1538e9ecf4 Bug 15084: Replace C4::Budgets::GetCurrencies with Koha::Acquisition::Currencies->search
Most part of the code here is unnecessary complex. We should selected
the currency if it is selected, that's all :)

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
2016-03-03 20:39:01 +00:00
a8942c2884 Revert bug 13618 - "Prevent XSS in the Staff Client and the OPAC" due to performance issues
Revert "DBRev to make notes of the XSS patches and the new important dependency."

This reverts commit e140603a59.

Revert "Bug 13618: Specific for branches.opac_info"

This reverts commit 06e4a50f00.

Revert "Bug 13618: (follow-up) Specific for other prefs"

This reverts commit d6475a111f.

Revert "Bug 13618: Fix for debarredcomment and patron messages"

This reverts commit dd98c9df92.

Revert "Bug 13618: Do not display html tags in patron's notices"

This reverts commit a065b243fe.

Revert "Bug 13618: Do not display &nbsp; and html tags in item fields content"

This reverts commit baeeaffbf8.

Revert "Bug 13618: Fix for system preference description"

This reverts commit a967a09261.

Revert "Bug 13618: Remove html filters for newly pushed code"

This reverts commit 0e98662b10.

Revert "Bug 13618: (follow-up) add missing lines for opac-shelves"

This reverts commit fc2fb605e5.

Revert "Bug 13618: (follow-up) Specific for ColumnsSettings"

This reverts commit bc308fdd9c.

Revert "Bug 13618: Fix for edit biblios and items"

This reverts commit 811c4e8402.

Revert "Bug 13618: followup to remove tabs"

This reverts commit ca8e8c397c.

Revert "Bug 13618: Fix last occurrences recently introduced to master"

This reverts commit bb417b256b.

Revert "Bug 13618: Fix for news"

This reverts commit ae5b98020a.

Revert "Bug 13618: Fix escape on sending baskets or shelves by email"

This reverts commit a7731ffe25.

Revert "Bug 13618: Specific for XSLTBloc"

This reverts commit 11fa38dc29.

Revert "Bug 13618: Specific for Salutation on editing a patron"

This reverts commit 36c07ad6d3.

Revert "Bug 13618: Specific for other prefs"

This reverts commit e6ea281a3b.

Revert "Bug 13618 - memberentrygen.tt errors Not a GLOB reference"

This reverts commit 7824874557.

Revert "Bug 13618: Specific for ColumnsSettings"

This reverts commit 1834da3da3.

Revert "Bug 13618: Specific for IntranetUser* and OPACUser* prefs"

This reverts commit 21ae62b253.

Revert "Bug 13618: Fix error 'Not a GLOB reference'"

This reverts commit 602bdbab4c.

Revert "Bug 13618: Specific for the ISBD view"

This reverts commit d254362435.

Revert "Bug 13618: Specific for pagination_bar"

This reverts commit 8837a8ae68.

Revert "Bug 13618: Specific places where we don't need to escape variables - intra"

This reverts commit 00eff140b3.

Revert "Bug 13618: Remove html filters at the intranet"

This reverts commit 7db851ff03.

Revert "Bug 13618: Specific places where we don't need to escape variables"

This reverts commit 49a3738b8d.

Revert "Bug 13618: Remove html filters at the OPAC"

This reverts commit cedaa0e23e.

Revert "Bug 13618: Use Template::Stash::AutoEscaping to use the html filter"

This reverts commit 01b38d3b13.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
2016-02-11 19:39:53 +00:00
Jonathan Druart
7db851ff03 Bug 13618: Remove html filters at the intranet
Signed-off-by: Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
2016-01-29 17:54:12 +00:00
237c1483dd Bug 14743: addorder.pl redirect problems under plack behind apache 2.4.10
I can't quite figure this out. When I run CGI version of Koha, I see following response (recorded using tcpdump):

HTTP/1.1 302 Found
Date: Thu, 27 Aug 2015 13:28:41 GMT
Server: Apache/2.4.10 (Debian)
Location: /cgi-bin/koha/acqui/basket.pl?basketno=5610
Vary: User-Agent
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/x-perl

However, when running behind apache 2.4.10 on Debian wheezy I see chunked response:

HTTP/1.1 302 Found
Date: Thu, 27 Aug 2015 13:21:28 GMT
Server: Apache/2.4.10 (Debian)
Vary: User-Agent
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/x-perl

60
Transfer-Encoding: chunked
Date: Thu, 27 Aug 2015 13:21:28 GMT
Connection: keep-alive

0

0

This response doesn't work in firefox (where it reports page not found) nor in chrome (where it returns lines below 60 on screen).

In the template the hidden input 'basketno' is listed twice. What the cgi script reads in the parameter, what is does is concat the values of the multiple basketno instances together createing what is likely an invalid basketno. For reasons beyond my understanding this is what triggers this error!

Test Plan:
1) Using plack, add an order to a basket from an external source
2) Note the error
3) Apply this patch
4) Add an order to a basket from an external source
5) Note you get no error!

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2015-11-10 09:28:47 -03:00
Katrin Fischer
8eb049a6a1 Bug 14163: Acq order form: rename 'Show all' to 'Show inactive'
On the order form there is a checkbox next to the fund list labelled
'show all'. Checking the checkbox will result in the inactive funds
showing in the pull down list as well.

The patch renames the label to 'Show inactive' to make the purpose
more clear.

To test:
- Create a new order
- Verify the label has changed as described above
- Decide if the change makes sense

Signed-off-by: tadeasm <tadeas.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2015-07-08 14:43:54 -03:00
Katrin Fischer
e835e03ccf Bug 14253: Acq - notify borrowers popup needs to allow scrolling
The 'notify on receiving' patron search on the new order form
in acquisitions didn't allow you to scroll, so there was no
way to select users from the bottom of a longer result list.

To test:
- Create a new order in acquisitions
- On the order form, use the 'Add user' button to open
  the popup
- Perform a patron research with a lot of results
- Verify that with the patch you can scroll, but
  that you couldn't without it

Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
without patch: no scroll bar in Firefox 38
with patch: scrolling works fine

Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2015-06-22 17:07:45 -03:00
Hector Eduardo Castro Avalos
5d3b2c5c2f Bug 14126: Typo on order receive page
A typo found while doing translation:

To test
1) Go to dir 'intranet-tmpl/prog/en/modules/acqui/neworderempty.tt'
   line 268 and check the typo "To notify on reveiving:"
2) Apply the patch
3) Repeat step 1 and check if the typo is fixed

Sponsored-by: Universidad de El Salvador

Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-05-06 10:39:41 -03:00
Jonathan Druart
519c273643 Bug 12648: Link patrons to an order
This patch is the main patch.

This feature adds the ability to link patrons to an order.
On that way, they will be notified when the order is completely
received.

Test plan:
1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl).
code: ACQ_NOTIF_ON_RECEIV, module: acquisition
2/ You can edit it if you want
3/ Create a basket and create an order with 1 or more items
4/ Link 1+ patrons to this order
5/ Close the basket and receive the order
6/ When you have received all items for this order, all patrons attached
will be notified. Check the message_queue table to check if the letters
have correctly been added to the queue.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-03-11 11:47:30 -03:00
Katrin Fischer
9cc7ac68e1 Bug 13593: 'stock number' should be 'inventory number'
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>
2015-02-20 10:57:26 -03:00
Jonathan Druart
d311722445 Bug 12839: aqbooksellers.gstreg is never used
The aqbooksellers.gstreg is never used in the code.
This patch does not remove the DB field but 3 useless occurrences in the
neworderempty page.

The both variable applygst and gstreg have never been took into account for prices calculation.

Test plan:
Verify there is no difference before and after the patch in the prices
calculation.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-12-03 11:34:48 -03:00
Jonathan Druart
499dbca6b8 Bug 12840: The budgeted cost and the total are automatically calculated
Both of these 2 values should not be modified by the user.
Since these values depend on the discount and the quantity.

Test plan:
Verify you cannot modify the budgeted cost and the total price on
creating/modifying an order.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-21 15:47:19 -03:00
b8b200836e Bug 11812 - Add missing "required" indicator to fields which are required
Form fields in the staff client which are required should be configured
to be so by doing several things:

- Add a class "required" to the field's <label>
- Add a class "required" to the form field
- Add 'required="required"' to the form field
- Apppend a <span class="required">Required</span> after the form field.

Several places in the templates are missing the <span>. This patch adds
them.

To test, apply the patch and view the following pages to confirm that
the "Required" text appears:

- Acquisitions -> Add an order to a basket from a new (empty) record.
  Title, quantity, and fund should indicate they are required.

- Administration -> Authority types ->  New authority type. The
  authority type and description fields should indicate they are
  required.

- Administration -> Authority types -> MARC structure -> New tag. The
  tag field should indicate it is required.

- Patron types and categories -> New category. Category code,
  description, and category type should indicate that they are required.
  FIXME: Enrollment period is required but the user must choose one. I'm
  not sure how to handle that clearly.

- Tools -> CSV profiles. Profile name, profile type, and profile MARC
  fields should indicate they are required on both the new and edit
  forms.

- Administration -> Manage MARC modification templates. Under "Create a
  new template" the name field should indicate that it is required.

- Tools -> Batch patron modification -> Submit a batch for editing. Any
  fields which are required according to your BorrowerMandatoryField
  system preference should indicate that they are required.

Patch behaves as expected.
Signed-off-by: Marc Véron <veron@veron.ch>

QA Edits: Re-worded the "required" not on the batch patron edit form,
added a missing word to the help text on that page. On the csv-profiles
page I removed an unnecessary "javascript:" protocol from the markup.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works and passes QA script.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-10-22 14:04:43 -03:00
27f1df0670 Bug 9088: if there is only one active order, pre-select it when creating new orderings
This patch makes the following changes to the template:

[1] If you add an order line, and you have one active fund (and zero or
    more inactive funds), the only active fund is preselected.
[2] If you modify an order line while its fund is inactive, it now shows
    the label (inactive) behind the fund name. (Note that other inactive funds
    may come up when clicking 'Show all' as they did before.)
[3] Corrected some indentation in this template part.

Test plan:

[1] Add an order line while having one active fund. Is it selected?
[2] Add an order line while having two or more active funds. No fund
    should be preselected.
[3] Modify an order line with an active fund. Is it still selected?
[4] Modify an order line with an inactive fund F2 (while having one active
    fund F1; note that this test explicitly wants F1 to be before F2).
    Check if F2 is selected and is labeled inactive.
[5] (Bonus points:) Modify an order line that refers to a deleted fund.
    If you edit this order, the fund combo should say: Select a fund.
    (Note: if you delete a fund, the budget_id in aqorders remains.)

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
I test against master 3.15.00.051
I test against all the three options of the AcqCreateItem:
placing an order
receiving an order
cataloging the record
All is OK.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-25 15:07:49 +00:00
Jonathan Druart
9eee2b5088 Bug 7180: make neworderempty code use getAuthValueDropbox.
The js function fetchSortDropbox has been deleted in previous patch.
The new function is getAuthValueDropbox.

Test plan:
- link authorized values to some funds
- open an existing order and verify value are correctly filled in the
  sort1 and sort2 values
- create a new order and verify behavior is the same as before

Note: This patch generates 2 ajax queries (max) if the budget is linked
to 2 av categories for sort1 and sort2. This could be improved using a
template plugin for values display on load.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-04 19:49:20 +00:00
Pasi Kallinen
9e9088049c Bug 12138 - Use placeholders in translatable Javascript strings
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>
2014-04-27 21:24:04 +00:00
Mathieu Saby
138f14c2b9 Bug 9416: (follow-up) fix neworderempty and templates
This followup answer QA remarks :
- neworderempty.pl updated so that the 2 new variables are passed
  to the template
- modordernotes.tt fixed to make the translation easier
- in CSV headers, to make clear that no change are made for the moment,
  rename "note" to "internal note"

Additionnaly, "Publisher code" was wrong in the csv headers. I changed
it to "Publisher" (the field in database is publishercode, but the
content is a real publisher name, not a code)

I did not change "Note:" in modordernotes.tt, because it is just under
a h1 tag which specifies the type of note the librarian is editing.

Test plan :
- edit an existing order, and try to change/add/delete the vendor note,
  and the internal note. Check the changes are properly saved
- export a basket and a basketgroup in CSV. Check the columns headers
  are "Publisher" and "Vendor note"

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed some tabs. Passes QA script and tests.

Tested:
- add notes when creating an order
- edit notes modifying an order line
- edit notes using the links on the basket summary
- check basket CSV export
- close basket
- check basket group CSV export
- edit notes on order receive page using the links
- edit notes on receive

Note: Translatability of templates could be improved by a follow-up.
It's better not to divide up sentences with if/else structures.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-19 15:55:37 +00:00
Mathieu Saby
36074fba65 Bug 9416: add new order vendor note field
Currently, there is a single note field in each order. It would be
useful to have 2 notes fields:

- one for the staff (ex: "catalog this book as soon as possible")
- one for the vendor (ex: "urgent", "only the 2d volume"...), which
  could later be printed in basketgroup pdf for example

This patch adds a new note made for vendor in each order. The existing
note is renamed "internal note".

The behavior of the 2 notes are the same

Changes in database structure:
- new column aqorders.order_vendornote
- column aqorders.notes renamed aqorders.order_internalnote

To test :
[1] Make a complete acquisiton process (creating the order > looking at
    the basket > looking the order > receiving); and try to use the 2
    notes (internal note / vendor note)
[2] Check the changes made on one page (eg detail of the order) are
    saved and visible on an other page (eg receipt page)

Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-19 15:55:36 +00:00
Jacek Ablewicz
1b0c02376e Bug 11914: fix two issues when creating an order from a suggestion
When order is being created from purchase suggestion:
- Budget/fund stored in suggestion record (if any) is not retained
on order page, system always defaults to 'Select a fund' even if some
fund was already chosen for a suggestion on the earlier stage.
- If there was a price given to, and stored within suggestion record,
initial prices calculations on order page are not working properly
('Replacement cost', 'Budgeted cost' and 'Total' show as 0.00 or blank).
As a workaround - to force correct price recalculation - user needs
to manually alter and then re-alter some price-related fields (e.g.,
quantity or vendor price).

This patch fixes both issues.

Test plan:
1) create a suggestion: choose some buget, enter something in 'Price'
and 'Quantity' fields,
2) try to make an order from this suggestion, to confirm/replicate
aforementioned problems,
3) apply patch,
4) make an order from previously created suggestion again, observe
that both issues are now resolved.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-18 21:59:14 +00:00
Galen Charlton
e276049746 Bug 10922: (follow-up) remove display of form parameter
This patch removes the display of the close parameter
in the "Accounting details" legend added by the previous patch --
this was obviously a bit of stray debug logic.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-23 16:56:40 +00:00
Mathieu Saby
1b56285e22 Bug 10922: Display whether prices are include or don't include tax when creating a new order
This patch adds "(tax inc.)" or "(tax exc.)" after the "Vendor price",
"Replacement cost", "Budgeted cost" and "Actual cost" when entering
a new order.  This reflects the value of the list and invoice prices
include/don't include tax flags in the vendor record.

Actual cost must probably not be displayed here, but it will be the
subject of an other patch.

To test :
- create 2 vendors, with differents values for "List prices includes
  tax" and "Invoiced prices does includes tax" options
- create baskets for these 2 vendors
- create an order in each basket, and look at the "tax. inc." and
  "tax exc" mention. It should be consistent with the options for
  each vendor
- look at an order adding "&close=1" to the normal URL of the order.
  You must see the order without ability to edit it, but with the same
  mentions "tax inc." and "tax exc."

Signed-off-by: Isabelle Beroud <isabelle.beroud@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script.
I have some doubts about the calculations done here, but the
display changes are correct.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-23 16:56:11 +00:00
04aa350777 Bug 8821: make receive shipment page hide inactive funds like new order form
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>
2013-09-16 16:26:12 +00:00
Fridolyn SOMERS
f92c74b65a Bug 7469: put focus on 1st field of creation form instead of search box (Acquisition)
When a user creates a new vendor, a new borrower or a new basket
(maybe on others page too, to be listed), a creation form is displayed,
but the focus is still on the search textbox on page top.

It would be probably better to switch the focus to the first field of
the creation form.

This patch adds the focus, for acquisitions module, on first input for
pages with a data creation or modification or pages with only one form
(like Z3950 search).

Test plan :
Go to pages and look where is the focus :
- acqui/basketgroup.pl : focus on "Basket group name:"
- acqui/basketheader.pl : focus on "Basket name:"
- acqui/invoices.tt : focus on "Invoice no:"
- acqui/modordernotes.pl : focus on "Notes:"
- acqui/neworderempty.pl : focus on "Title:"
- acqui/supplier.pl : focus on "Name:"
- acqui/z3950_search.pl : focus on "Title:"

Signed-off-by: Melia Meggs <melia@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
The focus choice is relevant and works as described.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-09-16 15:53:17 +00:00
dbe233a0e5 Bug 9238 - make fund pull down say 'select fund', not 'select budget'
When adding a new order to a basket the fund selection field is labeled
"Fund:" but the default option is "Select a budget." This patch changes
this string to "Select a fund" and also corrects the associated
JavaScript error message text displayed when one doesn't choose a fund.

To test, add an order to basket. The "New order" form should show
"Select a fund" as the default option for "Fund" in the "Accounting
details" section. If you submit the form without selecting a fund the
error message should read "You must select a fund."

Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
tests pass

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
String updates only, passes koha-qa.pl

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-08-16 16:12:29 +00:00
Fridolyn SOMERS
0d4724e81b Bug 10543 - Unify item mandatory subfields check
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>
2013-07-30 14:47:10 +00:00
5e1f8caf60 Bug 10475 - Item form in acquisition not hiding subfields properly
Subfields hidden in your ACQ framework leave a gap where they used to
be in the item entry form when adding an item to an order. This patch
makes the same change made by 7116 to services/itemrecorddisplay.tt to
correct the problem.

To test:

- Edit your ACQ framework and set some item subfields to hidden in the
  editor.
- Set your  AcqCreateItem system preference to "when placing an order."
- Add a title to an existing basket from an existing record.

The item entry form should display correctly with your hidden subfields
hidden. No whitespace should be left behind where the subfields were
hidden.

Also changed: Invalid "size" attributes on hidden form fields in
neworderempty.tt, stray </li>.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely, passes all tests and QA script.
Thx Owen!

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-07-12 20:40:15 +00:00
Jonathan Druart
da0337b374 Bug 9987: Remove DB field aqorders.biblioitemnunmber
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>
2013-07-02 15:18:50 -07:00
Jonathan Druart
9e4c289d3f Bug 9507: prevent submit: refactor some code in a js file
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>
2013-05-22 07:49:15 -07:00
Christophe Croullebois
3269d358e5 Bug 7228: can't add items in an order with Modify
We have a message if we want to add items and we can't add, substract only.
It's ok if we choose to create items on ordering, in this case koha can't add items, just substract
and in this case we have to delete manually the items(s) in the catalog.
But if via the syspref AcqCreateItem we choose to create items when receiving this limitation is not usefull
The patch just checks if the syspref AcqCreateItem is on 'ordering'
if not the message is not shown and we can add items

Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Here is the test I made for signing off :
after applying the patch
- syspref AcqCreateItem  : create items on RECEIVING
- in a basket, create an order (quantity = 1)
- save the order
- reopen the order
- change the quantity (2 instead of 1)
- save the order
=> changing quantity was not possible before the patch

- syspref AcqCreateItem  : create items on CATALOGING
- in a basket, create an order (quantity = 1)
- save the order
- reopen the order
- change the quantity (2 instead of 1)
- save the order
=> changing quantity was not possible before the patch

- syspref AcqCreateItem  : create items on ORDERING
- in a basket, create an order (click on "add" to add an item => quantity = 1)
- save the order
- reopen the order
- try to change the quantity (2 instead of 1), without clicking on "add" to create a new item => you cannot (alert message)
=> the behavior is the same as before the patch

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Copied test plan from bug report.
Template only change deactivating the Javascript that blocks
you from changing the quantity when AcqCreateItem is set to
something else than 'ordering'.
Passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
2013-05-01 08:22:36 -04:00
Jonathan Druart
ed63c13957 Bug 5343: Link serial and acqui modules
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>
2013-03-22 23:54:43 -04:00
Bernardo Gonzalez Kriegel
b874caed6c Follow-up Bug 9438 - Biblio notes displayed when ordering
This patch re-enables displying Notes when select
Modify order from basket view.

To Test:
1) After applying first patch, Notes are empty when select Modify order
2) Apply patch
3) Now Notes are visible again, unless the order is new.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
2013-03-21 09:42:06 -04:00
Adrien Saurat
12b050a83f Bug 9438: biblio notes displayed when adding order
The biblio notes should not appear in the "Notes" textarea
of the "New order" page, in Acquisitions.

TEST PLAN
1) Find a biblio with a note (for example 300$a in UNIMARC, 500$a
in USMARC), or add a note to a biblio.

2) In a basket, create a new order for that title. Before the patch,
the "Notes" textarea contains the note from the biblio. After the patch
the textarea is empty.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
2013-03-21 09:42:05 -04:00
Liz Rea
60a86dcc31 Bug 9268 - Scanning in barcode or ISBN in Acquisitions -> new order submits the form unexpectedly
To Test:

* Go to Acquisitions - Manage Orders
* Search for a vendor
* Click New Basket.
* Fill required fields
* Press Save.
* Click on "From a new (empty) record"
* Type in title Private Oz, Author Patterson, James.
* Scan (or type) ISBN - 9781864711875.
* (If not scanning, PRESS ENTER HERE)
* Nothing should happen. Form should not be submitted, no error message
  should appear.

Sponsored by: Hauraki District Libraries, New Zealand

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested according to test plan in Firefox and Chromium on Ubuntu.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
2013-01-31 11:40:03 -05:00
Fridolyn SOMERS
714075d5c1 Bug 8942: Translation process breaks javascript
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>
2013-01-31 11:00:24 -05:00
Dobrica Pavlinusic
5ee5693410 Bug 9346 - acqui/neworderempty.pl ignores exchange rates and destroys user data on page load
This restores behaviour of new order form before Bug 5335 merge

Test scenario:

1. load Receipt summary for existing customer
2. take note of Unit cost and Order cost
3. open existing order line and verify that Replacement cost,
   Budgeted cost and Total are not re-calculated on page load
4. change currency and verify that costs are updated
   (change currency to system default and all values should become
   same as vendor price)
5. change Quantity, get alert "You can't add a new item, please create a new order line"
   and verify that Total still reflects correct value

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Elliott Davis <elliott@bywatersolions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
2013-01-07 20:47:38 -05:00