Moving system preference serialization into the database
While doing some beginning work on a local syspref editor to fit in with the new system preference interface, I have run into the file permission "problem" of writing to files inside Koha's template directory structure. This is due to the fact that the system preferences are serialized in yaml format and stored in *.pref files within the template directory structure. While the problem of writing to files is one which needs to be addressed, it is not one that we have time to address before the 3.2 stable release. As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues. So, are there any serious objections to making this change? Kind Regards, Chris
* Chris Nighswonger (cnighswonger@foundations.edu) wrote:
While doing some beginning work on a local syspref editor to fit in with the new system preference interface, I have run into the file permission "problem" of writing to files inside Koha's template directory structure. This is due to the fact that the system preferences are serialized in yaml format and stored in *.pref files within the template directory structure. While the problem of writing to files is one which needs to be addressed, it is not one that we have time to address before the 3.2 stable release.
As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues.
So, are there any serious objections to making this change?
Hi Chris Assuming this leaves the system preferences translatable, as they are now, then I have no objections. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
On Sun, Jul 11, 2010 at 8:53 PM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
While doing some beginning work on a local syspref editor to fit in with the new system preference interface
BTW, this piece of hackary can be seen here for anyone who's interested: http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=shortlog;h=refs/h... <standard-disclaimer> As this is a wip, it is subject to break your system badly or even worse... you have been warned. </standard-disclaimer>
As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues.
Isn't it too late? To be translatable you need not to forget to serialize syspref templates per language, and then: * modify syspref editor to get YAML data from DB rather than from .pref files, per language * modify translation process (LangInstaller.pm) to extract text from DB and and write into DB It would be very useful to have a complete API to manage sysprefs and allowing to add, modify, update sysprefs, integrated with updatabase.pl process. Now when we add a new syspref, we have to: 1. Add some text into a .pref file (history in git) 2. Add an INSERT statement to syspref table into kohastructure.sql 3. Modify various default values per language located in installer/data/mysql/<lang>/.../default-syspref.sql 4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT statement. Any sysprefs modification should aim at simplification. There is room for simplification: * Clearly distinguish syspref values from a koha instance (stored in DB) and syspref templates (.pref file/db) * Put default values per language directly in .pref file (or DB but how will you track modifications by developers, we have git now) * Delete all perl language default values located in installer/data/mysql... * Delete deprecated fields in syspreferences table: options, explanation, type. And modify accordingly all .sql files. -- Frédéric DEMIANS
On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic@tamil.fr> wrote:
As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues.
Isn't it too late?
I'll defer to Galen on that point. To be translatable you need not to forget to serialize
syspref templates per language, and then:
* modify syspref editor to get YAML data from DB rather than from .pref files, per language * modify translation process (LangInstaller.pm) to extract text from DB and and write into DB
Actually, the present yaml would simply go into a *.sql file under mandatory sysprefs. This would ensure their installation during the initial run of the web installer. As for translation: The current yaml files should be translated already. This change would only necessitate a one-time move of those files into the previously mentioned *.sql files and their appropriate directories. Translation into presently un-translated languages would then follow the already established procedures for translating the mandatory, etc. sql files.
It would be very useful to have a complete API to manage sysprefs and allowing to add, modify, update sysprefs, integrated with updatabase.pl process.
Now when we add a new syspref, we have to:
1. Add some text into a .pref file (history in git) 2. Add an INSERT statement to syspref table into kohastructure.sql 3. Modify various default values per language located in installer/data/mysql/<lang>/.../default-syspref.sql 4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT statement.
Any sysprefs modification should aim at simplification. There is room for simplification:
* Clearly distinguish syspref values from a koha instance (stored in DB) and syspref templates (.pref file/db) * Put default values per language directly in .pref file (or DB but how will you track modifications by developers, we have git now) * Delete all perl language default values located in installer/data/mysql... * Delete deprecated fields in syspreferences table: options, explanation, type. And modify accordingly all .sql files.
This process is not aimed at fixing the syspref system for ease of use by developers... sorry, there is definitely not time for that before the 3.2 release. It is simply aimed at restoring a feature which is present in 3.0.x which many users depend on, but is not presently in 3.2.x. Having said that: this work could certainly form the basis of a solution to those problems encountered by developers when adding sysprefs to areas other than the 'local-use' tab. Kind Regards, Chris
2010/7/12 Chris Nighswonger <cnighswonger@foundations.edu>
On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic@tamil.fr> wrote:
As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues.
Isn't it too late?
I'll defer to Galen on that point.
To be translatable you need not to forget to serialize
syspref templates per language, and then:
* modify syspref editor to get YAML data from DB rather than from .pref files, per language * modify translation process (LangInstaller.pm) to extract text from DB and and write into DB
Actually, the present yaml would simply go into a *.sql file under mandatory sysprefs. This would ensure their installation during the initial run of the web installer.
As for translation: The current yaml files should be translated already. This change would only necessitate a one-time move of those files into the previously mentioned *.sql files and their appropriate directories.
Translation into presently un-translated languages would then follow the already established procedures for translating the mandatory, etc. sql files.
It would be very useful to have a complete API to manage sysprefs and allowing to add, modify, update sysprefs, integrated with updatabase.pl process.
Now when we add a new syspref, we have to:
1. Add some text into a .pref file (history in git) 2. Add an INSERT statement to syspref table into kohastructure.sql 3. Modify various default values per language located in installer/data/mysql/<lang>/.../default-syspref.sql 4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT statement.
Any sysprefs modification should aim at simplification. There is room for simplification:
* Clearly distinguish syspref values from a koha instance (stored in DB) and syspref templates (.pref file/db) * Put default values per language directly in .pref file (or DB but how will you track modifications by developers, we have git now) * Delete all perl language default values located in installer/data/mysql... * Delete deprecated fields in syspreferences table: options, explanation, type. And modify accordingly all .sql files.
This process is not aimed at fixing the syspref system for ease of use by developers... sorry, there is definitely not time for that before the 3.2 release. It is simply aimed at restoring a feature which is present in 3.0.x which many users depend on, but is not presently in 3.2.x.
Having said that: this work could certainly form the basis of a solution to those problems encountered by developers when adding sysprefs to areas other than the 'local-use' tab.
Kind Regards, Chris _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
There were two important reasons for moving the system preference descriptions out of the database. The first was translation. Translating strings in the SQL files is significantly different than the rest of the translator's workflow (from what I can tell), and requires several skills that Pootle does not. The easiest way to tell this is to look at how many languages have translated interfaces, and how few have translated system preferences. Besides the main targets, en-US and fr-FR, there are only four others that had a translated sysprefs.sql, thanks to the work of Katrin and others. Not many are going to waltz into the Koha project with both good translation skills and enough bravery to translate the SQL. Localizing system preference defaults per-language makes sense, definitely. With the current file-based system, this is separated from translation, and is a much less daunting task than having to translate and localize an SQL file at the same time. Aside from that issue, keeping the two separate was also a very intentional separation of concerns. Aside from the previously-mentioned translation problems, putting interface-related strings in the database is bad practice, IMO. Any practical concerns are important, but I think the current system has this on its side. Today's nitpicky theoretical problems are tomorrow's intractable real-life bugs (fines system, anyone?). Under the old system, fixing any issues with the system preference display required a database update, no matter how trivial they were. This made little to no sense, considering that these were entirely interface issues. Again, you could create a system to keep the data files and DB in sync without this, but this would be at best confusing and at worse fragile. Leaving the files where they are makes it clearer that they are intended to be interface-related data, like the XSLT, and translated as such. My vote for solving the local-use preferences system is to leave the current system as it is, but add a database column or some way of easily distinguishing local-use from non-local-use prefs in the DB (making the explanation column NULL for non-local-use would work, though would require a time-consuming database update). This would make building a local-use tab fairly easy. Once we do that, we can drop the options column entirely, as I doubt most local-use users will care enough to set it. Theoretically, we could even drop the type column, though that might be useful in the future to help deal with more complex types of system preferences (automatically turning date sysprefs into C4::Dates objects, for example). Wow, that turned out longer than expected. Anyway, hope I made sense. Sincerely, -- Jesse Weaver
Jesse++ Translation of SQL files is a bigger project and too difficult for most people starting with Koha. The current system of translating SQL files is error-prone and should be replaced by better methods. It's too easy to forget one file when adding new permissions or system preferences. Changes to the table structure get not reflected in sample files etc. In my opionion the current system for translation of system preferences is a great improvement. Katrin -----Original Message----- From: koha-devel-bounces@lists.koha-community.org on behalf of Jesse Sent: Mon 12.07.2010 19:10 To: Chris Nighswonger Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Moving system preference serialization into thedatabase 2010/7/12 Chris Nighswonger <cnighswonger@foundations.edu>
On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic@tamil.fr> wrote:
As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues.
Isn't it too late?
I'll defer to Galen on that point.
To be translatable you need not to forget to serialize
syspref templates per language, and then:
* modify syspref editor to get YAML data from DB rather than from .pref files, per language * modify translation process (LangInstaller.pm) to extract text from DB and and write into DB
Actually, the present yaml would simply go into a *.sql file under mandatory sysprefs. This would ensure their installation during the initial run of the web installer.
As for translation: The current yaml files should be translated already. This change would only necessitate a one-time move of those files into the previously mentioned *.sql files and their appropriate directories.
Translation into presently un-translated languages would then follow the already established procedures for translating the mandatory, etc. sql files.
It would be very useful to have a complete API to manage sysprefs and allowing to add, modify, update sysprefs, integrated with updatabase.pl process.
Now when we add a new syspref, we have to:
1. Add some text into a .pref file (history in git) 2. Add an INSERT statement to syspref table into kohastructure.sql 3. Modify various default values per language located in installer/data/mysql/<lang>/.../default-syspref.sql 4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT statement.
Any sysprefs modification should aim at simplification. There is room for simplification:
* Clearly distinguish syspref values from a koha instance (stored in DB) and syspref templates (.pref file/db) * Put default values per language directly in .pref file (or DB but how will you track modifications by developers, we have git now) * Delete all perl language default values located in installer/data/mysql... * Delete deprecated fields in syspreferences table: options, explanation, type. And modify accordingly all .sql files.
This process is not aimed at fixing the syspref system for ease of use by developers... sorry, there is definitely not time for that before the 3.2 release. It is simply aimed at restoring a feature which is present in 3.0.x which many users depend on, but is not presently in 3.2.x.
Having said that: this work could certainly form the basis of a solution to those problems encountered by developers when adding sysprefs to areas other than the 'local-use' tab.
Kind Regards, Chris _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
There were two important reasons for moving the system preference descriptions out of the database. The first was translation. Translating strings in the SQL files is significantly different than the rest of the translator's workflow (from what I can tell), and requires several skills that Pootle does not. The easiest way to tell this is to look at how many languages have translated interfaces, and how few have translated system preferences. Besides the main targets, en-US and fr-FR, there are only four others that had a translated sysprefs.sql, thanks to the work of Katrin and others. Not many are going to waltz into the Koha project with both good translation skills and enough bravery to translate the SQL. Localizing system preference defaults per-language makes sense, definitely. With the current file-based system, this is separated from translation, and is a much less daunting task than having to translate and localize an SQL file at the same time. Aside from that issue, keeping the two separate was also a very intentional separation of concerns. Aside from the previously-mentioned translation problems, putting interface-related strings in the database is bad practice, IMO. Any practical concerns are important, but I think the current system has this on its side. Today's nitpicky theoretical problems are tomorrow's intractable real-life bugs (fines system, anyone?). Under the old system, fixing any issues with the system preference display required a database update, no matter how trivial they were. This made little to no sense, considering that these were entirely interface issues. Again, you could create a system to keep the data files and DB in sync without this, but this would be at best confusing and at worse fragile. Leaving the files where they are makes it clearer that they are intended to be interface-related data, like the XSLT, and translated as such. My vote for solving the local-use preferences system is to leave the current system as it is, but add a database column or some way of easily distinguishing local-use from non-local-use prefs in the DB (making the explanation column NULL for non-local-use would work, though would require a time-consuming database update). This would make building a local-use tab fairly easy. Once we do that, we can drop the options column entirely, as I doubt most local-use users will care enough to set it. Theoretically, we could even drop the type column, though that might be useful in the future to help deal with more complex types of system preferences (automatically turning date sysprefs into C4::Dates objects, for example). Wow, that turned out longer than expected. Anyway, hope I made sense. Sincerely, -- Jesse Weaver
Leaving the files where they are makes it clearer that they are intended to be interface-related data, like the XSLT, and translated as such.
Yes, even if it's not so simple, for XSL files and for .pref files, because they were designed at first with no specific consideration for localization. See various bugs related to this.
My vote for solving the local-use preferences system is to leave the current system as it is, but add a database column or some way of easily distinguishing local-use from non-local-use prefs in the DB (making the explanation column NULL for non-local-use would work, though would require a time-consuming database update). This would make building a local-use tab fairly easy.
As I understand it, the main issue is with blocker bug 3756. It could be solved without adding a new syspref table column. You get from all the .pref files a list of 'official' sysprefs and you compare it to defined sysprefs in DB: the difference are the local sysprefs. -- Frédéric
I'm also against translating SQL when templated techniques are feasible. But if the feature needed is to allow staff users the ability to enter multiple translations *at runtime* with no systems-level administration, then the only question is whether to allow Koha to: 1. write to a directory that it later uses for data, or 2. put more stuff in the database. The former case would also change the security profile of Koha significantly. Allowing your application to write to template directories is bad practice. Among other things, if you happen to be running your Koha installations off of git repos (as I know several vendors do), then having new uncommitted changes in the repo will *block* git pull/rebase for updates. I regard it as inadvisable. The latter is also undesirable, but only because we are talking about trying to translate SQL, and for the reasons Frederic points out having to do with translation. Therefore the fix is to do something like allowing to Koha to ingest values from a template file at install and runtime. Read the template (doesn't have to be H:T:P, as long as we can get PO files from it), parse it to whatever, match against keys in the syspref table and update description. I should say that I am unconcerned with translation of descriptions for purely local use variables if the user can control the description field in the DB. They can write the description in as many languages as they need. For standard sysprefs that need to be translated, I would still want to route everything through http://translate.koha-community.org/ . This might mean a longer turnaround to get the result onto a production system, but it certainly would lead to better satisfaction with Koha for other users of the same language. --joe On Mon, Jul 12, 2010 at 2:07 PM, Frederic Demians <frederic@tamil.fr> wrote:
Leaving the files where they are makes it clearer that they are intended
to be interface-related data, like the XSLT, and translated as such.
Yes, even if it's not so simple, for XSL files and for .pref files, because they were designed at first with no specific consideration for localization. See various bugs related to this.
My vote for solving the local-use preferences system is to leave the
current system as it is, but add a database column or some way of easily distinguishing local-use from non-local-use prefs in the DB (making the explanation column NULL for non-local-use would work, though would require a time-consuming database update). This would make building a local-use tab fairly easy.
As I understand it, the main issue is with blocker bug 3756. It could be solved without adding a new syspref table column. You get from all the .pref files a list of 'official' sysprefs and you compare it to defined sysprefs in DB: the difference are the local sysprefs.
-- Frédéric
The former case would also change the security profile of Koha significantly. Allowing your application to write to template directories is bad practice. Among other things, if you happen to be running your Koha installations off of git repos (as I know several vendors do), then having new uncommitted changes in the repo will *block* git pull/rebase for updates. I regard it as inadvisable.
+1
The latter is also undesirable, but only because we are talking about trying to translate SQL, and for the reasons Frederic points out having to do with translation. Therefore the fix is to do something like allowing to Koha to ingest values from a template file at install and runtime. Read the template (doesn't have to be H:T:P, as long as we can get PO files from it), parse it to whatever, match against keys in the syspref table and update description.
That's how it works now with .pref being specifically tokenized to extract text to be translated which are written into a .po file. -- Frédéric
Ok. Here is a quick fix which seems to be what everyone is headed toward. Please abuse it a bit and see if it meets the present criteria. http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=commit;h=5b23a615... On Mon, Jul 12, 2010 at 2:46 PM, Frederic Demians <frederic@tamil.fr> wrote:
The former case would also change the security profile of Koha significantly. Allowing your application to write to template directories is bad practice. Among other things, if you happen to be running your Koha installations off of git repos (as I know several vendors do), then having new uncommitted changes in the repo will *block* git pull/rebase for updates. I regard it as inadvisable.
+1
The latter is also undesirable, but only because we are talking about trying to translate SQL, and for the reasons Frederic points out having to do with translation. Therefore the fix is to do something like allowing to Koha to ingest values from a template file at install and runtime. Read the template (doesn't have to be H:T:P, as long as we can get PO files from it), parse it to whatever, match against keys in the syspref table and update description.
That's how it works now with .pref being specifically tokenized to extract text to be translated which are written into a .po file. -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
Ok. Here is a quick fix which seems to be what everyone is headed toward. Please abuse it a bit and see if it meets the present criteria.
I try it. It works. But the way you identify local syspref is not the good one, as I understand it. You have in systemprefernces.pl (that you reactivate) a hash of 'official' sysprefs. Then you select all syspref defined in DB which are no in this hash. But it means that if tomorrow I had a new preference in a .pref file I also will have to add it in systempreferences.pl file otherwise it will appear as local. -- Frédéric
On Mon, Jul 12, 2010 at 5:28 PM, Frederic Demians <frederic@tamil.fr> wrote:
Ok. Here is a quick fix which seems to be what everyone is headed toward. Please abuse it a bit and see if it meets the present criteria.
I try it. It works.
Thanks. But the way you identify local syspref is not the good
one, as I understand it. You have in systemprefernces.pl (that you reactivate) a hash of 'official' sysprefs. Then you select all syspref defined in DB which are no in this hash. But it means that if tomorrow I had a new preference in a .pref file I also will have to add it in systempreferences.pl file otherwise it will appear as local.
I think this is an unfortunate side-effect of the "quick and dirty" part of this fix. Perhaps it might be good to open a bug against 3.4 to do at least some major cleanup of this code. There is a lot of it which should be removed. Kind Regards, Chris
I think this is an unfortunate side-effect of the "quick and dirty" part of this fix. Perhaps it might be good to open a bug against 3.4 to do at least some major cleanup of this code. There is a lot of it which should be removed
If your patch, as 'squashed' by Chris C., is committed, I will add quickly to the old syspref editor the ability to display syspref which are exactly the difference between DB and .pref files sysprefs. Thanks again for the good work. I agree that sysprefs design should be discussed further for 3.4: code cleanup and improvement asked by some (sysprefs per branch for example). -- Frédéric
Hi, On Tue, Jul 13, 2010 at 1:45 AM, Frederic Demians <frederic@tamil.fr> wrote:
If your patch, as 'squashed' by Chris C., is committed, I will add quickly to the old syspref editor the ability to display syspref which are exactly the difference between DB and .pref files sysprefs.
Please go ahead and patch against Chris' patch to add this. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
On Mon, Jul 12, 2010 at 1:10 PM, Jesse <pianohacker@gmail.com> wrote:
There were two important reasons for moving the system preference descriptions out of the database.
The first was translation. Translating strings in the SQL files is significantly different than the rest of the translator's workflow (from what I can tell), and requires several skills that Pootle does not. The easiest way to tell this is to look at how many languages have translated interfaces, and how few have translated system preferences. Besides the main targets, en-US and fr-FR, there are only four others that had a translated sysprefs.sql, thanks to the work of Katrin and others. Not many are going to waltz into the Koha project with both good translation skills and enough bravery to translate the SQL. Localizing system preference defaults per-language makes sense, definitely. With the current file-based system, this is separated from translation, and is a much less daunting task than having to translate and localize an SQL file at the same time.
Based on this and Katrin's subsequent reply, I certainly will not argue this point.
Aside from that issue, keeping the two separate was also a very intentional separation of concerns. Aside from the previously-mentioned translation problems, putting interface-related strings in the database is bad practice, IMO. Any practical concerns are important, but I think the current system has this on its side. Today's nitpicky theoretical problems are tomorrow's intractable real-life bugs (fines system, anyone?).
Under the old system, fixing any issues with the system preference display required a database update, no matter how trivial they were. This made little to no sense, considering that these were entirely interface issues. Again, you could create a system to keep the data files and DB in sync without this, but this would be at best confusing and at worse fragile.
Leaving the files where they are makes it clearer that they are intended to be interface-related data, like the XSLT, and translated as such.
I am not utterly opposed to leaving the system as it is if that is the prevailing opinion. As for the fix for the current and future problem however....
My vote for solving the local-use preferences system is to leave the current system as it is, but add a database column or some way of easily distinguishing local-use from non-local-use prefs in the DB (making the explanation column NULL for non-local-use would work, though would require a time-consuming database update). This would make building a local-use tab fairly easy.
Once we do that, we can drop the options column entirely, as I doubt most local-use users will care enough to set it. Theoretically, we could even drop the type column, though that might be useful in the future to help deal with more complex types of system preferences (automatically turning date sysprefs into C4::Dates objects, for example).
Unless no code depends on the type column, I think we should leave it alone for the moment. In the long haul, the table could certainly be cleaned up. The singular problem with local-use sysprefs in the system as it presently stands is the matter of setting the file permissions on the *.pref files. In order for those files to be written from within Koha, the apache user must have write permissions to those files. This is, in theory, a very simple fix. Just fixup Makefile.PL and company to modify the permissions accordingly. It is, in practice, a small nightmare for anyone who is not intimately acquainted with the how's, why's, and wherefore's of this group of scripts. So we need a volunteer... anyone? (Well, this job of writing to files from within Koha will have to be done sooner or later, but maybe later is better.) ;-) A syspref editor working with the syspref system currently in place is really a trivial thing to create. I see no reason to handle local-use prefs any differently than other prefs. Doing so would only complicate things imho. The code I have written so far already serializes new prefs, writes them to the local-use.pref file, and adds the proper data to the systempreferences table. It is in the rough, but clearly demonstrates the possibility of having a working pref editor in the 3.2 release. Given the relative ease with which a permanent solution maybe had, I'd hate to see us resort to a hack to fix bug 3756. Plus, any solution which stores local-use prefs in the db and does not serialize them makes for yet more work when a permanent solution is implemented. Not to mention all of the inherent risks of updatedatabase.pl munging data as it reorganizes it. Kind Regards, Chris
A syspref editor working with the syspref system currently in place is really a trivial thing to create. I see no reason to handle local-use prefs any differently than other prefs.
I see several reasons to handle differently Koha official sysprefs and local sysprefs: * They don't need the complete editor, with typed values, combo list and so on. * People who add local sysprefs know what they are doing. They are not end-users but integrators or developers. * It isn't necessary for local sysprefs to be translatable. So for them being stored exclusively in DB with no .pref template isn't a problem. -- Frédéric
participants (7)
-
Chris Cormack -
Chris Nighswonger -
Fischer, Katrin -
Frederic Demians -
Galen Charlton -
Jesse -
Joe Atzberger