When testing keypass features I added an additional entry on a key entry under the advanced tab. When exporting to csv to test this functionality the additional entry was nowhere to be found.
I would expect additional entries to be present on the csv file.
Additional entries for saved keys are not exported.
Note: I am not sure what is the intended function here from a developers standpoint.
If additional entries are intended to be exported then they 'd need to be implemented on a later release.
If it is not intended for those entries to be exported it would be good if it is documented somewhere. From a new user's perspective it would be even better if a dialogue box opened (after clicking export to csv) saying which parts of the database are not exported (with an option to never show again).
I am including two screen-shots of adding a new key and the resulting csv text below


When exporting the data to a scv I get the following result:
"Group","Title","Username","Password","URL","Notes"
"Root","key1","key1","key1","",""
Note: I have clicked ok to save the new additional entries before attempting to export.
I am testing keepassxc features to make sure any information I add to the database can be exported to a printable format (for non-digital backup purposes).
```{bash}
$ snap info keepassxc
name: keepassxc
summary: "community driven port of the windows application “Keepass Password Safe”"
publisher: keepassxreboot
contact: https://github.com/keepassxreboot/keepassxc
description: |
KeePassXC is an application for people with extremly high demands on secure
personal data management. It has a light interface, is cross platform and
published under the terms of the GNU General Public License.
commands:
Enabled extensions:
We call those additional attributes. Either way, exporting N number of attributes into CSV is problematic. You wouldn't want to add another row since each row represents an entry. You also cannot just add another column since CSV is pretty strict on columns. Lets say 1 entry has 100 attributes, then every exported row will have 90 commas with only one row having that data filled in.
To shorten this up, the intention of CSV export is not to replicate the database in a CSV file, its to export the primary fields for transport to another service. Your request would be better served in an XML export (for example).
Because TOTP codes are stored under additional attributes, the lack of their export in CSV (and the lack of a more structured export, such as XML), causes a bit of a lock-in problem. I cannot move to another service easily as I will have to go through _each_ entry and double check their attributes. This is an issue.
I've personally had to implement CSVs with n additional fields per record, even additional nested rows, and it's a horrible mess that many CSV readers will parse incorrectly.
CSV is a great format for exporting simple data structures, in an efficient way, but the need for something more versatile (like XML for example) is apparent. Currently the only _real_ way to get a complete export of a database is to open it in keepass and export to XML from there, something which is less than ideal, but does work very well as a temporary solution, as KeePassXC doesn't have an XML export. For now?
It would be useful to export plugin specific attributes (totp, http, etc) and would limit the scope (ie, columns). @andschwa if you think this would be a good feature please open a new issue. Creating an XML export feature would be rather trivial to do as well since the db is an encrypted xml export.
Note: cli interface can already export XML.
I think it's not complete, though. For KDBX4 it needs to inline attachments, which it isn't doing AFAIK.
Thanks @RealOrangeOne for the suggestion to use KeePass (the original) for exporting. Funnily, doing so showed another problem with exporting additional attributes. While KeePass exported to XML just fine, the other software failed to import it because some of my fields were too huge (1000+ character limit apparently on import).
This is a sorely missed feature. I agree that having a CSV with an arbitrarily large number of columns is problematic. However, I don't think you need to add as many columns as there are attributes. Instead, how about just having one column perhaps called "additional_attributes" and store a serialized form of the attributes as maybe JSON? Then when importing you can simply read the entire column and deserialize it.
That's not a bad idea
Most helpful comment
Because TOTP codes are stored under additional attributes, the lack of their export in CSV (and the lack of a more structured export, such as XML), causes a bit of a lock-in problem. I cannot move to another service easily as I will have to go through _each_ entry and double check their attributes. This is an issue.