In theory should block entering duplicate info for customers

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enter customer info & save
2. Start new customer
3. Enter exactly same info & save

What is the expected output? What do you see instead?
Expect to see dialog or message that customer already in database.  Instead
screen changes indicating customer info was saved.

Probably don't want to fix this for this project, but it might be worth
documenting as a future issue to resolve.

Original issue reported on code.google.com by bd.gai...@gmail.com on 4 Jun 2009 at 4:23

[GoogleCodeExporter]

We could do a search on First Name, Last Name & primary phone number and 
display a
message in the area below the New Customer input form with the customer name & 
phone
number hyperlinked.  This would be simple to implement with the given 
infrastructure.

Any thoughts?

Original comment by bd.gai...@gmail.com on 13 Jun 2009 at 5:47

[GoogleCodeExporter]

If we follow this logic, all the pieces that we need for this implementation 
are 
almost all there. 

The flow will be like this:
In saveCustomerInfo, we first call validateCust, then add the new step to call 
searchForMatchingCustomers (on first_name, last_name, phone_number); if the 
search 
return nothing, we continue with the existing logic; otherwise we return the 
list 
(to be displayed) and some error code (or even raise an exception)to signal 
that 
duplicate was found and we need to display the found customer instead of saving 
the 
customer again.

I think it's a good solution and not too much extra coding is required to get 
this 
to work. Worth a try.

Original comment by fionawhw...@gmail.com on 13 Jun 2009 at 8:01

[GoogleCodeExporter]

I think Wing's solution at the Model level is worth trying.  I would refine 
this in 2
ways.  

First, be sure to only check for duplicates when saving a new customer -- we 
don't
want to block an update of customer information.

Second, I would consider creating a new exception DuplicateCustomer or
DuplicateRecord and subclass it off of ValidationError.  This subclassing does 3
things.  It allows the existing error handling notification implemented in the 
View
to be used in the short run without changing interfaces.  It also allows the
Controller to catch this exception explicitly to modify how we might handle user
notification in the future.  And finally, it provides a place to add a local 
variable
and access method for holding the duplicate customer record for (the future)
reporting of this info to the user.

If you want, I think you should go ahead and implement this capability in the 
Model.
 If you want to test it, just uncomment the code I added to saveCustomerInfo in
dermico.py and update the import statement at the top of the module to import
DuplicateCustomer.  If you can do the subclassing scheme as described, you 
should see
your duplicate customer error message in the lower left corner of the side 
panel.

Let me know if any of this needs to be clarified.

Original comment by bd.gai...@gmail.com on 13 Jun 2009 at 4:06

[GoogleCodeExporter]

searchForMatchingCustomers should be case insensitive otherwise we may still 
end up with duplicates (i.e  Win 
Wong 650-415-1212  &  wi wong 650-415-1212). One way to do this will be to 
normalized form inputs (All 
upper case or title case: JUAN MARCO DEL TORO/ Juan Marco Del Toro) either in 
the validation sequence or 
before the validation takes place.  ~j

Original comment by jerome.c...@gmail.com on 14 Jun 2009 at 5:42

[GoogleCodeExporter]

I looked at the appengine discussions and there appear to be 2 suggested 
solutions to
this problem.  One is to use a package that was built as a 'hack' to help out 
in this
area until they do a better job of solving the problem.  The other was to save a
canonical form of the search information as additional information in the 
database. 
In our case, we could store the first name and last name information converted 
to
lower case in a couple of additional fields in the database and use those 
fields when
performing the search.  

In theory, we would want to do this for other fields as well (address, etc.) 
but for
blocking duplicate records, first name and last name would be sufficient.

Also, we could even combine into one string "last_name, first_name" so that we 
only
need one extra field.  I don't know if this has any impact in terms of the 
indexes
that need to be generated to support the search operation.

Original comment by bd.gai...@gmail.com on 14 Jun 2009 at 6:02