I would like a browser-extension level setting to “materialize” URI match detection on new entries created via extension.
What I mean is this: when I create an entry via browser extension, it is automatically (by default) created with “default” URI match detection.
In my extension, I set URI match detection to “Host” (not default).
When I create an entry, it gets autofilled by my current browser default URI detection rule.
However, when I switch to a different browser or add my entry to a shared collection, it is also shared with “default” match detection mode. Then other clients having this entry get a different experience compared to what I have because their “default” is different to my “default” set in the extension.
What I want is a setting on the extension that would, upon creating a new password entry, fill the URI match detection mode not with the value “default”, but rather with MY extension’s current default value (which is “Host” for me).
This way, when I switch to a new device, I would get the same experience I had with the previous device right out of the box, and my colleagues I share a password entry with would get the same experience as well.
@Anton_Bohdanov Welcome to the forum!
I think that a cleaner implementation of what you’re requesting is to make the Default URI Match Detection setting syncable. So that when you configure it to be “Host” on one device, it will also be “Host” on any new device that you set up. Therefore, all login items that have “default” URI matching will match the same way no matter what device you are using.
Frankly, I’m surprised that this functionality does not exist, and I’m wondering if is a bug.
@Anton_Bohdanov I changed the title from “URI detection materialization” to “Option to make the current URI default match detection choice (like “Host” etc.) the default for new login items (instead of “Default”)”. I hope that’s okay?!
Hello there!
Well, the solution you propose solves the issue of me transferring to a new device, but unfortunately it does not solve the issue of sharing an entry with an organization.
Thus, I would still stick to my original proposal, or the way @Nail1684 rephrased it - works for me too.
@Anton_Bohdanov’s approach, to make it a creation-time default, instead of a run-time default behaves well in a multi-user environment. @grb’s approach effectively requires all users to have the same default.
Personally, I feel it would be best for each vault item to have an explicit match detection and when viewing/editing an item, the selection menu always be visible. As it is today, this setting is too hidden.