[Navi Search] Possibility to force searching for tracking code

barnoldbert commented 9 months ago

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

capoaira commented 9 months ago

Hello, thanks for reporting the Bug. I think, we run here into an issue which is not good solvable. The search tries to open Caches (starts with GC), Trackables (starts with TB), GeoTours (Starts with GT), Members (starts with PR), Bookmark Lists (starts with BM) and Geocache Logs (starts with GL). Only if that criteria don't match, it looks if it could be a tracking code (6 random characters) and open it. In your case, it opens the bookmark, which is the expected behavior.

@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).

2Abendsegler commented 9 months ago

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 tn bmytk6 and tc bmytk6. If no identification is specified, everything stays as usual. Tracking numbers/tracking codes can also be specified as before, as long as there is no overlap with the other rules. If one of these identifications is specified, then it is a tracking number/tracking code.

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.

capoaira commented 9 months ago

I like the idea. But tn and tc is in my opinion not clear enough, 'cause one of this means the tracking code of the TB and the other means caches, TBs, profiles, BMs (not just TBs). Did we need two identifications or is one, to force tracking code, enough? The RegEx should also be updated to accept whitespace:

search.match(/^\s*(FT\s+)?((?:GC|TB|GT|PR|BM|GL|TL)[A-Z0-9]+)\s*$/i)

2Abendsegler commented 9 months ago

The official name for this code according to TB Listing is “Tracking Number”. In this respect, an abbreviation tn would make sense. It doesn't have to be two.

2Abendsegler commented 9 months ago

... If you have a better idea for an abbreviation, I'm open to others.

barnoldbert commented 9 months ago

my compliments for correctly identifying my problem. I made several typo's in the initial entry. the most ennoying is the error in the expected correct behaviour. as you understood I meant something like https://www.geocaching.com/track/details.aspx?tracker=bmytk6

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." the condition could be: if the code has 6 characters AND starts with one of the standard combinations GC|TB|GT|PR|BM|GL|TL... then ask if the user wants to find a travelbug.

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.

2Abendsegler commented 9 months ago

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.

capoaira commented 9 months ago

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). Let's say 100 of the 1089 possible prefixes will be used, there are 100 * 33⁴ = 118.592.100, which will be assigned. (My 45 coins have 25 different prefixes, which indicates that more than 100 prefixes are in use). That should be enough that we don't have to think about 7-character codes.

the condition could be: if the code has 6 characters AND starts with one of the standard combinations GC|TB|GT|PR|BM|GL|TL... then ask if the user wants to find a travelbug.

That is what I mean.

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.

Yes, I too, but also for GeoTours. But that does not mean that other not use one of the others.

The official name for this code according to TB Listing is “Tracking Number”. In this respect, an abbreviation tn would make sense. It doesn't have to be two.

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 😅

2Abendsegler commented 9 months ago

The thing with the prefix is, that it might not be DAU compatible.

Yes, but this whole field is not DAU compatible. I don't think many users know what you can do with the field.

A tn abbreviation does not always have to be used, only when there is an overlap, as here with bm.

That should be enough that we don't have to think about 7-character codes.

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:

The new dialog should be usable as an alternative to the current feature, new config parameter (false).
For a dialog, the design of Config, Sync, User Search should be used.
The new dialogue should be integrated into their color scheme.
Config and Sync must be selectable when the new dialog is active and must not be disturbed.
The new dialog has to be tested on all geocaching sites, because numerous different styles are now used on the geocaching sites.

Off topic:

My 45 coins

Are they all in your hands? Are they all displayed in the log form?

capoaira commented 9 months ago

Yes, but this whole field is not DAU compatible. I don't think many users know what you can do with the field.

Really? I thought a search field is self explaining.

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.

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.

Off topic:

My 45 coins

Are they all in your hands? Are they all displayed in the log form?

Not directly. I moved all into my collection. So these will not be shown on the log page

2Abendsegler commented 9 months ago

Yes, but this whole field is not DAU compatible. I don't think many users know what you can do with the field.

Really? I thought a search field is self explaining.

😂 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.

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.

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.

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. ;)

2Abendsegler commented 1 week ago

There was a new issue on this topic: [Navi Search] Searching for trackables does not work for trackables starting with "GT"

2Abendsegler / GClh