Add custom column for specific entry attribute

[Poikilos]

I cannot see the description in the list view, so I suggest adding that in case people have reasons for custom sorting.

Expected Behavior

• [ ] I would like to have additional columns for other fields or at least have
• [x] optional (or hardcoded) Description column.

Current Behavior

User-defined info in Description field is not visible in the listview. (resolved) Arbitrary fields (or at least a complete list of them) are not able to be added to the listview.

Mitigations

• [x] Possibly add feature to enable or disable columns for particular fields, such as in case someone wanted to have the password there too like in the original KeePass, but this is not essential to providing the feature.

Context

I would like to see the description in the list view so that I can put stuff in there for sorting (dates for bills is currently the case for me). I can do this with KeePass from keepass.info, but that requires mono if used on linux which is...problematic to say the least. Beyond that, I tried poking around in the code for KeePassX so I could submit a pull request, and even though I am somewhat familiar with Qt I could not find any clear way to make changes to the implementation of columns. I just found your project which says it is community driven, so I thought I'd see what you thought about this feature or could provide some guidance on where to change the code if I were to submit a pull request for hard coding a new column.

Debug Info

KeePassXC - Version 2.2.4 Revision: 4723f66

Libraries:

• Qt 5.10.0
• libgcrypt 1.8.2

Operating system: Arch Linux CPU architecture: x86_64 Kernel: linux 4.14.15-1-ARCH

Enabled extensions:

• KeePassHTTP
• Auto-Type
• YubiKey

[droidmonkey]

Already added to 2.3

[droidmonkey]

Actually, do you mean adding a column that shows a specific attribute by name?

[Poikilos]

I didn't think of any reasons for needing other columns, but yes, I did mean that (having a named field as a column) as a possible solution and someone might have reasons for viewing other fields as columns. I just got the git version via an AUR package and see you've added more columns. Good stuff. The high risk of corruption warning in the dev version sounds scary but I can at least use it read-only for sorting as a suppliment to KeePassX until you are confident enough to release a version with the new columns. Thanks.

[ThatGuyFromHighRolls]

I would also like to be able to show or not show various field columns to the view. i.e. I like to be able to see the Notes field when viewing a record.

[xPaw]

This is possible in the original KeePass 2, so it'd be nice to be able to do this in XC as well. I basically have an email attribute and would like to see it as a column.

[eoryb]

Yes, this would be a very nice feature. I've also used function in the original KeePass2.

[islamadel]

Please add this Feature for Showing Additional Attributes items in List View. Like E-Mail, First Name, Last Name, etc.

[nniesen]

I used this feature a lot in Keepass 2 especially for showing Email which usually isn't the same as username. I also have other information that I'd rather have in attributes instead of just in the Notes field.

[stfnlutter]

Agree, just had a first look to KeepassXC and it looks really nice, but not having custom columns kills it for me. For now I need to revert to the normal Keepass. I use it to show email address as mentioned above as well as other info. Would be great if this feature is added.

[nniesen]

@stfnlutter The fields are visible in the "view" pane under the Advanced tab so you don't have to Edit the entry to see them. You can also filter on them via Search with attr:<field> or attr:<value>. Neither of those is as convenient as a column at a glance and being able to sort on it.

[droidmonkey]

Columns are not convenient either as there can be an unlimited number of permutations and no control over mistypes and case adherence.

[stfnlutter]

@droidmonkey I am not sure why you are talking about permutations - I add some custom fields (e.g. "Registered Email"), and I select those custom fields as columns. I do the same for three different custom metadata I attach to my entries. In Keypass, when you enter a String Entry, it proposes in a dropdown custom fields you have already used on other entries, so there is no issue with typos. Maybe you mean that the attributes are outside of the normal structured data you have - yes, it is a property bag.

This is admittedly an advanced usage, but super handy. I agree with @nniesen that search on them is good but not sufficient, and Advanced tab too hidden away for my purpose. In the end it boils down to what KeepassXC wants to be - a C port of Keepass (which is quite powerful), or a simplified version for beginner users. I'd be of course happy if it would have equivalent functionality to Keepass :)

[at-cf]

