-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User is not found when is searched by name and one of surnames #7510 #8760
Conversation
Followup to #8178 |
wrt #8178 (comment), $this->connection->ldapMedialSearch would not need to be needed, but it would check the presence of an asterisk at the beginning of the word. So, all that needs to be done is breaking up the term into words. The queston is whether you need to have an asterisk before each word (less user friendly, more exact) or just once in the beginning of it (easier, less flexbile, potential for frustration, but essentially the same as if the setting would be set → I'd favor this). |
@blizzz, let me understand, do you propose something like this?
|
yes… well sort of. breaking up words is dependend on whether spaces are provided, and only then asterisk are prepended or not. |
Right, @blizzz. Would the change below be more appropriate then?
|
The method will get single words, only, see |
Yes, @blizzz, excuse me, I was, as we say here, "traveling on mayonnaise". Last snippets are unuseful because only repeat what previous method does. Variable $term already is a single word because Then, I think that following change maybe is that you should favor for
|
In that case you will end up with double asterisk in front. When passing any word to |
Hey, @blizzz, then it is a bug in current code, because if $term is equal to asterisk, $result will be a double asterisk:
I want to say that this code needs to be changed anyway. It seems to me that is enough to check the length of string, so: Replace:
for:
Can it be so? |
No, there can be only an asterisk at the beginning of the whole search term, any other occurrence is escaped. |
Right, if I understand now - otherwise I will generate a test case because it's getting confused - we can change if.. else.. structure to two if statements so:
if $term is equal to '', $result will be ''. I hope I didn't drink this time. |
Test cases would be great :D again, prepending should only happen, when the whole phrase was started with an asterisk. |
Codecov Report
@@ Coverage Diff @@
## master #8760 +/- ##
============================================
+ Coverage 51.68% 51.87% +0.18%
+ Complexity 25720 25379 -341
============================================
Files 1641 1608 -33
Lines 96441 95180 -1261
Branches 1393 1377 -16
============================================
- Hits 49850 49370 -480
+ Misses 46591 45810 -781
|
If "prepending should only happen, when the whole phrase was started with an asterisk", I think that proposal change can be discarded and replaced by that:
|
Let me show about need of asterisk prepended to term with some tests. I want to find Roger. Complete name is "Roger Luis Padilha de Souza". See the results according use of asterisk prepended and/or appended:
Search only for Roger in this case is not appropriate. If I know him as "Roger Luis" (test2.txt) and better as "Roger Luis Padilha" (test3.txt), the current implementation ($term . '*') is enough. But if I know him as "Roger Padilha"? Current implementation does not show results (test4.txt). But with an asterisk prepended (test6.txt), I got him. In theory, current implementation should find Roger from "Roger Padilha" in search box, according test10.txt, but it does not happen and I don't know why. Below there are some examples of names that can be found in our LDAP directory. Inside context presented before, imagine to find "Maristela Midlej Silva de Araujo Veloso" knowing her only "Maristela Veloso":
|
@fgsl yes, the approach in #8760 (comment) looks good. Just, when doing comparions, always do it strictly: For the tests I had unit tests in mind (apps/user_ldap/tests/AccessTest.php). If feasible? |
Nothing for 14 it seems -> moved to 15 |
Fixes #7510