Commit graph

190 commits

Author SHA1 Message Date
43a4a705bf
Bug 34478: Manual fix - Switch to post, update op, add missing include - basket
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2024-03-01 10:56:42 +01:00
acee057c4c
Bug 34478: Manual fix - edi_ean (cud-ediorder)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2024-03-01 10:56:22 +01:00
18e808240f
Bug 34478: op =~ ^cud- in pl/pm
This is the result of
  bash op_must_start_with_cud-perl.sh

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2024-03-01 10:56:11 +01:00
Emily Lamancusa
461d17b270
Bug 34752: (QA follow-up) perltidy
Signed-off-by: emlam <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-10-18 10:25:55 -03:00
772140dbc6
Bug 34752: Add AV handling to sort1/sort2 on baskets
This patch adds Authorized Value handling for the display of sort1 and
sort2 fields in the acquisitions basket display page.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: emlam <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-10-18 10:25:55 -03:00
06c2b4898b
Bug 28449: Add column with invoice number to basket summary page
At the moment it's quite a lot of clicks to get from the basket
summary to the invoice something was received in. This adds a nice
shortcut by creating a new column for the invoicenumber in the basket
summary table.

To test:
* Make sure you have a basket with some received and unreceived
  order lines
* Verify that the (received) shows for your received lines
* Verify no invoice number or link to it in sight
* Apply patch
* Verify that there is now a column for the Invoice containing
  the invoice number as a link to the invoice
* Test with a staff patron, that doesn't have edit_invoices permission
* Verify that now instead of a link you see the invoice number as text

Be happy, sign off ;)

Note: this doesn't change the CSV export. The way the CSV is built is
quite different to the summary table, so it would be better handled
in a separate bug/patch. The columns are already quite different!

Sponsored-by: The Research University in the Helmholtz Association (KIT)

Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Émily-Rose Francoeur <emily-rose.francoeur@inLibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-09-25 10:53:50 -03:00
2a1d85fc32
Bug 15348: Add estimated delivery date field to individual orders
This patch allows you to specify an estimated delivery date per order.
The specified estimated delivery date is also considered when searching
for late orders and exporting late orders. You can also edit the
estimated delivery date from the late orders page.

Test plan:
1. Update database, rebuild schema, restart services
2. Go to Acquisitions, search for a vendor, and create a new basket
3. Add an order to the basket. When filling in the accounting details,
notice the new 'estimated delivery date' field, but don't add a date.
Save the order.
4. Confirm no date shows in the estimated delivery date column in the
orders table.
5. Modify the order. Add a date in the estimated delivery date field and
save the order.
6. Confirm the date now shows in the orders table.
7. Close the basket.
8. Go to the Late Orders page.
9. Put estimated delivery date from and to parameters in the search
filters on the left. Ensure the from and to dates encapsulate the date
you entered in the estimated delivery date field for the order.
10. Click Filter and ensure the order shows.
11. Select the checkbox next to the order. Click the Export as CSV button.
12. Open the CSV and confirm the estimated delivery date that you
entered shows as expected in the file.
13. Click Edit under the estimated delivery date. Confirm the estimated
delivery date modal pops up with the correct order line number in the
modal header.
14. Remove the estimated delivery date and click Save.
15. Confirm that the estimated delivery date calculated by Koha now
shows in the late orders table.
16. Select the checkbox next to the order. Click the Export as CSV button.
17. Open the CSV and confirm the calculated estimated delivery date
shows in the CSV.
18. Confirm tests pass: t/db_dependent/Koha/Acquisition/Order.t

Sponsored-by: Bibliotheksservice-Zentrum Baden-Württemberg (BSZ)
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2022-09-16 10:36:53 -03:00
Petro Vashchuk
096fd4acfa
Bug 31001: Fix "CGI::param called in list context" warning in basket.pl
CGI param basketno should be explicitly scalar,
or else error log gets flooded with this warning:

