http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167
Jonathan Druart <jonathan.dru...@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #9859|0 |1 is obsolete| | Attachment #9860|0 |1 is obsolete| | Attachment #10033|0 |1 is obsolete| | Attachment #10034|0 |1 is obsolete| | --- Comment #72 from Jonathan Druart <jonathan.dru...@biblibre.com> --- Created attachment 10549 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10549&action=edit New version for updatedatabase At last, I come back ! :) (In reply to comment #70) > QA comment: > For simplicity, I recommend to remove the YAML file and associated code. Done > Skeleton: I see it in a regex as well as some code inserting into foo. > Assume that it was used in testing. Please remove it. Done > Mainpage: Some code was removed from Auth.pm. The version check is now in > mainpage.pl itself. I would rather have that check in an appropriate module. > It was in Auth.pm. You could leave it there? I think we should let the > version check stay within the scope of the checkauth call included in the > get_user_and_template call. (See also comment on Auth.pm below). New routine C4::Update::Database::is_uptodate() called on mainpage.pl The idea is to update the source code AND see the admin page (admin/updatedatabase.pl) to check if the database is up to date. > Note that there is some problem in current code, that forces me to login > twice when there is an update available. (It redirects to > admin/updatedatabase, but I must relogin again.) I can't reproduce this error, then I can't fix it. Can you give me more details please ? > Upgrading: When coming from an older version (before 3.9.0.x), you should > run the old updatedatabase and after that you should run the new dbrevs in > the dbrev directories. This is currently done in two passes. First it runs > the old update. You think that it is ready. When you login, you are prompted > to the new update form. It should not be too difficult to merge this into > one pass (less confusing). Please adjust install.pl for that: You should > check if it is still needed to call the old update before running the new > one (for numbered dbrevs only). I don't know how I can do this simply and properly. if someone feels motivated... > File structure: As mentioned above, make directories for a Koha release. > Getting all updates means fetching the updates from a few directories. This > makes the feature more future-proof. I create all of .sql and .pl until version 3.09.00.018 (current master) > Stable version: The md5 test will be of good use here! If we backport this > to 3.8.X, we could already check what updates we already have run from 3.9 > folder with the md5 checksum. When upgrading from 3.8 to 3.10, some dbrevs > are new, others will be incorporated already. So this remark only serves the > purpose of discussing "Should we also get this into stable already (within > reasonable time)?". Now, we can "mark as ok" versions which are already executed. (Else, we had to delete manually the corresponding file) > admin/updatedatabase.pl: Line 33 adds a fixme to new code: Add a new flag? Finally I use the "parameters" flag. I don't know if we want a special permission. > Commit message: please make it up-to-date. E.g. section on installdir. Done + Errors are now translatable This patch squashes the 3 others. I switch back to needs signed-off (A quick signed off is needed) -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/