Bug 10199 - Move fields type, options and explanation from systempreferences table?
Summary: Move fields type, options and explanation from systempreferences table?
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-06 11:45 UTC by Marcel de Rooy
Modified: 2023-01-25 23:01 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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2013-05-06 11:45:12 UTC
Currently, only local use preferences use the fields options and explanation. The normal preferences ignore these fields; they come from the YAML file now (.pref file).
The use of type is somewhat hybrid. There are still some references in the code (especially for YesNo), but the preferences script again looks at the YAML file.

My question is: Saving a pref file for the local use prefs does not seem an option (at least from the web interface). But could we move them elsewhere? Separate table? Another idea?

If you would delete a regular pref from the yaml file now, but not from the database, it will popup without an explanation or an older one and perhaps without options or older options in the local use tab.

How do you think that we should resolve this situation best?
Comment 1 Katrin Fischer 2013-05-11 12:28:24 UTC
Hi Marcel,

I am not sure what we would win by dividing local use preferences and normal preferences. Both need a table for the value set to be saved, so 2 tables seem more error prone to me than having one with a few columns unused?

I am sorry, but I don't understand the point about deleting the pref from your description. Could you give an example where this is a problem?
Comment 2 Marcel de Rooy 2013-05-13 07:39:47 UTC
(In reply to comment #1)
> I am not sure what we would win by dividing local use preferences and normal
> preferences. Both need a table for the value set to be saved, so 2 tables
> seem more error prone to me than having one with a few columns unused?
Hi Katrin,
I agree. If(..) we should move the unused columns, we should leave what we do use in systempreferences. So no completely separate table for local use prefs. Maybe a joined table for options and explanation to remove redundancy?
But then we still face this problem: You have local use pref A. Then it becomes a real pref so now its description comes from yaml. But we still have an old description in the joined table..

> I am sorry, but I don't understand the point about deleting the pref from
> your description. Could you give an example where this is a problem?
This is only a fictive problem. If you would delete a regular pref (remove it from the preferences file), but somehow not delete if from the table (the dbrev did not work out?). In this case you got a local use pref falling back to the old columns.
Comment 3 Katrin Fischer 2023-01-25 23:01:30 UTC
Almost 9 years later... is this something we should still act on?

I have to admit, working with a MySQL client often it's nice to have the additional clues in SQL. I am not against changing things, but would personally not push for it.