Feature Request: Ability to mark URLs are "exact only" _or_ sort by URL similarity

signe
signe
Community Member

This may not make much sense from the title, but here is what I'm getting at —

I have some logins where multiple accounts exist for the same web domain. The usernames for the account names are identical. However the login URLs for these logins are different.

ex: Volgistics, which is a Volunteer Activity recording site.

I have logins to two separate organizations for data recording:
- https://www.volgistics.com/ex2/vicnet.dll?FROM=54535
- https://www.volgistics.com/ex2/vicnet.dll?FROM=19883

As well as a third login because I also administrate one of the organizations
- https://www.volgistics.com/ex/login.dll/?NavTo=Start

And a fourth URLs which is an extension of one of the first two, which leads to a different form used for on-site checkin on my phone.

The problem is that when activating the browser plugin (or the phone app), the list of logins presented by 1P is sometimes in a "most recently used" order, and sometimes it appears in a completely random order... but what it doesn't do is either sort the logins by the accuracy of the match to the URL, or display only the matches for that exact URL.

e.g. If I'm on the "?FROM=19883" URL, I either don't want to see the others at all, or at the very least I always want that one to show at the top of the list because it's an exact URL match while the others are simply similar.


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni

    It's certainly something we can consider, but I'm not sure that use case is typical, and we don't often have requests like this. The problem is that for most users, it would be bad to restrict login credentials to matching the full URL, rather than the domain. That would result in people not being able to log into this very forum, since they could encounter slightly different URLs when logging in. Not a good time. And if we add an option for this, it will also be easy for people to enable that and later forget and run into issues because of that. We try to avoid doing things like that because, frankly, we get asked for another different option every day, and if we add even a small number of them, 1Password would be a mess, and much less usable for most people. So the best thing will probably to give your items useful titles to help you differentiate them.

  • signe
    signe
    Community Member

    Even if all it did was sort by URL similarity, with exact matches coming first, it would be a 500% improvement.

  • AGAlumB
    AGAlumB
    1Password Alumni

    @signe: I can definitely see that. I'm just trying to imagine how that would help and not harm most users. We get relatively few requests even for subdomain-only matching, but many more of those than for full URL matching like you're requesting, which is even more extreme. For nearly anyone but you, it seems like it would be bad to not be able to fill a login because it was saved here or here instead of here. Food for thought.

  • signe
    signe
    Community Member

    I don't understand how you believe that sorting would negatively effect users.

    This is one example of what I'm talking about. I'm logging into my company's AWS so that I can manage systems. As you can see, I'm specifically logging into a subdomain ("us-west-2.signin.aws.amazon.com") not amazon.com or www.amazon.com ... but even though there is a perfect match for the URL, it's listed at the bottom of the suggestions, requiring additional keying in order to select it.

    How does moving that entry to the top of the suggestion list, because it is a perfect (or closer) match for the URL the user is visiting, going to impact them negatively?

  • AGAlumB
    AGAlumB
    1Password Alumni

    @signe: I may have misunderstood. You'll note that my reply isn't about "sorting" at all but "matching". If you want all logins displayed, but have the exact, full URL matches at the top, it's certainly something we can consider for a future version. Apologies for misapprehending your meaning. It's just never come up before. :)

This discussion has been closed.