Add a new field calld "Has Passkey"

[rwernerar]

In the same way that a field exists for "Has TOTP," I would suggest adding another one called "Has Passkey."

I have some login credentials with passkeys and others without. It would be useful to see which ones have them and which don't on the main screen, just like the field for "Has TOTP."

When you add a passkey to an existing entry, a tag called "Passkey" is added to that entry. However, you only see the tag when hovering over a given field, not in the main area.

[droidmonkey]

Use the tag that we apply to entries that have passkeys added to them, I am really against adding more columns to the main view for things that are not interactive or genuinely informative.

You can invert the search and scope it to a group rather easily:

[JohnLGalt]

I think I kinda agree with adding a column here. While not interactive, it is definitely a great way to provide information at a glance - and no different, really, than the Has attachment column, and it would serve virtually the same purpose as the Has TOTP column, as well - make it an easy way to see if an attachment exists / TOTP has been set up for the entry or not.

As an example, IMO, having the Notes show as a column actually, in this case, makes much less sense, as the Notes field is designed as free flowing text, and a column is a poor way to show them if you have long, extended / multiple line notes.

Plus, the main reason for having a column showing the existence of a Passkey is not only for the simplicity of knowing when one has been made for an entry, but also for the prevention of (attempting to) creating another one - I have 400+ entries in my database, and I sure AF don't want to have to run a search on each group and refresh said search as I slowly go through and create passkeys for the different entries.

I'd even like it to go one step further and allow the user to manually set the item in a Passkey column marking it as being unavailable to create / generate a passkey, too. That way I don't waste a lot of time trying to create a passkey for a site that simply will not let me do so in KPXC. But this I suspect is well beyond a simple column feature. So, I'll just put my vote in for having a simple passkey column that functions similarly to the TOTP column.

[droidmonkey]

I agree with many of your points, especially the notes column (that is a carry over from KeePass2/KeePassX). I would submit that for sites that "don't accept" or "won't accept" a passkey, just use a custom tag for that.

[JohnLGalt]

I can probably start doing that, for sites that won't work / can't use KPXC.

[sorcix]

I don't like using tags for things that could be detected automatically. I've been moving passkeys around (as they were created as new entries in previous versions) and forgot to remove those tags manually. So now the tag isn't correct anymore in my database. I can (and will) clean that up manually, but my point is that tags are not always in sync with the actual contents.

Is adding a search filter for "has passkeys" an option, instead of searching for tags?

[droidmonkey]

Yes, and I agree with you on auto discovery. We could do that in a future state, but then it becomes application specific. At least with a tag you would be able to see that in other kdbx capable applications that are not keepassxc.