Jump to content

Issue with 'not found by' filtered searches


theflights

Recommended Posts

We have a problem with the premium member filtered search facility, specifically when using the 'not found by' field.  This problem has been going on for at least a year now and, now we have more freedom, it is now really causing us issues when trying to meet up with friends to geocache.
 

We have tried numerous scenarios on two different computers and three different browsers.  One browser was a virgin installation which had never been used for anything else.  
 

When searching using 'not found by' for a lowercase username there is no problem at all - all results are correct.  However, if carrying out an identical search but for a user with at least one capital letter in their name, the results are wrong.  The results appear to ignore that user on the map.  The results in the search list are correct, but they do not translate over to the map.  However, friends (both with uppercase in their name and all lowercase) can carry out exactly the same searches without a problem, therefore the issue appears to be with our account rather than computer related or across the board.  
 

We have been in touch with Groundspeak and, as far as they are aware, nobody else has the same problem and they can't recreate it.  They have asked us to post here to see if anyone else has the issue which, hopefully, will enable them to do more research and see if they can get to the bottom of the problem.
 

Please let us know if you have the same problem or have had the same issue and know how to resolve it.


Many thanks

Link to comment
11 minutes ago, Max and 99 said:

Can you explain this please? I've been testing out the search as you describe.

I will try.  When using the search filter to show caches 'not found by' any user with a capital letter in their name, the initial list of results comes up as correct.  Then, when I click on 'Map these Geocaches' the results are incorrect and will show geocaches that user has already found, thus not filtering any of the finds out.   I have attached an image, with permission of the user concerned, Goldfish58.  The arrows shown indicate two caches I know that Goldfish58 has already found.  The URL is shown in the picture, shows we should be looking at 'NFB' caches.   The second image is exactly the same search carried out by a friend and shows the correct results.

Search Glitch.png

Correct Search.jpg

Link to comment
5 minutes ago, theflights said:

I will try.  When using the search filter to show caches 'not found by' any user with a capital letter in their name, the initial list of results comes up as correct.  Then, when I click on 'Map these Geocaches' the results are incorrect and will show geocaches that user has already found, thus not filtering any of the finds out.   I have attached an image, with permission of the user concerned, Goldfish58.  The arrows shown indicate two caches I know that Goldfish58 has already found.  The URL is shown in the picture, shows we should be looking at 'NFB' caches.   The second image is exactly the same search carried out by a friend and shows the correct results.

Search Glitch.png

Correct Search.jpg

Then I confirm this behavior.

Link to comment
3 minutes ago, Max and 99 said:

Then I confirm this behavior.

Thank you very much, I pleased it's not just me!   I will wait and see if anyone else has the issue too and then report the findings back to Groundspeak.  Hopefully, they will get to the bottom of it and resolve it.

Link to comment
1 minute ago, Nylimb said:

In the URL, "goldfish58" is not capitalized.  If you capitalize the "g" in the URL, does the same problem occur?

I noticed that too.   I did capitalise it but it immediately goes back to lowercase.   The G is also not capitalised in the search carried out by a friend (second image) and that one shows the correct results. 

Link to comment
6 minutes ago, theflights said:

I noticed that too.   I did capitalise it but it immediately goes back to lowercase.   The G is also not capitalised in the search carried out by a friend (second image) and that one shows the correct results. 

Too bad.  I'd hoped it might be a workaround until the bug is fixed.

Link to comment
2 hours ago, thebruce0 said:

I posted about this weeks ago - haven't seen any replies or response:

Loading parameters into the Map search view has problems.

That is very interesting.   Can you narrow it down to searching for NFB for a user with at least one capital letter in their name?  I did have problems last year whereby I would type a username and I basically got a white dropdown box with no user avatars.  I presumed it was a glitch as it did rectify after a few weeks but I'm now starting to wonder if that was the beginning of my problems.

Link to comment

I just did some testing with some usernames in my area. When I tried it with a username that contains all uppercase letters (as well as a hyphen), I got the same result as you: caches that should have been filtered out were displayed on the map.

 

When I tried the same thing with a username that contains only lowercase letters and numerical digits, the caches they found were filtered out as expected.

 