AH01215: CGI::param called in list context from
/home/vagrant/kohaclone/acqui/basket.pl line 175, this can lead to
vulnerabilities. See the warning in "Fetching the value or values of a
single named parameter" at /usr/share/perl5/CGI.pm line 412.

This patch fixes it by working with it in a scalar context.
The functionality still remains the same but warning doesn't flood
error log.

To reproduce:
1. Head over to the acquisitions page.
2. Pick existing vendor with email contact info or create a new one.
3. Create a new basket or use existing one, and if it doesn't have
any orders, add a new order to it.
4. Use the "E-mail order" button to send order.
5. Check the error log and find the upper mentioned warning.
(Note: if you're going to test this more than once, you might need
to restart your Plack in order for this warning to get added to your
log file again, reasons of that is that the authors of CGI.pm decided
to "warn only once")
6. Apply the patch.
7. Use the "E-mail order" button again, ensure that the same warning
doesn't get added to the log file again.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2022-07-06 18:29:32 -03:00
049a6bf0dc Bug 29785: Rename Koha::Object->message with ->object_messages
It will conflict with other ->messages methods, it's too generic.

Bug 29230 needs Koha::Patron->messages to return Koha::Patron::Messages for instance.

Test plan:
Confirm that the tests modified by this patch still pass

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
2022-02-09 22:01:36 -10:00
d02e91f269 Bug 29859: Use iterator instead of as_list
On bug 29844 we decided to remove wantarray from Koha::Objects->search.
Reviewing the difference occurrences I found some unnecessary uses of ->as_list,
where iterators should be used instead.

This patch only removes the obvious places, not the tricky ones.

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
2022-02-09 15:36:23 -10:00
e53667105d Bug 29844: Fix ->search occurrences
and some more...

There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
2022-02-09 15:36:23 -10:00
Joonas Kylmälä
5095e0a954 Bug 29283: (QA follow-up) Remove code duplication
We have already a search filter for active orders.

Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-11-02 14:57:09 +01:00
1de960e7e3 Bug 29283: Don't attempt to cancel cancelled orders
When deleting a basket we cancel all the contained orders - when a
basket contains an order that was previously cancelled this can cause
an error if the biblio was deleted

When picking the orders to cancel, we should limit our search
to those not already cancelled.

To test:
- have a basket with at least one order
- click "Cancel order and delete catalog record", confirm cancellation of order and deletion of bib
- click "Delete basket", confirm deletion
- get error "Cannot insert order: Mandatory parameter biblionumber is missing at /kohadevbox/koha/acqui/basket.pl line 136.
 at /usr/share/perl/5.28/Carp.pm line 289"
- apply patch
- restart
- delete the basket
- success!

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>

Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-11-02 14:57:09 +01:00
33dd62d661 Bug 28640: Expose EDI Status on basket details page
This patch adds the edi_order relationship method to
Koha::Acquisition::Basket to return the most recently attached
edi_message of type 'ORDER' for the basket.

NOTE: EDI currently returns raw DBIC results. I have opted to maintain
that approach here, but would like to work on upgradeing the
Koha::EDIFACT::Order class to be a subclass of Koha::Object at a later
date.

We then use this new relationship in acqui/basket to display the EDI
status for such baskets.

Test plan
1/ Setup a vendor with EDI Ordering enabled
2/ Add a new basket for the vendor.
3/ Note the new 'EDI status' field displays and reads 'Not ordered'
4/ Close the basker
5/ The 'EDI status' should continue to display 'Not ordered'
6/ Re-open the basket
7/ Close the basket via 'Create EDIFACT order'
8/ Navigate back to the now closed basket
9/ Note the 'EDI status' field now displays 'Pending' and the transfer
date.
10/ Progress the EDI order by running the edi_cron.pl script
11/ The EDI status field should now reflect that the message has been
sent.

Signed-off-by: Benjamin Veasey <B.T.Veasey@lboro.ac.uk>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-07-26 12:46:32 +02:00
9d6d641d1f Bug 17600: Standardize our EXPORT_OK
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.

