| Summary: | AllowItemsOnHoldCheckout has columns in wrong order in sysprefs.sql | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Magnus Enger <magnus> |
| Component: | System Administration | Assignee: | Paul Poulain <paul.poulain> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | trivial | ||
| Priority: | P5 - low | CC: | chris, gmcharlt, m.de.rooy |
| Version: | 3.8 | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: |
Bug 7726: explanation and options that were in the wrong order
Bug 7726: explanation and options that were in the wrong order |
||
Created attachment 8643 [details] [review] Bug 7726: explanation and options that were in the wrong order I also removed the ` mysql-ism (In reply to comment #1) > Created attachment 8643 [details] [review] > Bug 7726: explanation and options that were in the wrong order > > I also removed the ` mysql-ism If these files are to become non database specific, moving them out of the mysql dir makes sense. Removing mysqlisms from mysql specific files doesn't seem like a hugely useful thing to do. In this case it doesn't break anything, in the case of removing them all from the mysql/kohastructure.sql it renders that file unable to create a database. So a blanket policy of removing them under all circumstances is dangerous. Making updatedatabase.pl db agnostic makes sense, making the schemas .. not so much. Created attachment 9039 [details] [review] Bug 7726: explanation and options that were in the wrong order I also removed the ` mysql-ism Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Updates an old DBRev to fix the issue, rather than updating the values in the existing database. The result, for anyone who has upgraded since 3.07.00.012, will not fix their database values. This is exceedingly minor, since these values are not displayed in the syspref editor, but better do fix this completely than only partially. Marking Failed QA (In reply to comment #4) > Updates an old DBRev to fix the issue, rather than updating the values in > the existing database. The result, for anyone who has upgraded since > 3.07.00.012, will not fix their database values. > > This is exceedingly minor, since these values are not displayed in the > syspref editor, but better do fix this completely than only partially. > > Marking Failed QA I this had been released I would agree. But since it hasn't, I disagree. And: * I don't have time to provide a new patch * releasing with this mistake (in less than 2 weeks) would be a shame So, I think this patch should pass QA, pushed, and I can move it to "assigned" again, for a more complete fix later. QA Comment: I would not object to push it. It resolves a bug (the sooner, the better). I agree with Ian that you could also send a followup to fix installations that already past this point. Passed QA Patch pushed to master before 3.8 release. Switching back to ASSIGNED though, to provide a fix for installations already updated This has been pushed to 3.8, we didn't get any complaints and it would only have affected people installing an unstable release for a short amount of tim - I am closing this. |
installer/data/mysql/sysprefs.sql has this, on line 341: INSERT INTO systempreferences (variable,value,options,explanation,type) VALUES ('AllowItemsOnHoldCheckout',0,'Do not generate RESERVE_WAITING and RESERVED warning when checking out items reserved to someone else. This allows self checkouts for those items.','','YesNo'); The order of the columns should be switched to this: (variable,value,explanation,options,type) The problem is also present in updatedatabase.pl: $dbh->do("INSERT INTO `systempreferences` (variable,value,options,explanation,type) VALUES ('AllowItemsOnHoldCheckout',0,'Do not generate RESERVE_WAITING and RESERVED warning when checking out items reserved to someone else. This allows self checkouts for those items.','','YesNo')"); This does probably not have any practical implications (hence severity = trivial), since the "explanation" is not used anymore and "options" is not used when the type is YesNo (I think?).