-
-
Notifications
You must be signed in to change notification settings - Fork 38
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
[Navi Search] Possibility to force searching for tracking code #2507
Comments
Hello, thanks for reporting the Bug. @2Abendsegler Do you have an idea how to prevent that? We could ask (if the code has 6 characters), if the user wants to open it as Cache, TB, Bookmark, etc. or as tracking code. But that would need an extra dialog... BTW, it looks like we don't support trackable logs (starts with TL). |
We could still build TL. Instead of a dialogue, we could work with an identification in the case of a tracking number/tracking code. So for our example Maybe we should finally provide a description of the possible inputs, perhaps similar to the auxiliary fields in the config, i.e. with a question mark, or perhaps even better, show title (multi-line) by hovering over the field. |
I like the idea. But search.match(/^\s*(FT\s+)?((?:GC|TB|GT|PR|BM|GL|TL)[A-Z0-9]+)\s*$/i) |
The official name for this code according to TB Listing is “Tracking Number”. In this respect, an abbreviation |
... If you have a better idea for an abbreviation, I'm open to others. |
my compliments for correctly identifying my problem. I made several typo's in the initial entry. I prefer as a solution the suggestion by capoaira: "We could ask (if the code has 6 characters), if the user wants to open it as Cache, TB, Bookmark, etc. or as tracking code." BTW I only use the search field to find a cache or a TB. In general I never have the code of one of the other types of items at hand. |
Hmm ... your preferred solution may seem to be the best solution for you, but it may not be for others. This solution would change the current approach. A person who previously got to the desired location without a dialog, even with 6 digit caches, TBs, GeoTours and bookmark lists, now has to go through the dialog unnecessarily from their point of view. I don't know how to explain this to this person? And what happens if the 6 digits for the tracking number are no longer enough, which I actually can't judge, but which makes sense because probably not all possible codes will be assigned. But then we would have to go through the dialog even with 7 digits codes. Or we would have to change the new approach again. As a rule, we proceed in such a way that procedures that have been implemented are not changed because we are stepping on someone's toes. Instead, we maintain the implemented approach and supplement it sensibly with new circumstances. For these reasons, I don't think your preferred solution is the right solution at the moment. |
I understand both, and I'm not sure which one I prefer. The thing with the prefix is, that it might not be DAU compatible. A dialog is clear to all, but of course it is an extra step for all how enter a 6-characters code. And I think that the most users use GC or TB numbers for Caches and Trackables. Bookmarks, Profiles and Logs might more shared as link than just the code. The tracking codes have a prefix of two characters, which is related to the type (For example CV for Community Volunteer tags, or GS for Lackey tags) followed by 4 random characters. So we have 33⁴ = 1.185.921 possibilities for each prefix. But there are multiple types that can use one prefix in common. So it might not be assigned all possible codes (33⁶ = 1.291.467.969).
That is what I mean.
Yes, I too, but also for GeoTours. But that does not mean that other not use one of the others.
Oh. I'm stupid. I thought, that you mean one for Tracking number and one for GC, TB, ... codes 🤦🏻♂️. Forgot what I said, we can of course support more abbreviation for that 😅 |
Yes, but this whole field is not DAU compatible. I don't think many users know what you can do with the field. A
Unless gaps are intentionally left to prevent to discover TBs with arbitrary codes. I think the effort to develop the dialogue is not justified, when there is such a tiny and simple intervention, that can achieve the same thing. The effort you have to put into this would be much more beneficial elsewhere. Requirements for a new dialogue. What comes to mind shortly:
Off topic:
Are they all in your hands? Are they all displayed in the log form? |
Really? I thought a search field is self explaining.
Yes, that is right. Maybe we can use the find player as template, so that we can ensure, that the dialog works on all pages.
Not directly. I moved all into my collection. So these will not be shown on the log page |
😂 Yes, that's right. But it doesn't even say that it is a search field. And that's not documented anywhere, I don't think. And I didn't know that you could also search for logs from caches, but not logs from TBs.
You will probably need additional elements, such as radio buttons, which are not used on the find player template. But yes, this could be a start. For example, with #2421 or #1473, many users would be much happier. ;) |
There was a new issue on this topic: |
Describe the bug
the search field in page header does nor resolve some trackable codes correctly.
To Reproduce
go to anay page where GClh is working
enter in the searchfield in the top BMYTK6
it the tries to open https://www.geocaching.com/plan/lists/BMytk6 that does not exist
Expected behavior
instead it should try to open
https://www.geocaching.com/plan/lists/BMytk6
OS
Windows
Browser
Firefox, Chrome
GClh Version
0.15.1
Additional context
I tried several other tracking codes, they are treated correctly
The text was updated successfully, but these errors were encountered: