Skip to content
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

Show owned caches when selecting "not found" filter even if the are found (meant for adopted caches) #15697

Open
eddiemuc opened this issue May 5, 2024 · 6 comments
Labels
Feedback required Issue requires feedback of the author or another user Support Issue related to one or more Support Tickets

Comments

@eddiemuc
Copy link
Contributor

eddiemuc commented May 5, 2024

From support ticket 240413:

A user asks to show found caches even when "not found" filter is selected if those caches are owned. This is meant for adopted caches.

User has adopted a cache (e.g. he is now the owner) but has also found that same cache many years ago. So this cache is legitimate both owned and found by him at the same time.

He asks now for showing this cache on the live map, even when he sets the filter "found=true".

I am at a loss how this could be possible or how c:geo could be adopted to support suche a feature. I thought about using an "OR"-filter, but those will mess up live searches (because "OR" is nt supported by gc.com API).

Anyone has a good idea?

@eddiemuc eddiemuc added Feedback required Issue requires feedback of the author or another user Support Issue related to one or more Support Tickets labels May 5, 2024
@ztNFny
Copy link
Contributor

ztNFny commented May 5, 2024

I don't understand the request, maybe something is missing in the description?

I also have a cache that I found and now own. I go to live map, set a filter "Found=Yes" and that cache is shown, as expected.
GC.com behaves the same way (as is to be expected)

@eddiemuc eddiemuc changed the title Handling of adpoted caches (owned and found at the same time) in filters Show owned caches when selecting "not found" filter even if the are found (meant for adopted caches) May 6, 2024
@eddiemuc
Copy link
Contributor Author

eddiemuc commented May 6, 2024

I changed title and description, hopefully request is now understandable?

@ztNFny
Copy link
Contributor

ztNFny commented May 6, 2024

So a filter "Found=No" instead "Found=Yes" as described in OP?
Why should such a filter show a cache that's found? Doesn't make any sense to me...

The cache has both properties Found and Owned, so by filtering for either of those attributes it'll be shown/hidden.

If a special behavior "Found=No should also include Owned=Yes" would be implemented it'd actually become impossible to just view normal unfound caches.

My conclusion: the users usecase can already easily be solved by himself using a "Found=No OR Owned=Yes" filter. -> no need to change anything
Changes to the default filter behavior would lead to very unexpected behavior that's likely impossible to understand because it wouldn't match what the labels say.

@ztNFny
Copy link
Contributor

ztNFny commented May 6, 2024

If GC live search doesn't support such live filters - well, there's nothing c:geo can do about that. The OR filter itself works as expected inside c:geo (offline).

@ztNFny
Copy link
Contributor

ztNFny commented May 6, 2024

What works also with live maps:
Found=No OR StoredList=My Hides

In this case the OR is applied locally as opposed to GC.

@Lineflyer
Copy link
Member

In case of stored caches we could prefer "Owned=Yes" over "Found=Yes".
But I would not implement such special case workaround, as it might be unexpected for other users.

There are many possible workaround this user can apply to see, what he wants to see (e.g. remove one condition from his filter, create a list with his hides and use this, etc. etc.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feedback required Issue requires feedback of the author or another user Support Issue related to one or more Support Tickets
Projects
None yet
Development

No branches or pull requests

3 participants