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>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
So far the administration module only allowed for 2 permissions:
- circulation conditions (manage_circ_rules)
- everything else (parameters_remaining_permissions)
With this patch almost every section of the administration page
will have its own granular permission.
To test:
- Create different staff users:
1) One with parameters_remaining_permissions
2) One with parameters
3) One with catalogue and no parameters
4) One superlibrarian
- Apply the patch
- Run the database update
- Check the staff users:
1) All subpermissions, but manage_circ_rules
should be checked
2) Nothing should have changed
3) manage_item_serach_fields shoudl be checked
(page had catalogue permission before)
4) Nothing should have changed
- Try different settings of the permissions and
verify that
- Administration page behaves correctly
- Administration menu behaves correctly
! You shoudl only see what you have permission for
https://bugs.koha-community.org/show_bug.cgi?id=14391
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
- Apply the patch
- Add an SRU authority server in admininistration -> Z39.50/SRU servers
You can try with the French national library, configured as such:
Hostname: catalogue.bnf.fr
Port: 80
Database: api/SRU
Syntax: Unimarc
Record type: authority
Additional SRU options: version=1.2,sru=get
SRU Search fields mapping example:
Keyword (any): aut.anywhere
Name (any): aut.anywhere
Author (any): (aut.type any "pep org") and aut.accesspoint
Author (personal): aut.type=pep and aut.accesspoint
Author (corporate): aut.type=org and aut.accesspoint
Author (meeting/conference): aut.type=org and aut.accesspoint
Subject heading: (aut.type any "geo ram_nc ram_ge ram_pe ram_co") and aut.accesspoint
Subject sub-division: aut.type=ram_pe and aut.accesspoint
Title (any): (aut.type any "tic tut tum ram_tp ram_tu") and aut.accesspoint
Title (uniform):(aut.type any "tut tum ram_tu") and aut.accesspoint
- Try a search from Authorities -> New from Z39.50/SRU
- Check that the authority is correctly displayed in "Show Marc"
- Check that the authority is correclty added to koha in "Import"
- prove t/db_dependent/Breeding.t
Signed-off-by: François Pichenot <fpichenot@ville-roubaix.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This form allows you to enter the match between the standard names of
the Z3950 search fields and the field names for a specific SRU server.
This patch only adds the form; it will be used in a subsequent patch.
Test plan:
Not needed, but you can call the form by constructing a URL like:
cgi-bin/koha/admin/sru_modmapping.pl?mapping=title=1,author=2
You should see the form with title and author filled.
Note that you cannot save the information yet.
Signed-off-by: Giuseppe Angilella <giuseppe.angilella@ct.infn.it>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
