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>
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>
Sponsored-by: Association KohaLa - https://koha-fr.org/
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: Association KohaLa - https://koha-fr.org/
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This bug report will add new classes for:
* Koha::Old::Patron[s]
* Koha::Old::Biblio[s]
* Koha::Old::Item[s]
* Koha::Old::Biblioitem[s]
Sponsored-by: Association KohaLa - https://koha-fr.org/
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In order to avoid writing the tests using plain DBIC which would later
need to be replaced by a Koha::Object-based counterpart, I introduce
this stub classes.
Stub tests are added as well.
To test:
- Apply this patch
- Run:
$ kshell
k$ prove t/db_dependent/Koha/Tags.t \
t/db_dependent/Koha/Tags/Approvals.t \
t/db_dependent/Koha/Tags/Indexes.t
=> SUCCESS: Tests pass
- Sign off :-D
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch introduces Koha::Object(s)-derived classes for budgets and funds (aqbudgetperiods and aqbudgets respectively).
C4::Budgets already uses DBIC calls on those tables so transition should be easy on top of this.
To test:
- Check the referenced schema files are the right ones.
- QA scripts shoudl be happy.
- Sign off :-D
Note: the POD coverage report throws a false negative result on singular classes which is trivially wrong.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are based on Koha::Objets. Tests provided.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test pass, no errors.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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>
There are 3 subroutines in C4::Members to get, add and delete patron
images:
- GetPatronImage
- PutPatronImage
- RmPatronImage
By creating these 2 Koha::Patron::Image[s] classes, we could remove them easily.
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>
In a few case (at least systempreferences and export_format (csv profiles),
the type method of Koha::Object and Koha::Objects can be in conflict with the
column names.
Indeed systempreferences.type exists and so the method will return
'Systempreference' (the name of the module) instead of the value of the row in
DB.
I have found at least 1 place where it can cause issue:
In C4::Context->set_preference:
601 my $syspref = Koha::Config::SysPrefs->find( $var );
602 my $type = $syspref ? $syspref->type() : undef;
603
604 $value = 0 if ( $type && $type eq 'YesNo' && $value eq '' );
type will always be 'Systempreference' and the YesNo pref will be set to an
empty string '' instead of 0.
I am not sure about the consequences of this, but it is preferable to
fix it ASAP.
To reproduce:
0/ Do not apply this patch
1/ Edit a YesNo prefs, AutoEmailOpacUser for instance
2/ Set it to "Don't sent"
3/ Check the value in DB, it should be set to an empty string, instead
of 0
4/ Apply this patch and try again. Now the value should be 0
Followed test plan, value is now 0 as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Tested both patches together, works as expected
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@theke.io>
This is the original patch for bug 12892 and replaces the older style of
fetching the holds data with Koha Objects. It will be used as a
foundation for future features.
Test Plan:
1) Apply this patch
2) Create a hold, set to waiting
3) Browse to circulation.pl for that patron
4) Note you see the list of waiting holds
5) Switch your logged in branch to a different branch
6) Note the "Waiting at" line is no longer emphasized.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Cathi Wiggins <CWIGGINS@ci.arcadia.ca.us>
Signed-off-by: Megan Wianecki <mwianecki@mplmain.mtpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea behind this is to have a pair of base classes on which to build
our new generation of Koha objects. Koha::Object is a base class, which
in it's most basic form, is to represent a row in a table. For example,
Koha::Borrower inherits from Koha::Object. So too could Koha::Biblio
and Koha::Item for example.
Koha::Objects is to represent a way to fetch and manipulate sets of
objects. For example, Koha::Borrowers has a method to get a
Koha::Borrower object by id and a method to search for an get a list
of Koha::Borrower objects. Right now Koha::Objects has only the
essentials but can easily be extended and those enhancements will be
passed down to all the child classes based on it.
By using these classes as a base, we will add consistency to our
code, allow us to keep our code DRY, reduce bugs, and encapsulate our
database access among other benefits.
Test Plan:
1) Apply this patch
2) prove t/Object.t t/db_dependent/Object.t t/db_dependent/Objects.t
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
working through the master branch to eliminate all
podchecker warnings/errors
Actual improvement to the quality of the POD will
come later (hopefully with assistance of others)
Signed-off-by: Andrew Elwell <Andrew.Elwell@gmail.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Following suggestion by Vincent Danjean for Debian
packaging, 0755 -> 0644 for non-executable
files.
Also removed shebang from a few modules in C4.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This code is intended to replace current value_builder code in 3.2, but
it does not affect it directly (yet) and is safe to include in 3.0.
This structure will be used to handle more complicated formats, like those
with checkdigits. Please note that "incremental" format is still STRONGLY
recommended because it will always perform the best, and most flexibly.
The desire to include other information (like branchcode) should compel
the proper use of the barcode generator to print the info ON the barcode,
not IN the barcode.
One of the nicer features of this structure is that you are able to
create a new barcode (of the same type) based on any previous Barcodes object.
That means you can create an array of 51 consecutive barcodes like:
my $x = C4::Barcodes->new('annual'); # for example
my @set = ($x);
for (1..50) {
push @set, $x=$x->new;
}
Importantly, this can happen without referencing the database after the
first constructor.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
- updating templates to have tmpl_process3.pl running without any errors
- adding a drupal-like css for prog templates (with 3 small images)
- fixing some bugs in circulation & other scripts
- updating french translation
- fixing some typos in templates
moving the getalltemplates and getalllanguages subs out from Search.pm (that will be deprecated soon) to Koha.pm
moving changelanguage.pl to OPAC scope