That way we will need to explicitely define the subroutine we want to
use from a module.

This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests

And a lot of other manual changes.

export.pl is a dirty script that can be found on bug 17600.

"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;

The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules

Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).

EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.

@EXPORT and @EXPORT_OK are the two main variables used during export operation.

@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.

@EXPORT_OK does export of symbols on demand basis.
"""

If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
  - use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-07-16 08:58:47 +02:00
3fe837bc74 Bug 28572: Remove C4::Debug
We are using Koha::Logger when it makes sense to keep the info,
otherwise we simply remove it

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Bug 28572: Replace missing occurrence in misc/admin/koha-preferences

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-06-22 12:04:32 +02:00
6f204fdf96 Bug 28591: Don't pass debug to get_template_and_user
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!

Test plan:
Confirm the assumption
Review the changes from this patch

Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl

git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-06-22 12:04:32 +02:00
Andrew Isherwood
ac4ac649aa Bug 23971: (follow-up) Remove data duplication
In response to Séverine observations in comment #10, this patch removes
the duplicate logging of the borrowernumber

https://bugs.koha-community.org/show_bug.cgi?id=23971
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-04-23 11:58:49 +02:00
Andrew Isherwood
565726e556 Bug 23971: Add logging for basket related actions
This patch adds logging for the following Acq actions:

- Basket creation
- Basket editing
- Basket approval (via EDI)
- Basket closure

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

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

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

Bug 23971: (QA follow-up) New DBrev syntax

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-04-23 11:58:47 +02:00
a851aaeebf Bug 26584: Remove unused C4::Acquisition::CloseBasket function
This patch makes code use the new Koha::Acquisition::Basket->close
method and makes CloseBasket obsolete.

It then removes it, and adapts the few places in which it was used.

1. Apply this patch
2. Run:
   $ kshell
  k$ git diff origin/master --name-only | grep -e '\.t$' | xargs prove
=> SUCCESS: Tests pass!
3. Try playing with baskets, closing them
=> SUCCESS: All works as expected!
4. Sign off :-D

Signed-off-by: David Nind <david@davidnind.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-11-05 15:24:20 +01:00
Katrin Fischer
2d6595a1bf Bug 26190: Allow to close a basket with only cancelled order lines
At the moment there are several cases, when closing a basket is not
possible:
- when there are no order lines in it
- when there are order lines with uncertain prices
- when the basket is marked as a standing order

The first case wasn't checked correctly as only pending/received
orders would be counted, but not cancelled orders.

To test:
- Create a basket
- Create an order line
- Verify the "close this basket" button shows
- Cancel the order line - the button disappears
- Apply the patch
- Verify the button appears and works now
- Create another basket - make sure you cannot close it
  without order lines
- Create an order line with uncertain price checked
  - you cannot close it
- Resolve the uncertain price - you can now close the basket.

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-11-04 12:59:33 +01:00
870ef9e2d9 Bug 26577: Make basket.pl and cancelorder.pl use ->cancel
This patch makes the mentioned controller scripts use the new
$order->cancel method instead of DelOrder.

To test:
1. Apply this patches
2. Have a basket with some orders
3. Play with cancelling orders and removing baskets
=> SUCCESS: No behaviour change!
=> SUCCESS: No errors!
4. Sign off :-D

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-10-15 14:50:07 +02:00
Julian Maurice
96cc447045 Bug 25898: Prohibit indirect object notation
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-10-15 12:56:30 +02:00
638786e719 Bug 24663: Remove authnotrequired if set to 0
It defaults to 0 in get_template_and_user

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-03 10:40:35 +02:00
8ecaedc22d Bug 21268: Don't remove 0 allocated funds from fund list
If a fund is created with a amount of 0, it will not appear in the fund
list (when a new order is created for instance).
0 allocated funds can be used to track donations and other situations
where there is not an expected amount for the year.

Test plan:
0. Do not apply the patch
1. Create 1 active and 1 inactive budgets
2. Create some funds for each budgets, with amount > 0 and amount == 0
3. Add orders to basket
=> Note that the funds with amount == 0 are not displayed
4. Apply the patch
5. Add orders to basket (using the different possible ways we have)
=> Note that the funds with amount == 0 are displayed

This change is applied to the different views of the acquisition module.

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-07-30 17:44:27 +02:00
6b984a0feb Bug 24157: New permission - delete_baskets
Add a new permission to delete acquisition baskets

Test plan:
- Remove the new permission "delete_basket" for a given patron,
use it to log in into Koha
- Create basket, try to delete it
=> There is no way to delete it
- Add the permission
=> Now you can delete the basket

Sponsored-by: Galway-Mayo Institute of Technology

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-07-30 17:30:23 +02:00
7b66b90fe7 Bug 25750: fix fallback to ecost_tax_included/ecost_tax_excluded
If 'Actual cost' has not been set then it has the value of 0.00 which
Perl evaluates to true so this patchset resets it to 0, so the fallback
to ecost_tax_included/ecost_tax_excluded happens.

Test plan:
1. Add item to acquisition basket (make sure the vendor has: tax rate: 15%, 'List prices: Include tax', 'Invoice prices: Include tax')
2. Set 'Vendor price' = 10 and do not set 'Actual cost'
3. Save order
4. Observe basket.pl shows 'Total tax exc.' has a value of 0.00 and GST
column has value of -8.70

5. Jump into the database:
select tax_value_on_ordering from aqorders where
ordernumber=<ordernumber>;
[You can get the ordernumber from clicking on the 'Modify' line the item
is listed in]
6. Observe a negative value: -8.70

7. Apply patch and restart plack
8. Add a second item to the basket
9. Set 'Vendor price' = 10 and don't set 'Actual cost'
10. Save order
11. Observe basket.pl shows 'Total tax exc' has value of 8.70 and GST
has value of 1.30
12. Repeat step 5 and observe tax_value_on_ordering = 1.30
13. Run t/Prices.t unit test:
sudo koha-shell <instancename>
prove t/Prices.t

Sponsored-by: Horowhenua District Council, NZ

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-07-09 11:50:42 +02:00
d2c2e7740f
Bug 24161: Keep tracks of late orders claims
So far we only record the number of claims and the date of the last
claim, in the aqorders table.
To keep track of the different claim dates, this patchset is going to
make the following DB changes:
  * Create a new table 'aqorders_claims' (id, ordernumber, claimed_on)
  * Remove the two columns from the aqorders table: claims_count and
  claimed_date

This will allow to display the different claim dates where needed: on
the late orders page, and the basket page.

To avoid additional fetches of Koha::Acquisition::Orders, GetLateOrders
has been moved to Koha::Acquisition::Orders->filter_by_late
That way we are going to add consistency, robustness, and cover the
feature with new tests.

Test plan:
0/ Create a bunch of new orders. Make sure they are from different
vendor (with different delivery time).
1/ Go to the late orders page and claim some orders
2/ Reclaim some of those orders
3/ Confirm that you can see the different claim dates for a given orders
(the history of the late orders claims is kept and displayed)

4/ Bonus point: Regression tests:

a. Modify the closedate of the basket in the database. That
will allow you to make sure the patch set did not introduce regressions.
It would be good to test the different filters on the late orders page:
 * delay
 * Estimated delivery date from/to
 * Vendor

b. Confirm that the subtotal and the total values from the late orders
page is correct.

c. Test the update database entry: do not apply these patches, claims
some orders against master. Apply the patch, execute the update DB entry
then confirm that the number of claims is correct (note that the dates
will not as it is not possible to guess them).

QA note: the branchcode parameter has been removed from filter_by_late.
At first glance it seems that it was not used.

Sponsored-by: Cork Institute of Technology
Signed-off-by: Angela O'Connor Desmond <angela.oconnordesmond@staff.ittralee.ie>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-05-04 09:44:44 +01:00
a28e1928d3
Bug 21746: Remove NO_LIBRARY_SET
NO_LIBRARY_SET was used when the DB user was logged in. Since bug 20489
it's not longer possible. We could remove the code.

One occurrence left in C4::InstallAuth as there is no (real) logged in user yet.

Test plan:
* Install Koha to make sure NO_LIBRARY_SET is not needed during the
install process
* Login into Koha
* Make sure the your library's name is displayed correctly in the header
* Set another library
* Confirm that the library's name is updated

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No problem during install, nor changing library.
Fixed (pre-existing) tab in circ/branchtransfers.pl
No errors

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-02 10:20:42 +00:00
77979a03b4
Bug 24467: Remove _count methods introduced for API use
This patch removes some methods that were introduced for API usage in
the first iteration of the object embedding development effort.

Those methods were obsoleted by bug 24528, which introduces a smarter
way for Koha::Object->to_api to embed *_count attributes on the output
structure based on the relationships and a call to ->count.

To test:
1. Apply this patch
2. Run:
   $ kshell
  k$ prove t/db_dependent/Koha/Biblio.t
=> SUCCESS: Tests pass
3. Sign off :-D

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-01-31 13:50:52 +00:00
f31993d126
Bug 24430: Remove CountBiblioInOrders and its traces
This patch replaces the only uses of CountBiblioInOrders and makes that
code use $biblio->orders->count instead.

Test nothing breaks in basket.pl and parcel.pl

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-01-21 11:21:57 +00:00
fad70512c0
Bug 11514: Untranslatable "Uncertain" text in acq
This patch modifies two pages so that the "Uncertain price" information
is shown by the template rather than the Perl script, making the text
translatable.

To test, apply the patch and go to Acquisitions.

 - Locate or create an order in a basket which has an uncertain price.
 - When viewing the contents of that basket the order which was marked
   as having an uncertain price should be labeled "Uncertain."
 - The same should be true for the invoice page. If you don't have an
   existing invoice with an "uncertain" order,
   - Go to "Receive shipments" for the vendor your "uncertain" order is
     with.
   - Create a new invoice.
   - Receive one or more orders which has an uncertain price.
   - Press the "finish receiving" button.
   - In the "Invoice details" section of the invoice page you should
     see the "Uncertain" label on the correct order.

Signed-off-by: Christophe Croullebois <christophe.croullebois@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
For the invoice view: close, receive, reopen, mark prices uncertain, go
to the invoice page (not sure it's expected however)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-11-06 16:54:42 +00:00
73c0100a3d
Bug 23522: (QA follow-up) Typo fix in comment
Tiny typo fix in a new code comment

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-11-05 08:12:30 +00:00
39bc68c90b
Bug 23522: Show actual price on in baskets
To test:
 1 - Create a new basket in acq, mark it as 'standing'
 2 - Add an item, leave the RRP and Vendor price as 0
 3 - Receive shipments for the vendor
 4 - Select the title from this basket
 5 - On receipt enter an actual cost
 6 - Finsih receiving
 7 - Go to the basket
 8 - Note the total for the order and the basket are 0, keep this browser tab open
 9 - Open a new browser tab and create a new non standing basket
10 - Add to basket, again with no RRP or vendor price
11 - Close the basket, receive the item
12 - Enter an actual cost on receipt
13 - Return to view the basket
14 - Total and order are $0
15 - Apply patch
16 - Refresh the basket in both tabs
17 - You now see the actual price for the orders

Signed-off-by: Rhonda Kuiper <rkuiper@roundrocktexas.gov>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-11-05 08:12:29 +00:00
7fe5f8cd2c Bug 18736: Use rounding syspref to determine correct prices in calculations
To test:
Place an order (no tax just for simplicity)
 listprice/rrp = 16.99
 discount = 42%
 quantity = 8
 estimated calculated at 9.85
 but order total is 78.83, but 8 times 9.85 = 78.80
Apply patches, set OrderPriceRounding syspref to 'Nearest cent'
Not order total is now as expected
View ordered.pl and confirm values are correct
Complete order, view invoice and confirm values
View spent.pl and confirm values
Go through acquisitions module and confirm prices throughout are
correct.

Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-21 16:27:09 +00:00
8035151e41 Bug 15774: (follow-up) Address QA issues
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-07 20:37:05 +00:00
Julian Maurice
904a488460 Bug 15774: Use Koha::Object(s) for additional fields
A lot of code can be removed just by using Koha::Object

It also makes fetching and updating additional field values easier.

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>

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

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-07 20:37:05 +00:00
Jesse Weaver
84f8301229 Bug 15774: Add additional fields to order baskets
This also moves the admin page for additional fields for all tables to a
single common screen, and factors out display/input parsing logic.

Test plan:
  1. Create an additional field for a subscription (under Serials -> Add
     subscription fields).
  2. Apply patch.
  3. Visit Additional fields under administration, and verify that
     the field created above still shows under the list for the
     subscription table.
  4. Create at least four fields for aqbasket for each combination of
     searchable/not-searchable and with/without an authorized value.
  5. Create an order basket, and verify that all fields are visible and
     correctly save.
  6. Edit the basket, verifying that changes to these additional fields
     are saved.
  7. Add an order to the basket (contents are irrelevant).
  8. Go to advanced search within acquisitions.
  9. Verify that only the searchable fields show in the form, and that
     their contents may be searched.

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>

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

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-07 20:37:05 +00:00
7d10549ae8 Bug 21205: Replace C4::Items::GetOrderFromItemnumber calls
This is done to ease the move of C4::Items (bug 18252) to Koha::Items

  my @itemnumbers = GetItemnumbersFromOrder($order->{ordernumber});
will become
  my @itemnumbers = $order_object->items->get_column('itemnumbers');

Test plan:
- Create an order with several items
- Receive some items

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

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-11-08 20:47:16 +00:00
af82a1d597 Bug 21033: Remove few warns in acqui/basket.pl
Resolve (line numbers based on 16.11.x):
Use of uninitialized value in hash element at acqui/basket.pl line 337.
Use of uninitialized value in hash element at acqui/basket.pl line 338.
Use of uninitialized value in hash element at acqui/basket.pl line 340.
Use of uninitialized value in hash element at acqui/basket.pl line 342.
Use of uninitialized value in hash element at acqui/basket.pl line 344.

Argument "" isn't numeric in multiplication (*) at koha-tmpl/intranet-tmpl/prog/en/modules/acqui/basket.tt line 486.
Argument "" isn't numeric in multiplication (*) at koha-tmpl/intranet-tmpl/prog/en/modules/acqui/basket.tt line 591.

Test plan:
If you have older acq data, you may have records in aqorders with field
tax_rate_on_ordering is NULL. These orders will trigger the above warns.
If you do not have, you could simulate by setting this field to NULL.

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

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-09 11:31:44 +00:00
7e21ffe6c5 Bug 19200: (QA follow-up) Simplify call to GetBasketAsCSV
If no profile_id is passed, GetBasketAsCSV will fallback to default itself.
No need to make the distinction in basket.pl.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-12-22 13:15:35 -03:00
Aleisha Amohia
809175f3d4 Bug 19200: Preventing warns when exporting a basket
To test:
1) Go to Tools -> CSV profiles -> New CSV Profile
2) Create a new CSV profile with any name of SQL fields. Ensure profile
type: SQL and usage: basket export in acquisition
3) Go to Acquisitions -> Find or create a vendor -> Use or create a
basket
4) Click the dropdown menu next to the 'Export as CSV' button. There
should be a 'Default' option and your new CSV profile (at least)
5) Click the 'Default' option. Notice warns
6) Click the 'Export as CSV' button. Notice warns
7) Click your new CSV profile option. Notice warns
8) Apply patch and refresh page
9) Repeat steps 5-7, confirm that warns do not show
10) Confirm export still works as expected

Sponsored-by: Catalyst IT

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-12-22 13:15:35 -03:00
04aea91de0 Bug 15685: (QA follow-up) Address QA issues
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-11 13:08:47 -03:00
Jesse Weaver
b29493265b Bug 15685: Allow creation of items (AcqCreateItem) to be customizable per-basket
This adds a new basket attribute (create_items) that can optionally be
set to override AcqCreateItem.

The following have been modified to reflect this (with the value of
create_items that causes them to behave differently in parentheses):
  * Cancelling receipt of an order (receiving)
  * Creating an order by hand or from MARC (ordering)
  * Receiving an order (receiving)
  * Showing orders with uncertain price (ordering)
  * Showing orders (receiving)
  * Showing acquisition details in the OPAC (ordering)

Test plan:
  1) Create baskets with "Create items when:" set to ordering,
     receiving, cataloging and unset.
  2) Test each of the above for each of these baskets, verifying that
     the basket-specific attribute overrides AcqCreateItem if set and
     falls back to the syspref otherwise.

NOTE: A check of AcqCreateItem in opac-detail.tt was removed because it
was redundant; the code path in question cannot be triggered unless
create_items/AcqCreateItems is set to the correct value anyway.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Barbara Fondren <bfondren@roundrocktexas.gov>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-11 13:06:06 -03:00
Colin Campbell
f59484df22 Bug 19340: Read basket details of transfer partner
Details of the basket an order is tranferred to or from
are displayed in the basket display.
Unfortunately these details were not being read so
the display incorrectly showed the details
of the current owning basket.

Signed-off-by: David Bourgault <david.bourgault@inlibro.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-09 16:02:51 -03:00
Aleisha Amohia
06b602b097 Bug 19180: [FOLLOW-UP] Renaming all instances of 'name' variable to 'booksellername'
... when referring to the name of the vendor.

To test:
1) Confirm vendor shows on webpage title (tab name)
2) Confirm vendor shows in breadcrumbs
3) Confirm vendor shows in heading when viewing basket ('Basket x (1) for
vendor')

Sponsored-by: Catalyst IT

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-09-19 11:47:33 -03:00
Aleisha Amohia
438a3dea0c Bug 19180: Add vendor name to breadcrumbs when closing an order
To test:
1) Go to Acquisitions
2) Find a vendor and a basket
3) Click 'Close basket' button
4) Notice that on confirmation page, breadcrumbs are missing vendor
5) Apply patch and refresh page
6) Vendor name should now show
7) Confirm link to vendor works as expected

Sponsored-by: Catalyst IT

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-09-19 11:47:33 -03:00
Aleisha Amohia
6ed1513e5f Bug 19257: Prevent warn when reopening a basket
To test:
1) Go to Acquisitions, find a vendor and a basket (create if you don't
have either)
2) Close the basket
3) View the basket and reopen it
4) Notice the warn
5) Apply the patch and repeat steps 1-3
6) Notice the warn no longer shows and the basket is reopened as
expected

Sponsored-by: Catalyst IT

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-09-07 14:38:22 -03:00
70eafe4484 Bug 18259: [QA Follow-up] Replace variable name
The variable name has_subscriptions implies that it is a boolean. In reality
we save the number of subscriptions into it. Renaming has_ to cnt_.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-07-14 12:02:30 -03:00
035e0beb8c Bug 18259: Koha::Biblio - Remove GetSubscriptionsId
C4::Biblio::GetSubscriptionsId can be replaced using
Koha::Biblio->subscriptions

Test plan:
Create a new order for a bibliographic record
Create a new subscription on this biblio
From the basket (acquisition), confirm that you are not able to delete
the order with the biblio ("Can't cancel order and delete catalog record
1 subscription(s) left")
Receive the order
On the parcel page, confirm that you are not able to delete the order
with the biblio

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

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-07-14 12:02:30 -03:00