When updating an existing patron an error message comes up about the birthday being invalid. It will let us save the record but puts in a birth date of 00/02/0. There shouldn't be an error about the birthday field if it's not required and it shouldn't be populating it if we don't want it to.
I can confirm this: If you edit a patron record which has a NULL dateofbirth, and leave the birth date field blank, after saving the record the dateofbirth column contains "0000-00-00"
git bisect blames the fix for Bug 6253.
Created attachment 6327 [details] [review] Proposed Patch Fixes dateofbirth issue, but makes a change deep in SQLHelper. Please test not only this bug, but also re-test bug 6253 to verify we're regression-free (my initial tests show that's so, but I could be missing something)
Created attachment 6330 [details] [review] [Signed Off] Bug 7134: patron records getting corrupted birthdates If no date of birth is provided in a new member form, the borrower gets the birthdate of "00/02/0", which is obviously incorrect (the result of passing 0 to the database directly) The fix is to remove a conditional check buried deep in C4::SQLHelper. This is in a helper subroutine that was changed for the Unified Member Search dev (bug 6253). Reverting this small change to the conditional does not seem to break search, but testing will be required. To test: 1. apply patch, and create a new patron with blank birthdate. The new patron should now have a blank birthdate instead of '00/02/0' 2. search for a borrower by 1 part surname, confirm search works 3. search for a borrower by 2 part surname, confirm search works 4. search for a borrower across firstname AND surname; confirm 5. search for a borrower and include categorycode/branchcode filters Signed-off-by: Liz Rea <wizzyrea@gmail.com> I confirm all working tests 1-5 1. Created patron with blank birthdate - birthdate was blank 2. Searched for patron "henry james acevedo III" by using "acevedo" - result was correct 3. Searched for mr. acevedo using "Acevedo III" - result was correct 4. Searched for Henry James Acevedo III, Henry Acevedo and James Acevedo - results were correct 5. Searched for Mr Acevedo with the branch he was not in, with the branch he is in, with a category he was not, and a category he was. All results were correct. also noted: inner searching seems to be working now? Example: Henry James (firstname) Acevedo III (surname) - searching James Acevedo brings back the correct patron. Not complaining, just noting. :)
I should note I confirmed the bug itself before I applied the patch - nasty bugger.
QA comment : small patch, addresses the problem, perfect test plan Patch pushed, please test
It appears that this patch broke the db dependent version of SQLHelper.t It would be great if we could get a follow-up patch to correct this so Jenkins will stop complaining. :-)
Deep and confusing problem in SQLHelper.pm. Not sure if the test can be corrected; logic still looks right. Any any change to SQLHelper will likely lead to more bugs elsewhere in the system. Not an easy issue to squelch.
(In reply to comment #8) > Deep and confusing problem in SQLHelper.pm. Not sure if the test can be > corrected; logic still looks right. Any any change to SQLHelper will likely > lead to more bugs elsewhere in the system. Ian, i'm not sure the problem comes from SQLHelper here. It's probably the test that must be fixed. I had a look, but I don't understand well how it works, I still have to investigate more.
(In reply to comment #9) > (In reply to comment #8) > > Deep and confusing problem in SQLHelper.pm. Not sure if the test can be > > corrected; logic still looks right. Any any change to SQLHelper will likely > > lead to more bugs elsewhere in the system. > > Ian, i'm not sure the problem comes from SQLHelper here. It's probably the test > that must be fixed. I had a look, but I don't understand well how it works, I > still have to investigate more. Perhaps hdl could look into this since he wrote SQLHelper?
I have fixed on bug 5327
This was included in the 3.6 branch prior to 3.6.4.