We need to add scalar to the calls. These parameters are not meant
to be used as multi_param.
Test plan:
Try With and without this patch on staff:
Try: /cgi-bin/koha/admin/columns_settings.pl
=> WITHOUT: No warnings
=> WITH: Same. No change.
Try: /cgi-bin/koha/admin/columns_settings.pl?module=acqui&page=basket
=> WITHOUT: Opens module, scrolls down. CGI::param called in list context in logfile
=> WITH: Opens module, scrolls down.
Try: /cgi-bin/koha/admin/columns_settings.pl?module=acqui&page=basket&table=orders
=> WITHOUT: Opens module, scrolls down. CGI::param called in list context in logfile
=> WITH: Opens module, scrolls down.
Try: /cgi-bin/koha/admin/columns_settings.pl?module=acqui&module=admin
* Hash like: panel => acqui, admin => page, undef => table, undef => modules, $modules (SHIFTED)
=> WITHOUT: Acqui expanded showing: There is no page using the table configuration in this module.
=> CGI::param warning in log.
=> And: Problem = a value of table has been passed to param without key
=> And: Problem = a value of modules has been passed to param without key
=> WITH: Only the first module (Acqui) should be expanded.
Try: /cgi-bin/koha/admin/columns_settings.pl?module=acqui&module=admin&page=basket&table=orders
* Hash like: panel => acqui, admin => page, basket => table, orders => modules, $modules hash (SHIFTED)
=> WITHOUT: Acqui expanded showing: There is no page using the table configuration in this module.
=> And: CGI param log warning.
=> WITH:: Opens Acqui. Second module ignored. Scrolling.
Try: /cgi-bin/koha/admin/columns_settings.pl?module=admin&module=acqui&page=basket&table=orders
* Hash like: panel => admin, acqui=> page, basket => table, orders => modules, $modules hash (SHIFTED)
=> WITHOUT: Admin expanded showing: There is no page using the table configuration in this module.
=> And: CGI param log warning.
=> WITH: Admin should be expanded (page and table ignored, not in Admin). No scroll.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 1b11de87b9)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch enabled scrolling directly to the correct table configuration when clicking the 'Configure this table'
button from any KohaTable/kohaTable table in Koha.
Test plan
1. Navigate to Administration > Cities
2. Click 'Configure this table'
3. Confirm the result is the table settings page and you are scrolled to
the cities table configuration
Signed-off-by: Andrew <andrewfh@dubcolib.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the column settings page to use ID's instead of
Indexes to restor the open accordian card after a setting change.
Test plan
1 Go to Administration -> Table settings.
2 All panels should be collapsed.
3 Test expanding and collapsing panels to confirm it's working
correctly.
4 Make a change to one of the table configurations. After clicking
"Save" the page should reload with the same panel expanded.
Signed-off-by: Andrew <andrewfh@dubcolib.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This page updates the table settings page so that it uses Bootstrap's
"Collapse" feature instead of jQueryUI's Accordion.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- Go to Administration -> Table settings.
- You should see a list of table settings which looks much the same as
it did before, with arrow icons prefixing each section header. All
panels should be collapsed.
- Test expanding and collapsing panels to confirm it's working
correctly.
- When you expand a section the heading arrow should change from
right-pointing to down.
- Make a change to one of the table configurations. After clicking
"Save" the page should reload with the same panel expanded.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On the acquisition table the sort option is not available as we don't
offer the ability to selection asc/desc and default to asc.
We cannot offer default_display_length for those tables.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
From tht YAML pod:
"""
This module has been released to CPAN as YAML::Old, and soon YAML.pm will be changed to just be a frontend interface module for all the various Perl YAML implementation modules, including YAML::Old.
If you want robust and fast YAML processing using the normal Dump/Load API, please consider switching to YAML::XS. It is by far the best Perl module for YAML at this time. It requires that you have a C compiler, since it is written in C.
"""
See also
https://gitlab.com/koha-community/qa-test-tools/-/merge_requests/35
Test plan:
Try some place where YAML::XS is not used and confirm that it works
correctly
QA note: This patch removes some uses of YAML that were not useful
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
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>
In that case it's equal to 0 and we need to adjust the test condition.
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>
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>
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>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This is a bug fix for bug the columns configuration feature, and
specialy for bug 13864.
Test plan:
Apply patches on bug 13864 and save columns for the late orders (in the
columns configuration admin page).
Confirm that they are correctly saved.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
works as expected
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This development introduces ColVis into Koha and provides a configuration
page for columns visibility.
ColVis is a plugin for DataTables. It allows to change the visibility of
the columns in the table.
* This development adds:
- the js and css file for ColVis
- a new DB table 'columns_settings'
- a new template plugin 'ColumnsSettings'
- a new package C4::Utils::DataTables::ColumnsSettings
- a new admin page admin/columns_settings.pl
* How it works:
A yaml file is created (admin/columns_settings.yml) in order to take an
inventory of all tables where ColVis is implemented. This file is read
to create the list of modules, pages and tables in the configuration
page.
There are 3 possible keys in the yml:
- is_hidden: default is 0
The column will be hidden.
- cannot_be_toggled: default is 0.
ColVis will allow to hide/show the column.
- cannot_be_modified: default is 0
Default values (in the yml) won't be modifiable.
When a user changes (or saves) the configuration for one module, all
columns are added to the DB table. The values in the DB get the upper hand
on the yaml values.
* Humm, strange?
It seems weird to have 2 storages for the same values. But I
think it will be easy to add an entry and maintain the yaml rather than
adding a new row (and new entry in updatedatabase script) in the DB.
* To go further: We can imagine that the configuration is saved for each
user (and not globally like it is made with this patch).
This patch cannot be tested as it, you need to apply the "POC" patch.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, more comments on last patch.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
