health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Health-dev] [bug #45786] Party search doesn't work when a last name is


From: Luis González
Subject: [Health-dev] [bug #45786] Party search doesn't work when a last name is the same of another party's name
Date: Mon, 17 Aug 2015 22:42:08 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0

URL:
  <http://savannah.gnu.org/bugs/?45786>

                 Summary: Party search doesn't work when a last name is the
same of another party's name
                 Project: GNU Health
            Submitted by: luisg123v
            Submitted on: Mon 17 Aug 2015 10:42:07 PM GMT
                Category: Functionality
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None
                  Module: health

    _______________________________________________________

Details:

When a party is searched, it looks for matches in fields like name, last name,
PUID, etc. However, if it finds a matching party using one of those fields,
the search stops automaticly. That would lead to not finding a matching
result.

For instance, if we are looking for a party whose last name is "Luis", and
there is another party whose name is also "Luis"; the search will find a match
using the field name, and then it will stop; causing the party not being
found.

The simplest solution I can think of, is to replace the method
"search_rec_name" (class PartyPatient, health.py) with the following code:
________________________________________
result = ['OR']
for field in ('name', 'lastname', 'ref', 'alternative_ids.code'):
    result.append([(field,) + tuple(clause[1:])])
return result
________________________________________

That will return a clause containing a logic OR operator, that will take into
account all possible matching fields.

Also, if that is not possible, I think it would be convenient to at least
prioritize the field PUID, i.e. locate it at the beginning of the tuple.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45786>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]