Fri 21 Aug 2015 11:28:34 AM UTC, comment #1:
Hi Luis
Thanks for the feedback and suggestion !
Yes. Today generic search will stop at the first match, so it is quite fast. However, you have a good point, since it would miss other subsequent entries.
I will implement the functionality for 3.0. We would have to check that it does not affect performance.
For the current 2.8 , you can include the OR operator in the search entry field. It does field name auto-completion, so it would be fast.
In your example, you would put on the filter field :
"Last Name": Luis or Name: Luis
This will bring back all the records containing "Luis" either in name or lastname
Best,
|
Mon 17 Aug 2015 10:42:07 PM UTC, original submission:
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.
|