[Koha-devel] Moving system preference serialization into the database

[Chris Nighswonger]

On Mon, Jul 12, 2010 at 1:10 PM, Jesse <pianohacker at 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