http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167 Jonathan Druart <jonathan.druart@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.druart@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)?".
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
Now, we can "mark as ok" versions which are already executed. (Else, we had to delete manually the corresponding file) 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.