Borrowers who self register are not checked against existing borrowers for duplication. This may be ok in large libraries who have staff to check the incoming queue rigorously, but for small libraries who want all borrowers to self register, this is a big problem. If a borrower forgets their password or misses the password during self registration, they can create as many accounts as they like with the same information. This can be very confusing for library staff - as the library staff doesn't know which account is the active one, or the borrower may have many active accounts I think this should be a toggleable option.
Sounds reasonable. So, how would duplication be dealt with at the patron side? Say they register for a second account, they can't use the e-mail alone, as several members of the household may be registered under the same e-mail address. Should it be a combination of e-mail address and name, or just name? What if the name is one off? Say they spell it slightly different, or extra spaces? Christopher
Hi, there is a new patch on the way to master - bug 16275: it allows to duplicate check on the e-mail address and will prevent another registration if there is already an account with this address. Liz, does this resolve the issue for you?
Primary email check is a great start thank you, but we need a more robust way of checking, several fields if possible.
I agree with Emma, this needs to be at least as robust as the staff client duplicate borrower checking. I envision some scenarios as follows: Let's just say we have a user who has registered a year or two ago, and can't remember they did. This person registered in the library, using a paper form, and their data was input into the system by a librarian based on the fields required in the staff interface. I'm going to assume for the sake of the exercise, that the library allows users to reset their own password by email. This person now comes to the library website, and has forgotten their username/password. They don't remember that they have even used the library website before (maybe they haven't). This user cannot accomplish what they want to without an account, so they decide to register. Sensible. User registers online, using the form specified by the library. Koha will then check those required fields and look for a user in the existing database that matches to some great extent, i.e. if we ask for 10 items of information, let's say if 6 match and one is an email address in any of the address fields, we have a suspected duplicate user. At this point, we can do one of several things: 1. suggest to the user that maybe they've already registered, please go to the library (which one?) because sorry we can't resolve this online. This is ok, but pretty bad service for a modern web app. 2. If we have a matching email address in any of the email fields (configurable?), and a strongly suspected duplicate, send an email with password recovery instructions to the matching email account. The user may not have access to this account - but that isn't our problem. It is much better than sending them away! Something like "We noticed you were trying to register, but we think you might already be registered with the library. Would you like us to email you information on how to recover your account?" If accepted, the email would help them reset their password and take them through the "forgotten password" workflow. If the user declines, send them to the library for in-person help. Alternately, we could If we have a strongly suspected duplicate, but no email address in any collected email field, we would not offer to send anything - "We can't register you online, sorry." 3. add the user but flag it with MANY FLAGS AND BLINK TAGS as PROBABLY DUPLICATE and note which borrower, and put it in the patron modification queue for a librarian to merge with the existing user. We will want to prefer the username and password that the user has just created with the new registration so they can still log in. There are other scenarios but I don't really have clearance to think about them right now. I do welcome discussion. Cheers, Liz
*** Bug 14856 has been marked as a duplicate of this bug. ***
This would be helpful for us as well. Lisette
+1