I have an interesting idea about the system preference request in the last point here.
Have the system preference editor create in the database a row for any pref's it didn't find there. It would have to keep track of what the default value should be for all pref's though. With the new system preference editor, as I understand it, changing the text of a pref is changing a file instead of the database now, so that's one of the two cases I can think of for a system preference to change the database. The other case is to create or delete a system preference. Let's put aside creating for a moment. Thinking about deleting a pref, I might argue that it shouldn't lightly be taken out of the database. Currently is is removed from the system preference editor, and ends up in the Local Use category. Maybe this category could be renamed 'Local Use / Deprecated'. The problem then becomes that the system preference editor isn't run often enough. So maybe there needs to be an addition to the version check in Auth.pm. Along with checking kohaversion.pl it could also check something like 'sysprefs.pl' to make sure all officially supported system preferences are in the database. Then the update mechanism could create the system preference instead while asking for it to be set ( if the user doesn't want to use the default setting ). That might be the way to go. Have a 'sysprefs.pl' that checks the database, and add to the update mechanism to create any that it reports as not being there. That way developers would be changing a file(s) instead of the database. On Wed, 2010-02-03 at 11:59 -0500, Galen Charlton wrote: > Hi, > > Quickly, from my point of view the main things I'd like to see in a > revised database update system are: > > * the ability to end up with a linear set of database updates in > released versions, for the reasons Joe mentions > * secondarily, the ability to have a linear path in HEAD > * a reduction in purely textual merge conflicts - splitting up the > monolithic updatedatabase.pl would go a long way to address this > * a better way to manage database updates that are backported to the > maintenance branch > * a mechanism to allow a developer to readily renumber updates that > they're working on in a topic branch when it comes time to submit to > HEAD > * getting simple system preference updates out of the main > > Regards, > > Galen -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
