To test:
1 - prove -v t/db_dependent/Koha/Config/SysPrefs.t
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
At the moment, the sysprefs are only cache in the thread memory
executing the processus
When using Plack, that means we need to clear the syspref cache on each
page.
To avoid that, we can use Koha::Cache to cache the sysprefs correctly.
A big part of the authorship of this patch goes to Robin Sheat.
Test plan:
1/ Add/Update/Delete local use prefs
2/ Update pref values and confirm that the changes are correctly taken
into account
Signed-off-by: Chris <chrisc@catalyst.net.nz>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Tested with plack with syspref cache enabled, there is some time between setting the syspref and applying it, but it takes just one reload of page, it shouldn't be problem, should it?
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Tested with CGI and CGI + memcache; some small issues still remain,
but it would be better to deal with them in separate bug reports
if necessary
Signed-off-by: Brendan Gallagher brendan@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>
System preferences should have a package based on Koha::Object to remove
the need for direct manipulation via SQL.
Test Plan:
1) Apply this patch
2) prove t/db_dependent/sysprefs.t
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Nick Clemens
Jonathan Druart
Kyle M Hall