Piling on... Especially with so many services requiring phone numbers, tokens etc. now for 2FA, it's pretty important to get a column view of account metadata. E.g. to answer question across couple hundred accounts, how screwed am I if I change cell numbers (common if moving countries).

[jayfan0]

I'd also like this feature too. Im moving over from dashlane and the entires stored there are email, login, secondary login, password, website, name, category and notes

the only things missing in comparison are email, secondary login and categry, but what i miss the most is email. I have so many accounts registered with different emails there is no way to keep track on keepassXC, so i still havent fully migrated. Their autofill also included either email or secondary login (email) in the autofill for thoe sites that used either

[droidmonkey]

You could just put the email in the notes section.

[jayfan0]

is there a way to then use that as a username login/ autofill with the browser extension? Sorry im still relatively new to it

[droidmonkey]

You have an email AND a username for login? You'll need to use the KPH attribute prefix in this case or use Auto-Type

[lcdennison]

There are so many use cases for this functionality that it almost borders on common sense to me as a fellow software developer. Here are a few cases I can think of off the top of my head from my workflow alone, primarily related to infrastructure management:

1. "Access Key" attribute to store AWS IAM access keys (which are different than usernames) and being able to quickly scan the list of keys to find the one I want
2. Expiration Date for certificates
3. Database names for credentials that have a username, password, and associated database name (database in the general sense of an online database)
4. Security Key Name to track the particular security key associated with a 2FA login just from list view

