keepassxc icon indicating copy to clipboard operation
keepassxc copied to clipboard

Ability to search *all* text, simply

Open jwdevel opened this issue 2 years ago • 9 comments

Summary

Currently, typing text to search will look through some subset of fields (not sure what they are exactly; did not see documentation), and if you want to find text in other fields, you need to use a prefix (p:..., attr:..., etc).

That is fine if you know where your text is located, but I often have some very vague notion of "I used text 'xyz' somewhere..." and I simply want to do an exhaustive search against the DB, all fields included. It seems there is no way to do this, currently. You need to do several searches with different prefixes, and piece the results together yourself.

Suggestion

Perhaps the simplest way would be to add a new "all:" prefix?

Some overlap with #4696, #7268, but they are specific to groups and attributes, not "all text, including passwords, etc.", as this one is.

jwdevel avatar Apr 26 '22 20:04 jwdevel

Interesting idea

droidmonkey avatar Apr 26 '22 21:04 droidmonkey

Thanks for reiterating this request @jwdevel. I've also found that when I search for something, I do so because I don't remember where that something is. The user may not recall if they wrote a value in the Notes field, or in an attribute, or even in a username (e.g. if it's an email address).

Limiting the scope to attributes via search syntax is useful, but by default, isn't it more useful to search in all fields than not to?

tredondo avatar Jun 20 '22 17:06 tredondo

Sometimes I even want to know where I used some of my registered PASSWORDS! Please, don't blame the messenger...

dioni21 avatar Jul 28 '22 14:07 dioni21

Maybe if we understood @droidmonkey's reasons for this behavior not being the default, we could advocate better for why we would find it useful as default?

tredondo avatar Jul 28 '22 18:07 tredondo

Sometimes I even want to know where I used some of my registered PASSWORDS! Please, don't blame the messenger... If I understand you correctly: You can do this using search term p:123456 with 123456 being the password substring you are looking for.

back 2 topic: I think it is both annoying and counter-intuitive to not search at least the groups be default. I think there should at least be an opt-in option to do so. Reason: To my knowledge there are basically 2 types of how people handle hierarchical structures. The first type (like myself) puts information to the leafs in rather flat structures and uses a search function to find these later on (I do this for emails and passwords). The second type builds hierarchical structures where an important part of the information is used as the node/folder/group name and navigates this tree to find the desired leaf later on.

Sadly, I work in teams which have both types of people. That means when I use the Keepass file of a person of the other type I cannot simply search, as I cannot search a string in group and leaf simultianously. Not even if I use one of those two: searchstring | g:searchstring u: searchstring | g:searchstring | t:searchstring i do not get the matching leafs from group searchstring that I get using g:searchstring probably | is only allowed within fields but not between fields (if that is the case my previously listed search requests would be syntactically incorrect and should be highlighted in red to tell the user that they are incorrect.

rwiesbach avatar Oct 28 '22 08:10 rwiesbach

Do not add the | it is not a recognized search term. As an example, if your group structure you want to search looks like /bob/azure/ssh:

  1. Search the group tree g:/bob/* t:findme

  2. Search the specific group g:/bob/azure/ssh t:findme

More sample search queries can be found in our documentation https://keepassxc.org/docs/KeePassXC_UserGuide.html#_sample_search_queries

droidmonkey avatar Oct 28 '22 08:10 droidmonkey

  1. Search the group tree g:/bob/* t:findme

  2. Search the specific group g:/bob/azure/ssh t:findme

While this functionally achieves the desired results, I think it's too complicated for the average user. This kind of syntax would usually be considered "advanced search". I think most users would welcome a simplified search by default, where you just enter the main keyword (just findme), and it searches everything for that keyword: all groups, all entries in all groups, etc. If that returns too many results, then you go to the advanced syntax to narrow it down.

On the other end of the scale, how about a g|t:findme syntax to search group name OR title for "findme"?

edit: The simplified search would be equivalent to OP's all: prefix suggestion, or following the g|t: paradigm, maybe a *: prefix (but the suggestion is to not require a prefix at all for the simplified search).

michaelk83 avatar Oct 28 '22 10:10 michaelk83

Sorry @droidmonkey I do not see how this answers my question / Adresses my problem. I do not know whether findme is in the group name, the group tree, the title (and maybe the username, the description ...) Both of your examples

On the topmost leavel of a search term there seems to be AND only. What I need is an OR. Yes, maybe I can do some De Morgan magic to find a legal expression in the defined search language, but similar to @michaelk83 opinion I think this is not handy and also too complex for the average user. The time I need to think about the "trick syntax" could also be used to navigate the tree.

@droidmonkey I dont see the reasons for not making "search all field" in the post that @tredondo refers too, but even If you have good reasons not to make this a default it should at least be possible as an option.

rwiesbach avatar Oct 28 '22 11:10 rwiesbach

At the end of the day, you are finding entries because groups have no value outside of organization and KeeShare. I am not disputing the need for a "search all strings" feature, I just haven't gotten around to coding it yet. You should have absolutely no reason to find a group OR an entry. That makes zero sense when you are ultimately just finding entries. The group search is ONLY to bound results to a matching group structure.

droidmonkey avatar Oct 28 '22 11:10 droidmonkey

It is not about finding groups (at least that is not what I am talking about). it is about finding entries. But if you have a group HOSTNAME and the title is SERVICENAME (SSH, FTP, ...) for example, then you want to find SERVICENAME on HOSTNAME if your search SERVICENAME HOSTNAME just like you would if you had no hierarchy and would name the Title HOSTNAME SERVICENAME

rwiesbach avatar Nov 02 '22 09:11 rwiesbach

It is not about finding groups (at least that is not what I am talking about). it is about finding entries. But if you have a group HOSTNAME and the title is SERVICENAME (SSH, FTP, ...) for example, then you want to find SERVICENAME on HOSTNAME if your search SERVICENAME HOSTNAME just like you would if you had no hierarchy and would name the Title HOSTNAME SERVICENAME

I had exactly this happen to me a lot👍

nod0n avatar Jun 21 '23 14:06 nod0n

Here is something with which the requested feature would help (and which I don't think has been mentioned yet). Sometimes using the hotkey on a website brings up a database entry that one does not expect. Sometimes that happens, I think, because of text within that entry's notes. If there are a lot of notes, correcting the problem - preventing the false positive upon pressing the hotkey - is a problem.

LinuxOnTheDesktop avatar Mar 27 '24 22:03 LinuxOnTheDesktop