* Add POD to get_table_settings
* Remove USE Dumper debug statement
* Add missing "10" entry
* Fix newly created test file (and renamed)
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch is the main patch of this patchset, you will find the
description and the test plan.
The idea of this new enhancement is to add the ability to define the
default sort order and the default number of rows displayed on the
acquisition basket page.
The existing "columns settings" feature was replaced by a
"tables settings" feature. To prepare the ground, there were some
works that were needed:
* rename variables and files
* Modify the structure of the yml files
* Create a new DB table to store the tables settings
Test plan:
0)
a. Execute the update DB entry to create the new table
b. Restart all (to get a new version of the yml file, that is cached by
memcached)
c. Create several orders for a given basket
1) Go to the basket view page
=> The default values are the same than without this patchset, the
number of entries to display is set to "20" and the table is sorted by
basket number (first column)
2) Go to the "Columns settings" page
3) Unfold the "Acquisition" tab
=> Notice the 2 dropdown lists at the bottom of the basket table
4) Select different values for "Default display length" and "Default
sort order"
5) Refresh the basket view page
=> Notice that the default settings are now effective on the table
QA note: We can decide to replace the different occurrences of "Columns settings"
by "Tables settings" if needed.
Sponsored-by: Institute of Technology Tallaght
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are preparing the ground with this patch. As the "Columns settings"
page will now add the ability to modify settings for the whole table, it
makes sense to rename the file and the variables.
Note that the controller script (admin/columns_settings.pl) and the yml
(admin/columns_settings.yml) files have not been moved to not break
shortcuts and abits people could have. But if QA decides, it could be
easy to do.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch changes the new circulation rule that's introduced from
useDaysMode to daysmode to improve consistency with other rule names.
We also update the accessors and code using them to reflect the new
term.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are 3 other occurrences where the new circ rule can be used:
* C4::Circulation::checkHighHolds
* Koha::Hold->set_waiting
* misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl
Test plan:
* checkHighHolds
Enable decreaseLoanHighHolds and fill decreaseLoanHighHoldsDuration
Setup things to hit a "high demand" alert with a shortened due date
Check an item out
=> The due date must be recalculated depending on the circ rule useDaysMode.
* set_waiting
Set ExcludeHolidaysFromMaxPickUpDelay to "1" (note that there is currently
a bug in the description of the syspref, see bug 22381 comment 19)
Mark a hold waiting
The expiration date should have been set depending on the value of the
circ rule.
* TalkingTech cronjob
Cannot test this
Signed-off-by: Simon Perry <simon.perry@itcarlow.ie>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Moving the useDaysMode system preference to a circulation rule will add
much more flexibility in the calculation of the due date.
The initial request was to make hourly loan returned on closed when
(when checked out on the same close day).
To do so we do not want to take into account the calendar.
However the calendar need to be taken into account for other loan item types.
Other scenarios are possible, for instance depending on the branch.
This patchset will add a new "Days mode" column (next to "Loan period")
to the circulation rules page, with the different values of the
"useDaysMode" system preference + a "default" value, to default to the
system preference value.
Test plan:
- Define a long loan item type (like 10 days) that will use the calendar
(or default to the pref value, if the pref is not set to "ignore the
calendar")
- and a hourly loan (like 2 hours) that will ignore the calendar
- Create items with those item types
- Mark today as a closed day
- Check the items out
=> The hourly loan is due the same day
=> The other loan is due on an open day
QA note:
There is the need to force the "days_mode" option when Koha::Calendar is
initiated for the due date calculation. To make sure devs will not
forget it, the methods that need have it defined will throw an
exception.
Sponsored-by: Institute of Technology Carlow
Signed-off-by: Simon Perry <simon.perry@itcarlow.ie>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is a companion/alternative to bug 25184, in that it allows an
explicit workflow for placing returned books into temporary storage for
a few days for decontamination purposes.
The idea here is to create a specific notforloan value for "In
Decontamination" or something along along those lines. This notforloan
value would never be trappable. At the end of decon,
UpdateNotForLoanStatusOnCheckin could be used to remove the
notforloan status and allow checkins to be trapped to fill holds.
Test Plan:
1) Apply this patch
2) Restart all the things!
3) Give an item a negative notforloan value
4) Place a hold on the item
5) Check the item in
6) Note the item is trapped for hold
7) Set SkipHoldTrapOnNotForLoanValue to the same notforloan value
you used in step 3
8) Check the item in again
9) Note Koha did not ask you to trap the item for hold!
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This bug is basically the same as bug 24966, but for hold_patron_name instead of hold_patron_bcode.
The subroutine hold_patron_bcode should always return an empty string, not undef.
Test Plan:
1) Using the SIP cli emulator, checkin an item that is not checked out
2) Note the DA field contains someting like "C4::SIP::SIPServer=HASH(0x88175c8)"
The hex number will almost certainly be different from this example
3) Apply this patch
4) Restart the SIP server
5) Run the SIP checkin again
6) Note the DA field is no longer present!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Automatic authority creation assumes that if we don't match we need a new authority.
Using the Default linker, however, we don't match if there exists more than one match.
This leads to repeatedly generating authorities once there is a duplicate in the system
We shoudl instead only create a new authority if there are no results
To test:
1 - Set Linker Module to 'Default'
2 - Enable AutoCreateAuthorities and BiblioAddsAuthorities and CatalogModuleRelink and LinkerRelink
3 - Add two copies of a single authority via Z39
4 - Add a heading for that authority to a bib record
5 - Save the record and note a new authority is generated
6 - Repeat and see another is generated
7 - Apply patch
8 - Restart all the things
9 - Save the record again, no new authority created
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 23934 removed the limitation that prevented item level holds from
getting local holds priority. The problem is the code has never checked
if the item level hold matches the given item! This means the wrong item
may be requested to fill an item level hold.
Test Plan:
1) Create 3 items on a record
2) Place a hold for the 2nd item you created
4) Ensure that hold would be picked up by local holds priority
5) Build the holds queue
6) Note the holds queue is asking for the wrong item!
7) Apply this patch
8) Rebuild the holds queue
9) Holds queue should now be asking for the correct item!
Signed-off-by: Kim Peine <kim@williston.lib.vt.us>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The holds queue builder does not honor
the new item_level_hold flag. Instead, it only item_level_request if
in the loop dealing with item level holds. This is incorrect. Item level
holds may be trapped in the local holds priority loop as well. It's
trivial to just pass though the correct item/biblio level hold flag.
I do not know how to write a reproducable test plan for these issues.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kim Peine <kim@williston.lib.vt.us>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
WWW::YouTube::Download is broken and not reliable.
Other alternative was to use HTML::Video::Embed but not updated since
years.
The best alternative seems to follow youtube advise and use an iframe
https://developers.google.com/youtube/iframe_api_reference
Test plan:
Put youtube video in 856$u (using different url formats, youtu.be,
youtube.com/embed, etc.)
Enable HTML5MediaEnabled and HTML5MediaYouTube and confirm that the
youtube videos are correctly embeded.
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This was the only occurrence of GetBooksellersWithLateOrders and it was
the only subroutine of C4::Bookseller
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It seems that this regression comes from bug 14419, but I have not found
a logic reason behind that.
This patch restores the behaviour we always had: facet groups must be
displayed in a given order: the Zebra index (au, ccode, holdingbranch,
etc.)
Test plan:
Apply this patch, restart all and confirm that the facets are not moving
up and down when you refresh your search result page.
QA note:
I think the following line must be removed
@facets_loop = sort {defined $a->{expand} && defined $b->{expand} && $a->{expand} cmp $b->{expand}} @facets_loop;
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In order to prevent typos or further regressions it is better (I think)
to have this code into a loop
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the code set the *_storage fields when adding new
fields to an existing course item. And reverts those fields correctly
when removing the item from the course.
If a new field is enabled on an existing course reserve, the storage
field is not given a value, so when the item goes off reserve, the
item field will always be updated to NULL.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/CourseReserves/CourseItems.t
=> FAIL: Tests fail, data is not reverted correctly
3. Apply this patch and repeat 2
=> SUCCESS: Tests pass! Data is correctly reverted
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As we are now removing them from MarkIssueReturned they should not be
removed from AddReturn as well.
Also I think this will fix a regression, if $doreturn is not set (in
case the item is withdrawn and BlockReturnOfWithdrawnItems or the item
is lost and BlockReturnOfLostItems, and other specific cases).
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It's quite hard to know where this need to be fixed.
it can be either MarkIssueReturned or LostItem, depending on the
different cases we want to handle.
This patch picked MarkIssueReturned, but maybe the similar code in
AddReturn needs to be removed then.
== Test plan ==
1. Set MarkLostItemsAsReturned to 'from items tab of the catalog module'
2. Set AutoRemoveOverduesRestrictions to 'Do'
3. Set up an overdues restriction in the notice triggers
4. Check out an item and let the overdues process restrict the account
5. Navigate to the moredetail.pl page (items tab) for the overdue item
6. Mark the item lost
7. Return to the account in question - notice the item has been returned, but the restriction remains
8. Clean state: remove restriction + remove item lost status
9. Apply patch
10. Redo the test but this time in addition to the item being returned,
the restriction will be lifted.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Now that we have the reserve_id PK on the reserves table we should use
it (instead of the couple borrowernumber, biblionumber)
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To make sure we are going to display the correct hold's info we need to
pass the reserve_id.
== Test plan ==
1. Add some content to HOLD_SLIP notice, e.g.
<h2>[% branch.branchname %]</h2>
<div>[% biblio.author %]<br>[% biblio.title %]<br>[% item.barcode %]
<ul><li> Reserve ID: [% hold.reserve_id %]</li>
<li>Expiration date: [% hold.expirationdate %]</li></ul>
2. Add 2 holds for 1 patron to a single record
3. Check the reserve IDs in the reserves table - on a clean sandbox, they will be 1 and 2
4. Check in one of the items from the record and print the slip
5. Note that the reserve ID on the slip is 2 and the expiration date is blank
6. Repeated check ins do not change this
7. Check in a second item from the record
8. Note that the reserve ID for this hold is also 2, but this time the expiration date is filled in
9. Check in the first item again - the reserve ID stays as 2, but this time the expiration date is filled in
10. Apply patch
11. cancel the holds to come back to a clean state
(and maybe ensure items aren't in transit)
12. redo the test and see the following differences
13. 1st checkin:
1. expiration date ok
2. the reserve ID is the one of the first hold
14. 2nd checkin:
1. expiration date ok
2. the reserve ID is the one of the second hold
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If think this case does not apply to real-life, but the logic needs to
be fixed.
If an item is due now, and AddReturn is called now with a return date in
the future, the issue is overdue and the patron must be debarred.
However it is not as we compare with now and not the return date
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In an OO package, the logger initialization should happen in the
constructor. This is not an OO package and the initialization is
happening on loading it. This is a wrong behaviour and certainly breaks
in environments where initialization cannot happen (package building,
for example). There could be several options to solve this, as it is
used in a single sub on this package, I opted for initializing on that
sub.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
== Test plan ==
1 - Have two patrons with userids and no cardnumber
2 - Note which of these has the higher borrower number
3 - Use the SIP cli emulator to connect and checkout a book to the patron with higher borrowernumber
See example after
4 - Note the book may checkout to the wrong patron!
5 - Apply patch
6 - Checkout to both patrons via sip
7 - The patrons get the correct checkouts
=== SIP CLI emulator ===
./misc/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -su term1 -sp term1 \
-l CPL --patron 23529001000463 -m checkout --item 39999000001259
translation: via the koha user term1, checkout item 39999000001259 to
patron 23529001000463
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch implements the use of the ViewPolicy record processor filter
inside C4::Search::searchResults. The idea is that the $record_processor
is instantiated once and reused inside the loop. This leaves options for
further optimizations I will do on a follow-up bug.
The filter is applied to the MARC data before it is passed to the XSLT
processor.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Search.t
=> FAIL: This is not implemented, tests fail
3. Apply this patch
4. Repeat 2
5. Feel the joy in your body from a long standing bug being solved
6. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes use of the 'variables' parameter in XSLTParse4Display
method in the different places that it is used in the OPAC. It does by
passing this parameter with
anonymous_session => 1|0
The value will depend on the output from get_template_and_user (i.e. if
there's a returned borrowernumber).
A special case takes place in search results, as the call to
XSLTParse4Display happens in C4::Search::searchResults. So a new
parameter 'xslt_variables' is added to it.
To test:
1. Apply the [DO NOT PUSH] patch
2. Open the OPAC in your browser
3. Try detail pages, search results, tags and lists/shelves pages with
or without an active session
=> FAIL: It always says (somewhere) 'Anonymous session: Yes'
4. Apply this patch, restart_all
5. Repeat 3
=> SUCCESS: It will tell the Yes/No correctly regarding anonymous
sessions!
6. Sign off :-D
Sponsored-by: Universidad ORT Uruguay
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Koha::Account->add_credit is expecting a positive amount.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
* We should not call Log::Log4perl directly
* Not sure it is correct as I get from (comment 77):
% koha-sip --restart
[2020/04/23 11:23:27] [ERROR] [undef]@[undef]: Argument "0.33_01" isn't
numeric in numeric lt (<) at /usr/share/perl5/Net/Server/Log/Sys/Syslog.pm
line 42.
C4::SIP::Trapper::PRINT /kohadevbox/koha/C4/SIP/Trapper.pm (24)
Why "ERROR" when it's a warning?
The [undef]@[undef] seems wrong here.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Now that we have Koha::Logger, we should use it in our SIP server. This
has the potential to make debugging SIP issue much easier. We should add
the userid for the sipuser to the namespace so we can allow for separate
files per sip user if wanted.
Test Plan:
1) Apply this patch set
2) Update the modififed log4perl.conf to your system
3) Restart your sip server
4) Tail your sip2.log, run some queries
5) Note you still get the same output messages as before, with the
addition of the ip address and username ( if available )
prefixing the message.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Lines can be moved. Deletion can be done too if skip_merge is not set.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It's entirely possible that some libraries are relying on the current
before for part of their workflow. Do to this possibility, it seems like
a good idea to control this behavior via a system preference.
Test Plan:
1) Apply this patch set
2) Run updatedatabase.pl
3) Set TrapHoldsOnOrder to "don't trap"
4) Set an item's notforloan value to -1
5) Place a hold on that item
6) Check in the item
7) Note the item is not trapped for hold
9) Set TrapHoldsOnOrder to "trap"
10) Check in the item
11) Koha should now ask if you'd like to trap the item for the hold!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Negative notforloan statuses should allow holds to be placed but not captured.
Due to coronavirus, we have libraries setting all returned materials to a negative notforloan value of Quarantine for several days.
They're using UpdateNotForLoanStatusOnCheckin to set that status automatically. However, those items are still capturing for holds,
even though those items cannot be checked out until the notforloan status is removed.
In cases like an On Order item where we do want the hold to fill at checkin,
UpdateNotForLoanStatusOnCheckin should be used to clear that notforloan status so the hold can fill.
In master, if I set an item to a not for loan but holdable status ( < 0 ) I can place the hold,
capture the hold and set it to waiting, but *not* check it out to the patron!
This does not make sense. I should not be able to trap an item for checkout unless it can be checked out.
Test Plan:
1) Set an item's notforloan value to -1
2) Place a hold on that item
3) Check in the item
4) Trap the item for that hold
5) Attempt to check the item out to the patron, you will be unable to
because it is notforloan
6) Apply this patch
7) Restart all the things!
8) Repeat steps 1-3
9) The screen should no longer ask if the item should be trapped
to fill the hold!
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Catherine Ingram <Catherine.Ingram@cedarparktexas.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch fixes 2 other occurrences. The first one is in POD of
AddReserve, the other one fixes SIP code
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The parameter is branchcode, not branch.
Test plan:
Place a hold on a biblio using ILSDI
Check that the branchcode is correctly filled with the patron's library
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
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>
To test:
1) Create translation files for a new language
( cd misc/translator; ./translate create xx-YY)
A new language means one that isn't already in Koha, xx-YY=>something you
invent.
2) Verify double encoding
egrep "Aix-Marseille|Jean Prunier|periodika|Bokm" misc/translator/po/xx-YY-*
check strange strings
3) Apply the patch
4) Create po files again
( cd misc/translator; rm -f po/xx-YY*; ./translate create xx-YY)
5) Verify no more double encoding
egrep "Aix-Marseille|Jean Prunier|periodika|Bokm" misc/translator/po/xx-YY-*
check normal string
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
At some point some calls to maybe_add got an extra $server var in their
parameter lists. This doubled parameter does nothing and should be
removed.
Test Plan: No change in behavior should be noted
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
