Closed CodeAlDente closed 5 years ago
Sure, seems reasonable.
Probably stroke through and de-prioritize in search? I don't know if outright removal is the best thing to do.
That would be a good option.
But I have just discovered that logins that have expired (set in KeePass) get already stroke through. Why not hiding those deleted entries with the option to show them and - to remember this choice - so that they will be shown in the future as well?
Yet they need to look different from the entries that have been expired. Maybe those deleted entries should get stroke through (when shown) and those expired should be in red color?
AFAIK Trash is kind of like any other folder in KeePass database or is it more standardized? If it isn't we would have to match it by name which is kind of flaky IMO.
AFAIK Trash is kind of like any other folder in KeePass database or is it more standardized? If it isn't we would have to match it by name which is kind of flaky IMO.
I'd say something like "Exclude folder from search results: [Trash can folder]" where brackets are an input box where the user can type any folder name should do the trick.
It should be a relatively simple setting to add, and will solve the problem, that by the way I just stumble upon today myself.
I would take a slightly different approach. There's really no such thing as a "deleted" entry, the action simply moves the entry to a group named Recycle Bin that has both Behaviors (Auto-Type and Searching) set to Disabled. I create subgroups called "closed" or "archived" for accounts that I don't use, but want to keep record of. I mimic the Recycle Bin by setting set the Behaviors to Disabled. To be functionally consistent and make Tusk function like the KeePass application, I think ignoring entries in groups that have the Searching Behavior set to Disabled is the way to go.
Super agree with that. Great idea, @swartzja
It looks like this has already been attempted:
https://github.com/subdavis/Tusk/blob/develop/services/keepassService.js#L168 // Entry properties defined by the parent group entry.searchable = true; if (group.enableSearching == 'false') //verify entry.searchable = false;
But it looks like group.enableSearching isn't being properly set (at least in my primary kdbx.)
I played with this a little tonight, and the way this is handled in the storage is interesting.
$ go run test.go test.kdbx | egrep '\<(Name|EnableSearch)'
<Name>Root</Name>
<EnableSearching>null</EnableSearching>
<Name>Implicitly Enabled</Name>
<EnableSearching>null</EnableSearching>
<Name>Recycle Bin</Name>
<EnableSearching>false</EnableSearching>
<Name>Explicitly Enabled</Name>
<EnableSearching>true</EnableSearching>
Null means inherit, and it's implicitly true at the Root.
kdbxweb is properly reading the database, but Tusk wasn't dealing with the boolean value properly. I just sent pull request #292 to fix this.
(FWIW, while debugging that, I also discovered the Go library I was using to parse the kdbx files wasn't dealing with bools correctly either.)
At the moment Tusk is even showing entries that have been deleted (moved to trash in KeePass). I do not consider this as a bug as it could be useful to some people to check their login details from the past for different reason. But I do believe that most of us are interested in active logins, those entries that have not been deleted. So, it would be awesome to have an option to show all entries or to hide entries that have been deleted.