Attributes not searched by default?

[TRSx80]

First off I must thank you for all your work (and for sharing it, like civilized people!). I use keepassxc daily, it is probably one of my most used programs on GNU/Linux; I don't know what I would do without it. I really do feel obligated to throw you guys few dollars, and I will be doing so (probably recurring) once I am back to work. You certainly deserve it. For right now though, the very least I can do is let you know that the care you have taken, features implemented, etc. are greatly appreciated! 🍻

Overview

I would expect search to include searching attributes by default, however apparently it does not.

Today I could not find some data that was listed in an attribute, until I searched attribute field specifically (with attr:xxx). Which is an OK workaround (for now) but I don't think this should be the default search behavior.

If I had not spent some time digging into this today (only today in fact I learned about the expanded search options (like attr:, which are very nice btw! 🍻 )), I very likely would have missed the information I was looking for in my database completely (and perhaps then duplicated it somewhere else).

Therefore what I propose (and what this issue is about) is a change in the default behavior.

Steps to Reproduce

1. Put cursor / focus in search field / bar (or press Ctrl-F).
2. Type part of the attribute value I am looking for.
3. Results get filtered down to an empty list (no result).

Note that my search options "Case sensitive" and "Limit search to selected group" are both un-checked. I also made sure I was in the root folder (even though that shouldn't matter, especially with these settings).

Expected Behavior

Find the information I am looking for.

Actual Behavior

No matching result comes up.

Unless I do attr:xxx in which case I get what I am looking for. But I do not feel this should be the default behaviour.

Context

I did a search for what I thought were relevant terms but did not find anything (apologies if I missed it).

I also read through some related issues as well as the related PR (among others) but I don't think these directly address this particular aspect.

KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Qt 5.12.5
Debugging mode is disabled.

Operating system: Debian GNU/Linux bullseye/sid
CPU architecture: x86_64
Kernel: linux 5.4.0-4-amd64

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (only unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.5

Operating System: GNU/Linux
Desktop Env: XFCE / i3-gaps wm
Windowing System: X11

[droidmonkey]

Very unlikely this will be a default behavior.

[wolframroesler]

Thanks for the thumbs-up @TRSx80, really made my day.

Maybe an option to search in attributes can be added to the menu that appears when you click the question mark in the search field? The attr: syntax isn't really discoverable.

Maybe same solution like recommended for default group search #4705 (comment) ?

Or a single combined option for both?

[TRSx80]

Sorry for disappearing! Got busy; you know how it goes. :)

Anyway, to me the additional custom attributes are just as critical top level fields as username and password.

I honestly did not think this would be a controversial assertion.

One particular case (in fact the exact case that motivated me to lodge this issue) would be a group of SyncThing installations, where for each user on each machine you can have a username and password to log in to the web UI. So you need to leave those fields as is, for auto log in purposes[1]. However there is also a GUID which uniquely identifies that particular instance (combination of user and machine). I have a number of machines (and users) that I manage, and trying to sort all of that out without being able to search for the GUIDs is just more painful than it needs to be.

I'm sure you could quite easily come up with more examples.

I am struggling to comprehend what the downside would be in including those attributes into the default search (without requiring to put in attr:, which I did not even know about until I started looking in to this).

I cannot find it now, but there was another thread I read about search where it was discussed that the modern assumption of a general search box is that it would be searching everything by default, which I also agree with. And many people in that thread said the same, including devs, and so I don't understand how this would be any different?

Maybe someone can help me to understand?

[1] Yes I realize you could put either the name or password into an attribute field, and re-work your auto log-in to work anyway, so you could have the attribute you are looking for in a searchable field. But this to me is not only a workaround but also breaks the semantics of all of the fields involved.

[TRSx80]

The attr: syntax isn't really discoverable.

Yes, this is part of what I am talking about. Never even knew about that wonderful functionality you worked so hard on @droidmonkey until I came digging into this issue! It's just hidden away!

[droidmonkey]

Fixed that problem

[TRSx80]

Ooh! Very nice! 😃

I still think it should be included in default search... 😁

[nniesen]

I've never had to use t:, u:, p:, etc.. so it's counter intuitive that I would have to type something other than the text I'm searching for. I think the field prefix is an excellent way to limit/scope the search but everything should be searched by default. A setting somewhere with default fields to search would also be fine.

[TRSx80]

Thanks for the bump, nniesen, I had forgot about this.

I just spent a good 20 minutes (at least) searching for some article I read recently, unfortunately without success. I think it was called "Tags are Dead" or something like that.

Anyway, one (of several good) points the author made was that various complicated classification schemes are a relic of a time when computing cycles were much more expensive than they are today. And conversely, they are so cheap nowadays that ubiquitous and fast full text search has become the norm, rather than the exception.

I agree with nniesen, if you are looking to narrow down to something more specific then you have several more tools available to you. Which is great. But I don't think that anything should really be excluded from the default search.

In fact, I would argue that the expectation of almost everyone nowadays if for the default to search everything. I would even go so far as to say that the onus is actually on those who would exclude such functionality to justify why it should be excluded, rather than on us to justify why it should be the default.

Finally, there was another long thread already in this project (can't find it at the moment either) where search was discussed, and the conclusion was essentially the same one I came to here. Therefore it is even inconsistent within the project itself not to "include everything as the default" so to speak.

[nniesen]

Another issue I've run into lately, with the current implementation, is trying to find and replace domain names. The domain names are in url, browser integration (attr), user name (u), and less frequently notes or title. It's not clear/documented which fields are included by default (I think everything but attr) and it doesn't work to do it in one search like "domain attr:domain" or "domain|attr:domain".