Bug 12139 - Preference name saved all lowercase
Summary: Preference name saved all lowercase
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-25 09:14 UTC by paxed
Modified: 2015-12-03 22:00 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description paxed 2014-04-25 09:14:54 UTC
If a preference doesn't exist in the database, saving that preference via the UI will result the preference name set in all lowercase in the database. This means those preferences that have any uppercase characters won't find the value, eg. in templates.

To test:

1) select * from systempreferences where variable like 'advancedMARCeditor';
   (note the way the "variable" is in db: "advancedMARCeditor")
2) delete from systempreferences where variable like 'advancedMARCeditor';
3) Go to system preferences, edit and save advancedMARCeditor setting.
4) select * from systempreferences where variable like 'advancedMARCeditor';
   (note the way the "variable" is in db: "advancedmarceditor")
Comment 1 Marc Véron 2014-04-25 12:57:21 UTC
I could reproduce this following the test steps.

Additional remarks:
The system log logs the variable name correctly ('advancedMARCeditor')

As far as I can trace it down, the involved code is in admin/systempreferences.pl around line 284 
or around line 355

However, the insert statement and the log statement use the same value at both places: $input->param('variable')
Comment 2 Jonathan Druart 2015-04-27 14:28:50 UTC
Looks good now, I did not manage to recreate this issue.
Please reopen if I am wrong.