QA tools complains about:
Apparent command =cut not preceded by blank line.
Trivial fix.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Zeno Tajoli <z.tajoli@cineca.it>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The item search needs to join on biblio_metadata to allow search on
marcxml field
Test plan:
Launch complex item searches (using marc fields).
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Zeno Tajoli <z.tajoli@cineca.it>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Two discussions on koha-devel lead to the same conclusion:
biblioitems.marcxml should be moved out this table
- biblio and biblioitems
http://lists.koha-community.org/pipermail/koha-devel/2013-April/039239.html
- biblioitems.marcxml & biblioitems.marc / HUGE performance issue !
http://lists.koha-community.org/pipermail/koha-devel/2016-July/042821.html
There are several goals to do it:
- Performance
As Paul Poulain wrote, a simple query like
SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY publicationyear;
takes more than 10min on a DB with more than 1M bibliographic records
but only 3sec (!) on the same DB without the biblioitems.marcxml field
Note that priori to this patch set, the biblioitems.marcxml was not
retrieved systematically, but was, at least, in
C4::Acquisition::GetOrdersByBiblionumber and C4::Acquisition::GetOrders
- Flexibility
Storing the marcxml in a specific table would allow use to store several
kind of metadata (USMARC, MARCXML, MIJ, etc.) and different formats (marcflavour)
- Clean code
It would be a first step toward Koha::MetadataRecord for bibliographic
records (not done in this patch set).
Test plan:
- Update the DBIC Schema
- Add / Edit / Delete / Import / Export bibliographic records
- Add items
- Reindex records using ES
- Confirm that the following scripts still work:
* misc/cronjobs/delete_records_via_leader.pl
* misc/migration_tools/build_oai_sets.pl
- Look at the reading history at the OPAC (opac-readingrecord.pl)
- At the OPAC, click on a tag, you must see the result
Note: Changes in Koha/OAI/Server/ListRecords.pm is planned on bug 15108.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Zeno Tajoli <z.tajoli@cineca.it>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
There is only one call to C4::Biblio::ModBiblioframework, it's called
just before C4::Biblio::ModBiblio in cataloguing/addbiblio.pl
At first glance this call does not seems useful: all the subroutines
called from ModBiblio send the frameworkcode in parameter.
I'd go to remove it, but I'd like to get confirmation by others.
No test plan here, you need a good pair of eyes and deep into the
C4::Biblio code.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Add shibboleth parameter to POD of set_userenv.
Removed a 12th set_userenv parameter from Borrower_Discharge.t.
Replaced set_userenv call in PatronLists.t looking like a fortunate typo.
Test plan:
Run the two corrected tests.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Persona never really took off, and although many browsers currently
support it, very few services actually implement it.
This has lead to it's founders, Mozilla, to end the project. In their
own words:
=============================================================================
Persona is no longer actively developed by Mozilla. Mozilla has
committed to operational and security support of the persona.org
services until November 30th, 2016.
On November 30th, 2016, Mozilla will shut down the persona.org services.
Persona.org and related domains will be taken offline.
If you run a website that relies on Persona, you need to implement an
alternative login solution for your users before this date.
For more information, see this guide to migrating your site away from
Persona:
https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
=============================================================================
Given the above, and that the Persona authentication methods as a whole
are no longer being actively maintained by anyone anywhere to ensure
ongoing security, we should deprecate the option from koha.
Test plan:
Apply this patch and make sure you do not find any references of Persona
Have a look at patches from bug 9587 and confirm that everything has
been reverted
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Code looks good to me.
Also ran several tests including: Auth.t, Auth_with_shibboleth.t.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* C4/Circulation.pm (GetTransfers, GetTransfersFromTo): Also return
branchtransfer_id in return columns.
* installer/data/mysql/atomicupdate/14187.perl: New file.
* installer/data/mysql/kohastructure.sql: Modify branchtransfers structure.
* t/db_dependent/Circulation/transfers.t: Update tests to expect
branchtransfer_id.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Test plan successful on all steps.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended patch: Remove Schema changes from this patch
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Currently the card number is generated when the user enters the patron creation form. This creates a problem of concurrency - when two or more simulataneous users are registering members, the error "card no. in use" can occur.
This change moves the card number generation to occur after the "Save" button is pressed.
Changes:
-C4/Members.pm:
Added code to fixup_cardnumber,If the cardnumber is blank and "autoMemberNum" ON.
-koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:
Added code to display "leave blank for auto calc during registration" in cardnumber label in patron registration form only if "autoMemberNum" ON.
-members/memberentry.pl:
Added code to get weather or not "autoMemberNum" is on or off and removed fixup_cardnumber generation.
Test cases:
-If "autoMemberNum" ON:
->In blank case, must generate auto card number in simulataneous users.
->If user entered, check for unique card number.
-If "autoMemberNum" OFF:
Must work normal.
Followed test plan, works as expected.
Note: Syspref PorrowerMandatoryField must not include cardnumber, otherwise
you can not save. Maybe that should be mentioned in the comment for
syspref autoMemberNum.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch fixes notification when same biblio has multiple reserves with same borrower,
introduced in Bug 14695. C4::Reserves::ModReserveAffect uses internal method
_koha_notify_reserve but sends itemnumber and biblionumber instead of record_id.
To test:
Prerequisites:
- One biblio with two items attached
- A patron with hold_filled notification activated
- A letter for HOLD with <<reserves.reserve_id>> in it
1) Place two reservations on same biblio
2) checkin item x on pickup branch, observe patron message generated
3) checkin item y on pickup branch, observe patron message generated
4) note that reserve_id is the same on both messages, which is wrong
5) apply this patch and repeat 1-3
6) now observe notifications have correct (different) reserve_id
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test Plan:
1) Apply these patches
2) prove t/db_dependent/Accounts.t
3) 'git grep makepayment' should return no results
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In the previous patch we use the constraint_exists subroutine to verify
if an index or a foreign key exists.
But the `SHOW INDEX` query does not return foreign keys (as its name
suggests!).
We need another subroutine foreign_key_exists to check the FK existence.
I have found that because t/db_dependent/TestBuilder.t fails on
oai_sets_biblios, because oai_sets_biblios_ibfk_1 has not been removed.
Test plan:
0/ Do not apply this patch
1/ Use a 3.20 DB
2/ update the DB
3/ SHOW CREATE TABLE oai_sets_biblios
will display oai_sets_biblios_ibfk_1
Apply the patch and repeat 1, 2, 3
=> Will not display oai_sets_biblios_ibfk_1
It has been removed as expected.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
3) Test fine payment via the "Pay selected" button
Signed-off-by: Laura Slavin <lslavin@hmcpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
3) Test fine payment via the "Pay" button,
but make the payment for less then the full amount
Signed-off-by: Laura Slavin <lslavin@hmcpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is the fourth patch in a series to unify all payment functions into
a single mathod
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
3) Test fine payment via the "Pay" button,
but make the payment for less then the full amount
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is the third patch in a series to unify all payment functions into
a single mathod
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
3) Test fine payment via the "Pay selected" button
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch create a Koha::Acquisition::Booksellers module and
Koha::Acquisition::Bookseller::Contract[s] modules.
All code in the acquisition module is adapted to use the CRUD methods of
Koha::Object[s].
The former C4 routines are removed.
Test plan:
Since a lot of files are impacted by this patch, try a complete
acquisition workflow and try to catch errors.
Be focused on bookseller and bookseller' contacts data.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
From C4::Auth:
my $patron = Koha::Patrons->search({ userid => $userid })->next;
This should be replaced with
my $patron = Koha::Patrons->find({ userid => $userid });
userid is a unique key
Caught with NYTProf:
# spent 78.9ms making 1 call to Koha::Objects::next
Test plan:
Login at the intranet
Reload the page
=> You must still be logged in
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested by enabling TrackLastPatronActivity and logging in again.
Verified lastseen column in borrowers.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Ready for an archaeology course?
C4::Circulation::GetItemIssues is only used once, from
catalogue/issuehistory.pl
This call has been added by
commit 95d6452462
Adding some more information on issuehistory.
which says "Adding itemnumber to issuehistory.pl API so that one could search
for issuehistory of a specific item."
So it added the ability to see the item issue history but did not
provide a way to access it via the interface.
It's ok so far but this subroutine is broken since
commit aa114f5349
Bug 5549 : Only use DateTime for issues table
because of this change:
- my $today = C4::Dates->today('iso');
+ my $today = DateTime->now( time_zome => C4::Context->tz);
I let you catch the typo ;)
And since this commit the subroutine explodes with "The following
parameter was passed in the call to DateTime::from_epoch but was not
listed in the validation options: time_zome"
Since it has never been raised by someone and that the feature is
hidden, I'd recommend to simply remove it.
Note that the "Checked out from" column would have been wrong even if we
fixed all the previous issue.
Test plan:
Just dig into the code and confirm what this commit message tells
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Looks fine for me.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
For no discernable reason, when AddIssue calls AddRenewal, it passes the
branchcode generated from _GetCircControlBranch. Assume
_GetCircControlBranch is set to return items.homebranch. So:
1) If an item owned by LibraryA is checked out at LibraryB, the
statistic line branchcode will be LibraryB
2) If an item is renewed via the ajax datatables renewal function, the
statistic line branchcode will be LibraryB the
3) If an item is renewed via scanning the item into the checkout again,
statistic line branchcode will be *LibraryA*
This is clearly improper behavior. The renewal is taking place at
LibraryB, so the branchcode passed to AddRenewal should be LibraryB,
the logged in library. This also jives with the documentation for
the subroutine.
Test Plan:
1) Set CircControl to "the library the item is from" aka ( ItemHomeLibrary )
2) Set HomeOrHoldingBranch to 'The library the items is from" ( aka homebranch )
3) Create item with homebranch of LibraryA and holdingbranch of LibraryB
4) Set the logged in library to LibraryB
4) Check the item out to a patron at LibraryB
5) Note the statistics line has a branchcode of LibraryB
6) Check the item out again to trigger a renewal, renew the item
7) Note the statistic line has a branchcode of LibraryA!
8) Apply this patch
9) Repeat step 6
10) Note the statistics line has a branchcode of LibraryB!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Kuhn <kuhn@monterey.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Currently you can call GetPreparedLetter like:
$prepared_letter = GetPreparedLetter(
(
module => 'test',
letter_code => 'TEST_HOLD',
tables => {
reserves => [ $fk1, $fk2 ],
},
)
);
It assumes that $fk1 is a borrowernumber and $fk2 a biblionumber.
It seems hazardous to do this guess.
I suggest to remove this feature and only allow hashref indeed.
Test plan:
Use different way to generate letters and make sure you do not reach the croak
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Circulation::GetIssues subroutine is only called once and can be
replaced with a call to Koha::Isues->search with a join on items.
Test plan:
- Apply first patch and make sure the tests pass
- Apply second patch and make sure the tests still pass
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
- Use of GetItemnumbersForBiblio instead of GetItemsByBiblioitemnumber (thx Jonathan Druart)
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test this patch you should try to send a query to you opac formatted
this way :
http://[your-opac-domain-name]/cgi-bin/koha/ilsdi.pl?service=GetAvailability&id=[biblionumber]&id_type=bib
You should get availability status for all the items of the matched
bibliographic record.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to Admin -> Classification sources
2) Attempt to reproduce bug before applying patch. Notice the message
saying the add was successful, but was not added to the table
3) Apply patch and refresh page (restart plack if necessary)
4) Add new classification source with same code as existing one. Notice
you are now told that the add failed.
5) Confirm adding new classification source with unique code works
6) Add new classification filing rule with same code as existing one.
Notice you are told that add failed.
7) Confirm adding new classification filing rule with unique code works
Sponsored-by: Catalyst IT
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
This is not the way to go, we should use an eval instead.
But since we do not have RaiseError set, it will not work.
This module will need to be moved to Koha::Objects to be implemented
correctly.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If you are non logged-in and you the search result contain lost items,
you will get:
Can't call method "category" on an undefined value at
/home/liz/koha-src/koha/C4/Search.pm line 2091.
This is because bug 17556 assumed that $userenv was not defined when the
user is logged out. Actually it is, with non defined or empty string
values.
Test plan:
Do a search in the opac that would turn up a whole list of results (and
not just that one) with the lost item included.
=> Without this patch you should get an error
=> With this patch applied you should see the search results
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
C4::Biblio::GetHolds can be replaced with Koha::Biblio->holds->count
Test plan:
Create an order and place a hold on the biblio you have ordered.
On the basket view, you should not be able to Cancel the order and/or
delete the record
Receive the order, on the parcel page you should get the same behavior.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
All the values different from the ones GetMember returned has been
managed outside of GetMemberDetails.
It looks safe to replace all the occurrences of GetMemberDetails with
GetMember.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This value is not used anywhere
Test plan:
git grep enrolmentperiod| grep -v installer| grep -v translator|vim -
should show you that I am right
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Same as other patches, reservefee is only used in opac-reserve.pl
Test plan;
Set reserve fee for a patron category
Place a hold at the OPAC with one of these patrons.
You must get a message about the reserve fee.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The is_expired value is used in 2 places, let's use
Koha::Patron->is_expired instead.
Test plan:
Depending on the different value of BlockExpiredPatronOpacActions for
the patron category, a patron must be blocked if he has expired.
Confirm that behavior from opac-renew and opac-reserve scripts
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Same as authflags, a flags key is set containing all the patron flags.
It is only used in a few places and it's better to call
C4::Members::patronflags when we need it.
Test plan:
Look at the diff and confirm that the change make sense
Use git grep to confirm we do not use the flags somewhere else.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The amountoutstanding value set by GetMemberDetails was only used in a
few places. In that case it makes sense to only retrieve it when needed.
Test plan:
1/ Add fines to a patron, on the OPAC patron info page, you should see a
"Fines" tab
2/ Add credit to a patron, you should see the credit displayed
3/ Set the pref maxoutstanding to 3
4/ Add a fine of 4 to a patron
5/ Try to place an hold for this patron
=> You should get a "too much oweing" message
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This script is not used from the Koha codebase and does not seem very
useful.
We could rewrite it if needed later (ie. if someone complains I will
rewrite it).
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
GetMemberDetails create a authflags key, but this key is only used from
2 different places.
One is a very simple script, which does not seem very usefull
C4/SIP/interactive_members_dump.pl. I propose to simply remove it.
The other one is the member-flags.pl script. What is done in this one is
a bit weird since we a doing twice the same query (it was not highlighted
before this patch). We will need to fix that later.
At the moment the goal it to remove the GetMemberDetails subroutine
without introducing any regressions (and so without adding big changes)
Test plan:
Select/unselect permissions for a patron, save and edit again.
The behavior of the permission checkboxes should be ok
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The correct way to get the value of BlockExpiredPatronOpacActions from a
patron object is to get the patron category then call the
effective_BlockExpiredPatronOpacActions:
$patron->category->effective_BlockExpiredPatronOpacActions
So this patch applies this change and remove this value from the
GetMemberDetails subroutine.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
As said in the previous commit, I considered SetAge as unnecessary and
removed it.
Test plan:
1/ Edit a patron using the different 'Edit' links
2/ Play with the patron category limited to age ranges, and date of
birth
3/ You should get the expected warning if the date of birth is inside
the patron category date range.
To finish:
prove t/Circulation/AgeRestrictionMarkers.t t/db_dependent/Reserves.t \
t/db_dependent/Koha/Patrons.t t/db_dependent/Members.t
should return green
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Adding POD, changing the config files to live in a path pointed to by
koha-conf.xml
This means multiple instances can have their own config
Please test the 2 patches together
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised. Arbitrary arguments can be passed to SMS:Send
drivers. If an argument is provided that has already been set by
SMS::Send or the driver, it will be overwritten by the value from
the YAML file. My only suggestion for an improvement would be an
example of what the YAML should look like, but that is a minor thing.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::SMS::send_sms now reads a YAML file and pass all parameters in the
file to SMS::Send::new.
The config file is read in <installdir>/etc/sms/driver/<driver>.yaml.
For instance, if the driver used is SMS::Send::UK::Kapow, the config
file has to be in <installdir>/etc/sms/driver/UK/Kapow.yaml
A underscore character is prepended to all parameter names so they are
treated as driver-specific options (leading underscore must not appear
in config file).
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Not optional since we are 'using' it in updatedatabase.pl.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This reverts commit 7ac1bc3537.
On a kohadevbox:
Error flock (1) on
'/home/vagrant/kohaclone/installer/data/mysql/atomicupdate/bug_xxxx.perl':
No locks available at installer/data/mysql/updatedatabase.pl line 13637.
This is because Path::Tiny->slurp[_utf8] uses flocks which does not work
with NFS
Test plan:
Execute a .perl atomic update file on a kohadevbox
=> Without this patch you should get the flock error
=> With this patch the update should work fine
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Members::GetHideLostItemsPreference can easily be
replaced with Koha::Patron->find(42)->category->hidelostitems
Test plan:
Create 2 patron categories, 1 with "Lost items in staff client" set to
"shown" and another one to "Hidden by default"
Create 2 patrons using them
On the result search page, the detail page of a record, the item list
page and the page to place a hold, make sure the lost items are
shown/hidden as expected
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is the second patch in a series to unify all payment functions into
a single mathod
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
3) Test fine payment via the "Pay" button
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Followed test plan, works as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The amount in accountlines should be saved as a negative amount, but
amount outstanding is correct.
Note: This routine is actually used only once (in paycollect.pl). And is
only cosmetically tested in Accounts.t.
Test plan:
[1] Create a manual invoice, Fine, say 20.
[2] Click on the Pay button next to this fine, and pay 1.
[3] Pay again, using 'Pay amount' button, and pay 2.
[4] Pay again, using 'Pay' on the same line, the full remaining amount.
[5] Verify that you see -1, -2 and -17 on the Accounts tab.
[6] Run t/db_dependent/Accounts.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The calls
output_pref({ dt => dt_from_string( $date ) })
are wrong and should be replaced with
output_pref({ str => $date })
For better error handling.
Here we fix the problem of items.onloan when searching
Test plan:
- Set items.onloan=0000-00-00 (UPDATE items SET onloan='0000-00-00')
This can come from old data or bad migration
- Execute a search
=> Without this patch you get
Can't locate object method "ymd" via package "dateonly" (perhaps you forgot to load "dateonly"?) at /home/vagrant/kohaclone/Koha/DateUtils.pm line 225.
=> With this patch you won't get the error
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
I was reading through Reserves.pm trying to figure out a bug - found some
unused variables instead.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