I then did a series of tests for various combinations of different character classes (uppercase, lowercase, digits, punctuation, spaces). The only class of characters that causes this issue is uppercase letters. You could have the name "tester123 456-7", and it will work as expected. However, the inclusion of even a single uppercase letter then breaks it.

 

Earlier posts pointed out that uppercase letters are automatically changed to lowercase in the URL, so it could be that the search engine is doing a case-sensitive search when looking up the lowercase-ified username in the database and not finding a match. If this is what's happening, it could be resolved by either not changing the case in the URL, or changing the underlying search engine to do case-insensitive lookups in the database.

 

This is also very easy to reproduce. Look up a cache that a user has found. Filter for "Not found by" that user, map the results, and see if that cache is filtered out of the map. That cache shouldn't be displayed, but it will be if the username contains an uppercase letter.

  • Upvote 1
  • Helpful 1
Link to comment

To add to that... the issues I mentioned in my thread above aren't affected.  Those UI issues are causing a different problem.

 

For example: I have a bookmark for a search (list view), NFB myself and two friends - one of them has capitals in her username. The querystring for the search includes the capitals. The list search is correct.

 

As mentioned, clicking Map these results opens a tab with the same filters but her username is sent in all lowercase (querystring). That could be a problem - however: The map filters DO include her proper username (with capitals) in the list of NFB users. So the UI is case-insensitive for populating the filters on loading, but the search does not take her username into account.