I don't claim these are the best use cases, just ones I can quickly think of. There are probably dozens if not hundreds more reasonable use cases among the community. It's the basic ability of adding more columns/output to our "query"/view of Keepass database results. Of course, the "Notes" field can "solve" most if not all of these use cases because it's a generic "catch all" field. It's just clunky and inefficient with most of them, especially when a particular entry has more than one additional "custom" data point (Notes doesn't show multi-line in list field).

I can understand if this particular feature is difficult to implement and that's the reasoning it won't be done; this is an open source project after all. But it's definitely one of the more important usability issues with KeepassXC, in my opinion. Not enough to make me switch applications, of course.

I personally don't care about auto-type or browser integration for custom attributes. My feedback here is specifically related to the additional columns in list view.

[droidmonkey]

It's not difficult just completely non-scalable. Each specific attribute name requires its own column. Unless you are careful and consistent then you'll end up with many cusyom columns. This will be greatly improved with custom entry layouts that will enforce consistency in attribute names.

Regarding your examples, these would be my solutions:

1. Notes
2. Use the existing expiration field
3. Add the database name to the entry title
4. Notes

There is a bit of "illusion of choice" with this feature request. It does not necessarily make things better or solve root problems. For the record I plan to implement this feature request, just exploring the limits.

[decadent]

Personally I imagined these columns to be selectable for each folder—hopefully the file format allows storing extra properties on folders. This way I wouldn't see a separate ‘email’ column in the folder of email passwords.

(However, if KeePass itself has this feature in some form, I guess the implementation should be compatible. Dunno yet what ‘custom entry layouts’ look like, and they may override these musings.)

[lcdennison]

@droidmonkey Indeed, your feedback made me think of a side mention here, which is that Keepass helps on that exact-string enforcement by auto-suggesting custom attribute names (as a type-ahead type implementation) from existing attributes in the database whereas KeepassXC does not. At the end of the day, it's still up to the user to make sure they aren't making typos and such, but the auto-suggestion helps on that front. I'd personally be willing to accept the responsibility of making sure each attribute name is exactly as it should be, but it is indeed not an ideal solution.

What's the "custom entry layout" stuff you mentioned? Is that #863 ? If so, that seems very applicable to this and a lot of other things. I could still see this custom attribute stuff still being helpful on the list view in particular edge cases, but way less of a priority/need if we could define custom entry layouts and then be able to select those "pre-defined" fields for showing on the list view, same as the "built-in" fields. If the solution could be intelligent to only show the options that are actually applicable for list view (based on the actual entry types in the particular list), that's even better.

[droidmonkey]

Yes that's the feature request, it's high on my list now that I finished other refactors.

[fnordiff]

In my opinion, the notes field is not a good solution for this task. It already stores various other things that differ from account to account. And there can only be one thing at the beginning of the notes.

One advantage of "additional attributes" is that you can save key = value. Email addresses are a typical example of this.

"Permutations, control over mistypes and case adherence" shouldn't be a problem. KeePass2 solves this by suggesting existing keys when creating an additional attribute. That works very well, corresponds to an autocomplete.

Displaying the E-mail field in a column gives me an everyday overview of where I am using which e-mail address. This is different from a search and different from viewing a single entry.

[trycoast]

I think this is a no-brainer. I'd pay to have this feature created.

[fnordiff]

5502 describes some solutions regarding the above mentioned challenges with permutations, control over typos and case adherence of additional attribute names.

[berniyh]

It's not difficult just completely non-scalable. Each specific attribute name requires its own column. Unless you are careful and consistent then you'll end up with many cusyom columns. This will be greatly improved with custom entry layouts that will enforce consistency in attribute names.

Well, you are right, but look at it this way: If I can enable the attribute "E-Mail" to show as a column, I have an easy way to check whether I used a different spelling in other entries (e.g. Email), since those don't show up. And then I can correct them to match. And of course there can be an large number of attributes, but in that case it is up to the user to decide what is important for the list view and what is not. Just like it is the case with all the other columns as well, e.g. size, dates or notes.

[ygoe]

It's not difficult just completely non-scalable. Each specific attribute name requires its own column. Unless you are careful and consistent then you'll end up with many cusyom columns. This will be greatly improved with custom entry layouts that will enforce consistency in attribute names.

Well, you are right, but look at it this way: If I can enable the attribute "E-Mail" to show as a column, I have an easy way to check whether I used a different spelling in other entries (e.g. Email), since those don't show up. And then I can correct them to match. And of course there can be an large number of attributes, but in that case it is up to the user to decide what is important for the list view and what is not. Just like it is the case with all the other columns as well, e.g. size, dates or notes.

My experience of the last couple years is very simple: I need one extra column for the e-mail address and nothing else. And I never had any issue typing "E-Mail" correctly for each entry, so inconsistencies are not an issue to consider here (as mentioned previously). Keep it simple, please, at least in the beginning. We don't have to discuss similarity checks here as long as we don't even have a simple column view yet!

If somebody would need to add a dozen of columns to their list, then yes, it might not scale. But for all others who just need one or two columns, it would be just fine! The e-mail column even seems to be so often mentioned here that I'm wondering why it isn't a default entry field yet. I'd have wished for that for years.

All I see here is concerns and objections. And you can't all be German, can you?

[gcstang]

Maybe I missed it in this chain but the custom field should be fillable on the page i.e. another populate app Bit* has this concept and it allows you to set the name and value for sites that require not only a user/pass but some other field like a workspace value to login. The name should be used to set my value on the page with that column.

[ygoe]

A strange example for this is the BBC, e.g. their web radio app BBC Sounds. You have a user name, e-mail address and a password with their accounts. You need the password to authenticate, but identification differs. If you're under 13, you must use only the user name, if you're older, you must only use the e-mail address. Trying the other method fails silently. I observed this when trying to log in with my user name (KeePass default behaviour) as explicitly suggested by the login form labels. Their support explained this to me (on 2022-12-07) but failed to provide a reason for this unexpected behaviour that surely leads to tons of login problems.

I've properly created that database entry with the user name. Since KeePass doesn't care about e-mail addresses as a primary field (a major oversight IMO), it's tucked away in an additional field. A note for the entry reminds me what to do if login fails. I'll have to copy and paste everything manually then because no KeePass app can help me with their weird login scheme.

Suggestions:

1. Promote the e-mail address as a standard field besides the user name, always.
2. Provide a selection whether for this account the user name or e-mail address should be used by default. The default type sequence and browser add-ons must regard this choice.
3. Allow auto-typing of user name and e-mail address individually.

[ohuf]

I would very much enjoy if I could define additional global custom attributes. e.g. additional attributes that, once defined, are available to each entry. (just like the "KeePass custom attributes" Once an attribute is defined as "global" it would probably be a breeze to add it to the global ListView.

[gisturbance]

How's the [thought] progress on this? Custom columns would immensively increase usability, especially together with https://github.com/keepassxreboot/keepassxc/issues/7971.