Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a new method to Koha::Calendar that returns a boolean indicating
whether there are any business days between two given dates (exclusive).
Implementation details:
* Returns 1 if any business days exist between start and end dates
* Returns 0 for consecutive days, same dates, or only holidays between
* Uses exclusive range (does not include start or end dates)
* Handles date comparison and timezone normalization
* Efficient early return when first business day is found
This is designed specifically for use cases like detecting missed
business days due to server downtime or scheduling issues.
To test:
1. Apply patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/Calendar.t
=> SUCCESS: All tests pass!
3. Sign off :-D
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Calendars can be configured in a way that all days are closed.
The simplest way to do that is to configure a repeatable holiday for
every day of the week.
With such calendars, searching for an open day will literally take
forever.
This patch sets a hard limit on how many iterations are allowed before
giving up. This limit is set to the arbitrary value of 5000, which
should be large enough to be able to consider there is no open days if
we haven't found any with that many iterations, and small enough to
allow the loop to end quickly
Test plan:
1. Set system preference 'useDaysMode' to 'Use the calendar to push the
due date to the next open day' ('Datedue'). Make sure the existing
circulation rules do not conflict with that setting.
2. Browse to Tools » Calendar
3. Set every day of the week to "Holiday repeated every same day of the
week"
4. Issue an item to a patron
5. Check the box and select 'Renew selected items'
6. The renewal should fail pretty quickly
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
1. Check using git grep command that addDate does not exist
2. Check the patch that addDuration is spelt right
3. Check that tests pass t/Calendar.t
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>
When a holiday is entered, then exceptions generated on a range, there exists both a holiday and exception in
the special holidays table. We should cache the exception over the holiday instead of both
Also, !1 in perl returns '' rather than 0, so we should explicitly set the value
Add blank line to clear pod error from qa tools
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Re-introduce the blank line mentioned in the commit message, it was accidentally removed by automatic formatting
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I didn't introduce the method that is warned about, but adding POD for
it seemed reasonable and will silence the QA Script warning.
Signed-off-by: Emma Perks <Emma.Perks2@uhb.nhs.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch refactors is_exception_holiday and is_single_holiday to
utilise a single _holidays method which combines the logic of the
previous single_holidays and exception_holidays methods.
As Koha::Calendar is instantiated at a branch level, we also move split
the cache into branches too.
Signed-off-by: Emma Perks <Emma.Perks2@uhb.nhs.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Rather than using an array of dates and iterating them, use a hashref
and do a direct lookup
Signed-off-by: Emma Perks <Emma.Perks2@uhb.nhs.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes our use of DateTime::Set and replaces it with a quick
hashref implimentation
Signed-off-by: Emma Perks <Emma.Perks2@uhb.nhs.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
1. Go to tools -> calendar and make sure Sundays are holidays by adding
a holiday on a Sunday and selecting "Holiday repeated every same day
of the week" and "Copy to all libraries" and save.
2. Go to administration -> system preferences and select "Use the
calendar to push the due date to the next open matching weekday
for weekly loan periods, or the next open day otherwise" for the
system preference "useDaysMode" and save the system preferences.
3. Put the below code in a file name test.pl and execute it using
the command "sudo koha-shell -c 'perl test.pl' kohadev"
use Koha::Calendar;
my $calendar = Koha::Calendar->new( branchcode => 'CPL' );
$dt = DateTime->new(
year => 2020,
month => 06,
day => 21
);
print "This is a sunday: " .
$dt->day_of_week . "\n";
my $ndt = $calendar->next_open_days($dt, 0);
print "This is a monday: " .
$ndt->day_of_week . "\n";
4. Without the patch applied, this script
will freeze after printing "This is a
sunday ...". Abort using ctrl-c.
5. Apply patch and run the script again.
The test script will now complete.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
We should use Koha::DateUtils instead of Date::Time directly
This patch simplay replaces calls to now() with a call to dt_from_string()
which does effectively the same thing.
Probably reading the code and verifying changes is sufficient but...
To test:
1 - confirm the files all compile
2 - confirm all tests pass
3 - confirm Koha still works
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Add a bit of missing POD whilst we're working in here
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This reverts commit a693c7243c which
caused regressions.
The original loop compared start date to end date and iterated all the
way to start date equals end date. The alternate implimentation
inadvertantly looped from start date, skipped the first day then
iterated up to one day beyond end date.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
prev_open_days can receive either positive or negative numbers and
then does the right thing with them. However, we weren't also doing this
with the number it receives back from get_push_amt
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This was causing the amount to push by to be incorrectly calculated
Sponsored-by: Cheshire West and Chester Council
Sponsored-by: Cheshire East Council
Sponsored-by: Newcastle City Council
Sponsored-by: Sefton Council
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In a sequence of closed days, we should take into account the nature
of each closed day as we encounter it in order to calculate the amount
to add to reach the next potential closed date. We are now doing this.
Sponsored-by: Cheshire West and Chester Council
Sponsored-by: Cheshire East Council
Sponsored-by: Newcastle City Council
Sponsored-by: Sefton Council
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch will, when appropriate, roll due dates forward by full weeks,
rather than single days.
Sponsored-by: Cheshire West and Chester Council
Sponsored-by: Cheshire East Council
Sponsored-by: Newcastle City Council
Sponsored-by: Sefton Council
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We require next_open_day & prev_open_day to be more flexible. We could
create a separate sub, but that's not very DRY given that they'll do
pretty much the same thing.
So next_open_day becomes next_open_days and prev_open_day becomes
prev_open_days and both functions accept an additional parameter which
determines how many days they add or subtract.
All calls of these two functions have been modified accordingly.
Sponsored-by: Cheshire West and Chester Council
Sponsored-by: Cheshire East Council
Sponsored-by: Newcastle City Council
Sponsored-by: Sefton Council
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The loops for subtraction holiday dates in hours_between and
days_between differed and as such their handling of start and end
boundaries for days also differed. This patch makes them handle the
boundary days consistently.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patchs adds the ability to calculate the end of the suspension date
(debarment date) using the finesCalendar syspref.
Prior to this patch it was never calculating without taking into account
the calendar.
calculated without taking holidays into account.
This was a problem because the restriction could end in the middle of a
period the library is closed.
Test plan:
- Set finescalendar to 'not including days the library is closed'
- Set a circulation condition with no fine/maxfine, but fine days and
max fine days instead
- Check out an item with a due date in the past
- Check the item in and verify the restriction date
- Clean the restriction
- Add holidays to your calendar on the calculated restriction date
- Check the item out again with the same due date in the past
- Check in the item again
- Verify the calculated restriction end date has changed, it's set to the day
after the holiday.
Fines in days restriction calculation is correctly taking calendar
into account.
Sponsored-by: Goethe-Institut
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
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>
The crash is caused by comparing two datetimes where one datetime is
floating and the other one was not. In that case the floating is
converted. Note too that DateTime overloads comparison operators.
This patch clones the two dates first. Puts them in floating both. And
just after that starts comparing etc.
Similar small change in hours_between.
Adding a test where the parameters are swapped for days_between.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Set TZ to America/New York
2 - Checkout item and set due date to '2016-03-09 02:29:00"
3 - Make sure fines are set for the item type, fine mode production,
calculate fines on return
4 - Check in item - invalid date time warning in logs
5 - Apply patch
6 - Check in item - no error
7 - prove t/Calendar.t
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 9031: Use floating instead of UTC
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Squashed the changes for Calendar.pm; will add a follow-up to finally
overcoming the crash on Invalid local time.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
- Remove expiration date calculation in C4::Letter since it's done
when setting the reserve waiting,
- remove expiration date calculation in circ/waitingreserves.pl. Use
the one in DB,
- add a new atomic update that calculate expiration date for
waiting reserves,
- add tests for days_foward function and fix the infinite loop.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch makes koha automatically set expiration date when reserves become
waitting. Also it adds a new syspref "ExcludeHolidaysFromMaxPickUpDelay" that allows to
take holidays into account while calculating expiration date.
Test plan:
- Install this patch and run updatedatabase.pl script,
- allow ExpireReservesMaxPickUpDelay in system preferences,
- set ReservesMaxPickUpDelay to 5.
- Place an hold on a checked out item and check in this item:
The hold's expiration date should be today + 5.
- Allow ExcludeHolidaysFromMaxPickUpDelay in system preferences,
- add holiday during this pickup delay period,
- Create a new hold and make it comes waitting:
The hold's expiration date should be today + 5 + number of closed
day(s).
Also:
- Check that ExpireReservesOnHolidays syspref works again
without ExcludeHolidaysFromMaxPickUpDelay.
- Check that cancel fees apply again if wanted.
Signed-off-by: sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Using a DateTime object with a timezone of America/Santiago
was causing fatal errors for Koha::Calendar->is_holiday
and Koha::Calendar->exception_holidays, when the objects
were truncated to an invalid local time.
Using a floating zone allows us to use the same day, month, year
for comparison purposes without running into the possibility of
creating an invalid local time and thus a fatal software error.
Edit:
While the changes to is_holiday and single_holiday make sense (Jonathan agrees too)
I didn't manage to have them fail, because truncate is not failing in my trials, but
days_between. So to me, it narrows down to have exception_holiday return floating tz
datetime objects so it doesn't break days_between.
Anyway, it is ok to push this patch, and the regression test I provide covers this scenario
I'm describing.
To test:
- Apply the regression tests patch
- Run:
$ prove t/db_dependent/Holidays.t
=> FAIL: Unexpected error due to bad timezone/date combination
- Apply this patch
- Run:
$ prove t/db_dependent/Holidays.t
=> SUCCESS: Tests pass
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
From the POD of Koha::Cache->set_in_cache:
# This is a bit of a hack to support the old API in case things still use it
Let's remove this hack and update old calls.
Test plan:
Look at the results of
git grep set_in_cache
and confirm that there are no more version of the old call (without
hashref as third param)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
s/Koha::Cache->get_instance/Koha::Caches->get_instance
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
https://bugs.koha-community.org/show_bug.cgi?id=11921
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This report had no test plan and no unit tests.
Adding some lines to Holidays.t.
Added a trivial line move in Calendar.pm.
Test plan:
Run t/db_dependent/Holidays.t with and without cache.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with memcached, Cache::Memory and no cache (edit Cache.pm).
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
On the same way as bug 14522, we should use Koha::Cache to cache
exception_holidays.
It's not safe to use a package variable if running under Plack.
There is not test plan, just make sure the changes make sense.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This makes the loop add holidays for each bracnh instead of the calling
branch
To test:
I used memcached-tools to view the cache, clear the cache, and wait for
holidays to regnerate
Have a branches with different holidays
Clear the cache
Do a checkout
View the cache - one libraries holidays are repeated for all branches
Apply patch
Clear the cache
Do a checkout
Library holidays are correctly cached
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
perl -p -i -e 's/^.*set the version for version checking.*\n//' **/*.pm
+ manual adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
this patch adds Koha::Cache functionality to the 'single_holidays' table
it is a performance patch for the problem described in BZ14315, only
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14315
it replaces slooow DateTime holiday objects with simple Ymd strings (19991230), then stores the strings in an @array using Koha::Cache
it does not attempt to add caching to all holiday tables - just the single_holidays table (at this stage
on my test (master-cd9a827); nytprof showed a time reduction of the single_holidays() sub - from 61.7s to 587ms
here are some before/after nytprof runs, (really on master-cd9a827, not 3.20)
http://x1.kohaaloha.com/i/nyt-bz14522-before/home-mason-g-k-3-20-x-Koha-Calendar-pm-1485-line.html#237http://x1.kohaaloha.com/i/nyt-bz14522-after/home-mason-g-k-3-20-x-Koha-Calendar-pm-1485-line.html#280
to test...
1/ add a bunch of single_holidays to your test koha, (my table has 400 holiday rows)
2/ add a loong circ rule for an itemtype (my rule has 140 days)
3/ checkout an item to a user (took me 67 secs)
apply patch...
4/ return item
5/ repeats steps 1..3, (took me 6 secs)
6/ add/change/delete some various single_holidays, via Home->Tools->Calendar
ensure that your various changes have indeed saved correctly
for extra points...
7/ run tests t/Calendar.t and t/db_dependent/Holidays.t, with all tests pass OK
sudo koha-shell -c ' export PERL5LIB=/home/mason/g/k/master ; \
cd /home/mason/g/k/master ; perl t/Calendar.t ; perl t/db_dependent/Holidays.t ' testkoha
8/ run QA tool, with all tests pass OK
sudo koha-shell -c ' \
export KOHA_CONF=/etc/koha/sites/mayo2/koha-conf.xml \
export PERL5LIB=/home/mason/g/k/master:/home/mason/qa-test-tools/ ; \
cd /home/mason/g/k/master ; perl /home/mason/qa-test-tools/koha-qa.pl -c 1 ' testkoha
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
As far as I can tell $sunday is never used. And it seemed to be
scoped to only _init.
The remaining hashiness was cleaned up for the $return_by_hour.
TEST PLAN
---------
1) Apply both patches
2) (Skip this one - file does not exist / MV) prove -v t/db_dependent/Calendar.t
3) prove -v t/db_dependent/Holidays.t
4) prove -v t/Calendar.t
5) perlcritic -3 Koha/Calendar.pm
-- the message corresponds to a comment in the code already
and not this change.
6) run koha qa test tools
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The Readonly and Readonly::XS package are only used in Koha::Calendar.
IMO the added value of there packages does not justify their purpose.
Test plan:
1/ Remove Readonly and Readonly::XS
2/ Open the calendar and confirm you don't get any error concerning missing
dependency
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
* Allow on shelf holds needed to be enabled
* Added some error supression code for undefined string comparison
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The caching introduced by the main patch is not ideal
as it won't work correctly if a persistance engine is used.
However, I have good reason to expect that bug 8089 will
be worked on (because I'm going to do it) so that Koha::Cache
can be used for this prior to the release of 3.16.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch ensures that the package-level cache is updated
when add_holiday() is used. Note that except for the test
case added by this patch, there doesn't seem to be anything
that actually calls ->add_holiday(); it may be better to remove it.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Tomas Cohen Arazi
Koha Development Team
Julian Maurice
Jonathan Druart
Eden Bacani
Nick Clemens
Martin Renvoize
Andreas Jonsson
Andrew Isherwood
Marcel de Rooy
Alex Arnaud
David Cook
Kyle M Hall
Tomas Cohen Arazi
Mason James
Mark Tompsett
Jonathan Druart
Galen Charlton