As mentioned in my thread, I need to make an adjustment to the filters so that the "Done" button is available (applying the 'new' filters - even if they're the same) and then the map search results DO take her username into account.

 

There's absolutely some oddities happening with the UI for the "Not Found By" filter on the Map Search page.  These two threads are highlighting them.

 

 

My take:

The search parameters by querystring are conducting the search on the server end first, but as the page loads, the front end is interpreting the parameters as a user would interact with the page in order to fill the filter fields. Thus, the initial cache search is using all-lowercase usernames (per the querystring), but the UI is doing the username search case-insensitive in order to populate the NFB filter. So the user SEES the proper username in the field, but the initial search is not including the proper username.  And, once the search filters are updated manually, the front-end UI sends the correct username (w/capitals) and the search results are repopulated with the correct results.

Edited by thebruce0
Link to comment
1 hour ago, The A-Team said:

I just did some testing with some usernames in my area. When I tried it with a username that contains all uppercase letters (as well as a hyphen), I got the same result as you: caches that should have been filtered out were displayed on the map.

 

When I tried the same thing with a username that contains only lowercase letters and numerical digits, the caches they found were filtered out as expected.

 

I then did a series of tests for various combinations of different character classes (uppercase, lowercase, digits, punctuation, spaces). The only class of characters that causes this issue is uppercase letters. You could have the name "tester123 456-7", and it will work as expected. However, the inclusion of even a single uppercase letter then breaks it.

 

Earlier posts pointed out that uppercase letters are automatically changed to lowercase in the URL, so it could be that the search engine is doing a case-sensitive search when looking up the lowercase-ified username in the database and not finding a match. If this is what's happening, it could be resolved by either not changing the case in the URL, or changing the underlying search engine to do case-insensitive lookups in the database.

 

This is also very easy to reproduce. Look up a cache that a user has found. Filter for "Not found by" that user, map the results, and see if that cache is filtered out of the map. That cache shouldn't be displayed, but it will be if the username contains an uppercase letter.

Thank you very much for taking the time to do the research and report back.  I hope Groundspeak are able to resolve this issue soon as it clearly affects other users and not just me.

  • Funny 1
Link to comment
1 hour ago, thebruce0 said:

To add to that... the issues I mentioned in my thread above aren't affected.  Those UI issues are causing a different problem.

 

For example: I have a bookmark for a search (list view), NFB myself and two friends - one of them has capitals in her username. The querystring for the search includes the capitals. The list search is correct.

 

As mentioned, clicking Map these results opens a tab with the same filters but her username is sent in all lowercase (querystring). That could be a problem - however: The map filters DO include her proper username (with capitals) in the list of NFB users. So the UI is case-insensitive for populating the filters on loading, but the search does not take her username into account.

As mentioned in my thread, I need to make an adjustment to the filters so that the "Done" button is available (applying the 'new' filters - even if they're the same) and then the map search results DO take her username into account.

 

There's absolutely some oddities happening with the UI for the "Not Found By" filter on the Map Search page.  These two threads are highlighting them.

 

 

My take:

The search parameters by querystring are conducting the search on the server end first, but as the page loads, the front end is interpreting the parameters as a user would interact with the page in order to fill the filter fields. Thus, the initial cache search is using all-lowercase usernames (per the querystring), but the UI is doing the username search case-insensitive in order to populate the NFB filter. So the user SEES the proper username in the field, but the initial search is not including the proper username.  And, once the search filters are updated manually, the front-end UI sends the correct username (w/capitals) and the search results are repopulated with the correct results.

Thank you very much for your work and reply.   I can confirm that carrying out the 'adjustment' to the filters on the map page and clicking done, but changing nothing does give the correct result.  Thanks for pointing that out and I will be able to use that workaround until Groundspeak get to the bottom of the problem. 

Link to comment
37 minutes ago, thebruce0 said:

It would be great to hear feedback from a lackey that this bug has been noted; whether it's high priority for fixing or not :)  This is one of those threads that can disappear quickly from sight, but hopefully not out of sign out of mind...

Yes, I agree with you on that.   I currently have an open ticket with Groundspeak and have linked this thread to the ticket.  I have been assured it will be dealt with but was given no timescale.

  • Funny 1
Link to comment
On 6/4/2021 at 5:37 PM, Frau Potter said:

Thank you for all the repro steps! With the help of everyone in this thread we were able to put together repro steps to report to the engineering team (and we see that tricky work-around). We will try to get this fixed soon.

Frau Potter,

Any update in the 2 1/2 months since you posted? I'm still seeing a problem with the results ignoring the "Not found by" parameter. Thanks.

Link to comment

I haven't heard anything from Groundspeak since I highlighted this post to them in May as part of my open ticket.  I have been using the workaround.   However, the workaround seems to have failed now too.  I searched tonight, using the 'filters' on the map page.  The URL keeps the capital letter in the username but it is not filtering out finds for the user.

Link to comment
31 minutes ago, theflights said:

I haven't heard anything from Groundspeak since I highlighted this post to them in May as part of my open ticket.  I have been using the workaround.   However, the workaround seems to have failed now too.  I searched tonight, using the 'filters' on the map page.  The URL keeps the capital letter in the username but it is not filtering out finds for the user.

I'm wondering how this bug fits in with today's Release Note. I cannot check it out myself yet.

Link to comment
45 minutes ago, Max and 99 said:

I'm wondering how this bug fits in with today's Release Note. I cannot check it out myself yet.

 

It's very broken here right now.  In Internet Explorer, after I get search results, anything I do with the Filters (including leaving them where they were), that search gives me the whole world instead of my location.  I cleared cookies and history, same thing.  In Brave, the whole page reverts to the start "Search" screen as if I haven't done a search.  If it's just me, I guess I can post versions and stuff.  But this is new.

 

Anyway, I didn't even get to the point of comparing upper and lower case.

 

Edited by kunarion
Link to comment

Not sure if this is a new problem or just new to me. I did post elsewhere about it.

 

Reading some of the above comments, I can't help but add something:

On the desktop version, it keeps resetting my default map filters to exclude my finds and my own hides.

 

Every time I go to the map lately (the last couple of weeks), I have to go into filter preferences and change it back to what I like (showing finds, showing hides, and under "not found by", eliminating the entry of myself.  I then hit the "apply" button and it becomes the map I want to see.

 

BUT THEN IF I LEAVE THE PAGE OR OPEN MAPS IN A NEW TAB, IT RESETS ITSELF TO IGNORE MY PREFERENCES, AND I HAVE TO GO ADJUST THE FILTERING ALL OVER AGAIN !

 

You have no idea how angry this makes me. Well, the fact that I logged in to make a forum post or two about it, and the fact I just did all caps shouting should tell make it clear.

 

Like keyboard-smashing angry.

 

"They" probably think this is helpful, but it's not. I want to see what I choose to see ! If I choose to see my finds and my hides, so be it !

 

1) The site should be remembering my preferences (at the very least as long as I remain logged in and the cookies are still valid), not resetting them to exclude most of what I see on my local area map.   

 

AND/OR

 

2) The default filtering should be no filtering at all. Let members choose to exclude what they do not want to see - do not make the choice for them automatically !

 

 

  • Helpful 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...