Bug ID: 18636
Summary: Can not save new patron on fresh install (Conflict
between autoMemberNum and BorrowerMandatoryField)
Change sponsored?: ---
Priority: P5 - low
Assignee: [hidden email] Reporter: [hidden email] QA Contact: [hidden email] CC: [hidden email], [hidden email]
Tested on a fresh install on current master
- Go to Koha > Patrons > Add patron (full form)
- Verify that label for card number reads: "Card number(leave blank for auto
calc during registration):"
- Do not enter anything in field card number
- Enter surname, try to save
- Form does not save because field card number is required
- autoMemberNum is on by default
(sysprefs.sql line 65)
- BorrowerMandatoryField contains surname|cardnumber by default
(sysprefs.sql line 86)
- Full form does not save because card number is mandatory and empty
Note: With quick add form and settings above, cardnumber is not displayed, form
What to do?
- Better explanation for autoMemberNum and BorrowerMandatoryField
- Set defaults for autoMemberNum and BorrowerMandatoryField in a way that they
do not conflict?
- Ignore cardnumber being a mandatory field if autoMemberNum is on?
- Ask for settings in onboarding tool?
What |Removed |Added
CC| |[hidden email]
--- Comment #2 from Katrin Fischer <[hidden email]> ---
Hi Krishna, this is more of a support question I think and would be better on
the mailing list or in IRC. Please state which version of MySQL you are using.
If it's 5.7 or later it's strongly recommended you switch to MariaDB as there
are a lot of known problems with 5.7 being more strict.
The documentation as part of the patch says if AutoMemberNum is ON, then
BorrowerMandatoryField should not contain cardnumber. If I remove cardnumber
from the BorrowerMandatoryField, then on adding a patron a long number gets
generated as the card number.This is happening after upgrading to 17.05.
Earlier, we were using 16.05 and there the card number was getting auto
generated by adding one to the last added patron's card number. So we had
numbers like say 125, 126 etc(we are a small library) whereas the settings
suggested in 17.05 leaves us with an unwieldy 14 digit card number.
Katrin, I will reconfirm on the MySQL version. Am not sure about that. Do you
think this is related to the autoincrement issue at the database level ?
--- Comment #5 from Katrin Fischer <[hidden email]> ---
Hm, this might not be an update issue. The cardnumber is generated by looking
for the biggest used number in your database and adding 1. If you do something
like: select max(cardnumber) from borrowers; what does it give you? If you want
to get back to low numbers, you might just have to clean up a few records.