Add support for default entry layouts

[droidmonkey]

Summary

Following the conversation in #863, this feature focuses on adding a set of default entry templates that are shared amongst the various KeePass compatible applications. Original conversation start: https://github.com/keepassxreboot/keepassxc/issues/863#issuecomment-1161421170

The 'system' for this approach is documentation over code since it will be implemented by multiple parties. Need to clearly document:

• The default templates and their ids
• What data types and key names each template requires
• some form of input validation (try not to be too strict)

Then we can move to allow a 'custom' template spec like I wrote above, if necessary.

Some good default templates that would get us 99% there:

• Secure note (title and notes only)
• Credit Card (title, CC numbers, expiration)
• Entry with email (add an email field to the entry)
• identification (Title, name, person data fields, address, etc)

Example: https://github.com/Kunzisoft/KeePassDX/wiki/Templates

The final table defining this feature is found below: https://github.com/keepassxreboot/keepassxc/issues/8228#issuecomment-1211902266

[strongbox-mark]

Sounds great! I've put together this as a starter/draft, not sure if Github Markdown is the best way to manage this but here goes :)

Layout Name	Custom Data "LayoutType" ID	Field Name(s)	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber Expiry CVV	Credit Card No. e.g. 4555 5555 5555 5555 Month & Year (mm/yy or mm/yyyy) The CVV security code	[0-9]+ [0-9]{2}/[0-9]{2,4} [0-9]+	Should allow spaces
Entry with Email	EntryWithEmail	Email	Display an Email field with this entry.	.*
Identity	Identity	Name Phone AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 12a My Building Abbey Road NW8 9AY London United Kingdom	. . . . . . . .

What do you think?

[Hundhausen]

I would add an Secure Question with Question and Answer as Password field, so that I can copy it out easily.

Email should also include Password and Notes for Server Information. Maybe these even separate.

I think some not so important ones but maybe nice to have would be Wifi, Membercards with expiration date and 2FA Backups, but these would probably just be a duplicate with a secure note.

[droidmonkey]

For each default template we need to map certain attributes to our "core attributes" so that the copy/paste, browser, and auto-type integrations work with the template. So for example, Credit Card template would map "Credit Card Number" to the username field and CVV to the password field when interacting with that entry. This is mainly a KeePassXC problem since mobile apps don't have browser integration or auto-type.

This would be implemented in the backend (ie, within Entry.cpp) when a core attribute is requested it would check the template setting first then attempt to map the template to the requested attribute and return the value.

We also need to be cognizant of references and how those will play out. The KeePass standard to way too loose and you have to take into consideration so many contingencies.....

Also, Credit Card should include a field for type of card (eg, Debit, AMEX, MasterCard, Visa, etc). Same with Identity (e.g., License, Passport, Contact, etc) and identity should include an email field and multiple phone fields (mobile, office, home). I would implement that as showing one field initially with a drop arrow that would show "more". This is how most contact apps do it on Android and iOS.

[strongbox-mark]

For each default template we need to map certain attributes to our "core attributes" so that the copy/paste...

Yes, we'd also have to do something similar on the Strongbox side, but as you say, this is implementation specific.

Also, Credit Card should include a field for type of card (eg, Debit, AMEX, MasterCard, Visa, etc).

Yes, I suppose you're right. Do we need an exhaustive list or would the 3 main ones work (AMEX, Visa, Mastercard)?

Same with Identity (e.g., License, Passport, Contact, etc)

Do we have an exhaustive list for this, or is it free form? How would you expect it to work? e.g. do you display a License differently from a Passport, or a Contact? Or is it possible to live without this?

identity should include an email field and multiple phone fields (mobile, office, home)

The way Strongbox works is it allows you to add any fields and will display them on the same view as the normal (Username/Password/URL) fields, so for us this is fairly straightforward, you can add any fields you like, email/phone numbers etc.

Do you think that we need to define particular field names for phone number? e.g. PhoneNumber1...PhoneNumberN

For Email Strongbox almost treats this as a native field (like Username/Password). It always uses the field name "Email", and this can be part of any entry. I know in KeePassXC you don't treat an "Email" field as special, and you have extra fields on a separate tab which I suppose will make your implementation different.

In short, the way I see this feature is to define an entry as a particular type and say that there are the following well known fields (but there could be many more not "well known" fields too). The well known fields are probably:

• Displayed more prominently (e.g. Credit Card Number up front)
• Used to make AutoFill simple (e.g. Credit Card, Expiry, Addresses (from Identity entries))
• Perhaps makes Entry editing/creation more specialized/streamlined

Any extra fields that an entry has are also available, but perhaps not as prominently displayed. So, for me, I don't think we need to be exhaustive, just rather instead be minimal, e.g. we need:

• A minimal set of entry layouts as defined in the table above
• For each layout a minimal set of well known fields

Any extra fields are available but not specially displayed/processed by the App or the AutoFill component. What do you think?

[michaelk83]

Do we need an exhaustive list or would the 3 main ones work (AMEX, Visa, Mastercard)?

You'd need to at least add "Other" for the remaining types. There are functions to determine the type from the CC number, so this can be auto-filled or even left read-only. I don't recall the card type ever being asked on websites, and the title is enough for identification by the user, so IMO a read-only field or indicator would be more than enough. If you want to go the extra mile, you can check that the CC number is a valid (there's some sort of checksum), and display the card type logo next to the number field, or a red X if it's invalid (or just leave the logo blank when the number is invalid or the type is unrecognized).

I would add an Secure Question with Question and Answer as Password field

These are usually related to a particular entry, so it'd be best to allow adding (multiple) security questions to a regular entry, in the same way that you would add multiple phone numbers. But since this is more about regular entries, it may be outside the scope of the custom layouts feature. (This was recently raised in #8274 ).

[droidmonkey]

Yah sorry I took the list of fields as those that are shown. Title would suffice for card type and we can dynamically determine it for image and validation purposes on our side.

Secure question and answer should be recognized as a feature with a defined name on any entry, but not shown by default. Same with multiple phone numbers. This does bleed a little into the custom template discussion, but it is rather trivial to have PhoneNumber-1 and PhoneNumber-2 and support a ui that can add multiple "rows". This is usually accomplished in mobile by having the floating + sign in the bottom right that let's you add to a card or what not.

[strongbox-mark]

You'd need to at least add "Other" for the remaining types. There are functions to determine the type from the CC number, so this can be auto-filled or even left read-only. I don't recall the card type ever being asked on websites, and the title is enough for identification by the user, so IMO a read-only field or indicator would be more than enough.

@droidmonkey - Do you think then that we can eliminate the need for Credit Card Type field? If we can determine simply from the card number?

I would add an Secure Question with Question and Answer as Password field, so that I can copy it out easily.

I'm not sure about this one, as @michaelk83 said above, I think a lot of people just include these as extra fields in an entry rather than an entry by itself. Also as @droidmonkey says, this feels like a separate feature bleeding into another issue.

I think that we need to be minimal here and use a small set of very popular types initially to reach lots of people and get a feel for how well this "convention" system works.

That's my own personal take, I think we should lock the scope down now to the 4 above (Note, Credit Card, Email, Identity). We can always extend later if we like this method/paradigm.

[droidmonkey]

@strongbox-mark I think I answered your questions above your post

[strongbox-mark]

@droidmonkey Sorry, I wasn't a 100% on your answer...

Title would suffice for card type and we can dynamically determine it for image and validation purposes on our side.

When you say "Title would suffice for card type", what do you mean by Title? Like the Title field? What would it look like, e.g. I have an entry with the Title "Mark's Banking Card"? How do you determine card type from that?

Do you mean:

When there is an entry marked as a "CreditCard" entry, we would look at the "CardNumber" field and then be able to automatically determine the type of this card?

That is kind of how I saw this working. Sorry if I'm being dense! 🤦‍♂️

[droidmonkey]

The user can decide to write in the card type in the title field (like I do now) if they choose. No need for a separate field.

Separately, the keepass apps may choose to use the credit card number field to determine the card vendor and show an image for display purposes.

Sorry my brain merged those two sentences as I was typing before.

[strongbox-mark]

Got it, sounds good to me! 😀

@varjolintu - Any thoughts? would the above "convention" work well for you in the AutoFill context? e.g. the 4 "types" (Note, Credit Card, Email, Identity) and their associated "well known" fields?

[varjolintu]

@strongbox-mark Concerning browser integration there's ne exact preference how I'd like this to be done at KeePass/database side. Mapping the data from template to extension shouldn't be that difficult to do.

The credit card type is a tricky one. Now the extension's draft supports it but I haven't tested it. Few sites use it, and they usually excpect a string value for the <select> HTML element. If we discard the card type from the template, that is something users must fill manually when needed. Plus the card holder's name is often needed too.

Using an email template with browser makes me think about how the permissions for that are handled. Every page with a username/email field has access to that template automatically? Or do we have to explicitly ask a permission for that too (meaning.. almost every page would do it)? Maybe some global permission (at least for email template) is needed. Something like "Allow automatic access to this template" etc. With more secure data like Credit Card template, a separate permission is always needed.

[strongbox-mark]

The credit card type is a tricky one. Now the extension's draft supports it but I haven't tested it. Few sites use it, and they usually excpect a string value for the <select> HTML element. If we discard the card type from the template, that is something users must fill manually when needed. Plus the card holder's name is often needed too.

OK, yes, it is a tricky one... However, if you have the card number, I think it should be possible to figure out the type as discussed above by @michaelk83 ... If you have this auto-determined type then could your extension fill in the type for the user?

Plus the card holder's name is often needed too.

Yes and usually the address (billing and shipping) too... But this should then be made available by marking entries as "Identity" type. This includes name, address, postcode fields etc, which could then be automatically filled?

Using an email template with browser makes me think about how the permissions for that are handled. Every page with a username/email field has access to that template automatically? Or do we have to explicitly ask a permission for that too (meaning.. almost every page would do it)? Maybe some global permission (at least for email template) is needed. Something like "Allow automatic access to this template" etc. With more secure data like Credit Card template, a separate permission is always needed.

For sure, I think this is a KeePassXC specific issue, each KeePass client will have to manage this in their own way I think.

[droidmonkey]

I'd imagine the extension can determine the card type/vendor from the card number itself, same as the app. Alternatively we can send that calculation to the extension, it doesn't have to be a static field.

Card holder name might be a good field to add though! Forgot about that.

[varjolintu]

For sure, I think this is a KeePassXC specific issue, each KeePass client will have to manage this in their own way I think.

Yeah. This is just something I have to think all the time :) Using Identity template fields for filling a possible address during Credit Card fill also needs some permission adjustments.

[strongbox-mark]

Card holder name might be a good field to add though! Forgot about that.

Yes, here you go:

Layout Name	Custom Data "LayoutType" ID	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+	Should allow spaces
Entry with Email	EntryWithEmail	Email	Display an Email field with this entry.	.*
Identity	Identity	Name Phone AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 12a My Building Abbey Road NW8 9AY London United Kingdom	. . . . . . . .

[michaelk83]

Email is an interesting one:

• It's a very common field in online accounts, maybe common enough to include by default. (This has been requested multiple times.)
• It's sometimes used in addition to a username, but often instead of one.
• If you include a phone number in Identity, it makes sense to include an email as well. Other contact info can be left to custom fields, but almost everyone has an email these days.

I think it should be reconsidered as a standard field in the default entry type, alongside Username and Password, included also in the Identity type, and then Entry with Email can be dropped.

In KPXC, it may be useful to add a radio button to select whether Username or Email should be copied with Copy Username for each entry (and if one of them is empty, default to the other one).

[strongbox-mark]

I think it should be reconsidered as a standard field in the default entry type, alongside Username and Password, included also in the Identity type, and then Entry with Email can be dropped.

I'd love if KeePassXC did this too, Strongbox does it by default, but I think it's the only client doing it unfortunately. It uses the field name "Email" for this, and displays it as a standard "native" field like username/password etc.

then Entry with Email can be dropped.

That would be an excellent bonus.

If you include a phone number in Identity, it makes sense to include an email as well. Other contact info can be left to custom fields, but almost everyone has an email these days.

Makes sense I think... Will add if no objections...

[droidmonkey]

I think in lieu of having a template just for "and also email" I will strongly consider making it a first class feature on the normal entry page. It could even be hidden by default and "added" to an entry if the user wants it by clicking a drop down arrow or button.

[strongbox-mark]

Maybe for now then we could just go with the nice minimal set of three layouts:

Layout Name	Custom Data "LayoutType" ID	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+	Should allow spaces
Identity	Identity	Name Phone Email AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 john@email.com 12a My Building Abbey Road NW8 9AY London United Kingdom	. . . . . . . . .*

It'd be cool to see Email added as a "native" field in KeePassXC too 😀

[mainrs]

I am not sure if this needs extra consideration for the templates, but I wanted to bring it up nevertheless. Some of the templates would benefit from custom "actions" a user can perform to share them. For example the Identity type could use the vCard format and QR codes to make it easier to share the data. The same would hold true for custom WiFi templates.

P.S.: Is there any official specification of the backing Keepass 2.x file format (namely KDBX 4)?

[PoisonFrog]

What do you think?

Credit card also needs a PIN field.

[strongbox-mark]

Credit card also needs a PIN field.

Yes, good idea I think... Updated table:

Layout Name	Custom Data "LayoutType" ID	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV PIN	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code The PIN Code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+ [0-9]+	Should allow spaces
Identity	Identity	Name Phone Email AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 john@email.com 12a My Building Abbey Road NW8 9AY London United Kingdom	. . . . . . . . .*

@droidmonkey Do you think we could commit to the Custom Data Attribute Name for this feature, something like KPEX_LayoutType ? What do you think?

[droidmonkey]

I like it!

[mainrs]

@strongbox-mark Would it not make sense to make it possible to have more than a single phone number for an identity? A lot of people have a mobile number and a land line. That logic can be extrapolated to all other fields as well. But I think that phone numbers are a common enough scenario that it would make sense to support them.

[strongbox-mark]

HI @mainrs

This is just the minimal well-known set of fields so that browser extensions and display/input templates can have a minimal set to work with. The idea would be to try to keep these to an absolute minimum.

The way I see it, this doesn't mean you can't add as many fields/phone numbers etc as you like to an entry on top of this, and they would perhaps be displayed as 'Additional Fields' etc.

We're really trying to minimize scope creep here, which as you can see from the above thread has been a key goal, because this could easily get unwieldy. I mean, what about a Fax number? Work number vs Home number? How about social media handles/usernames as part of Identity? A photo or avatar attachment.

The line is a little arbitrary I'll admit, but if you can add additional fields to an Identity entry then you should be covered, and I think there's probably an 80/20 rule here that most people have a single number in most cases, which is what this spec should aim to cover.

That's just my humble opinion though :) Happy to hear others.

[mainrs]

Hey! I didn't read every comment to be honest and missed the statement that the set should be kept minimal! I totally agree with you! Sorry for the extra noise in this issue :)

[strongbox-mark]

Updated table to include the Custom Data attribute name (KPEX_LayoutType) above.

Layout Name	KPEX_LayoutType	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV PIN	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code The PIN Code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+ [0-9]+	Should allow spaces
Identity	Identity	Name Phone Email AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 john@email.com 12a My Building Abbey Road NW8 9AY London United Kingdom	. . . . . . . . .*

[tunbridgep]

I have been looking for template support similar to the Keepass Templates addon (https://github.com/mitchcapper/KPEntryTemplates) for Keepass-compatible programs outside of the original Keepass for a while now.

I was thinking of adding a $300AU bounty to this issue, with $100 going to keepassxc, $100 going to strongbox, and $100 going to Keepass2Android upon completion, as an incentive to get this implemented ASAP across the products that I use.

I don't actually use Strongbox but I can see the strongbox developers have been very integral to getting this implemented judging by the above comments on the issue.

How would I go about doing this in an official capacity?

I think in lieu of having a template just for "and also email" I will strongly consider making it a first class feature on the normal entry page. It could even be hidden by default and "added" to an entry if the user wants it by clicking a drop down arrow or button.

Can we get "and also a PIN" feature too? More and more devices and applications are now using "quick-unlock" style unlocking, where they have a regular normal password and a PIN for easy unlocking afterwards. Ctrl-Shift-C would be a great shortcut to copy the PIN as well.

[gmckeown]

I was going to open a feature request to support credentials that don't fit the standard username/password format, but I think this covers what I'm thinking of. Specifically for me, this arises because I'm working with the MS Graph API a lot currently, so I'm storing quite a few OAuth2 "credentials". The key information items for these entries are the Tenant ID, the Client ID and the Client Secret.

I am using Advanced -> Additional Attributes to store them currently, but it would be great to be able to create a specific OAuth2 Client Credentials Grant entry that had these fields immediately visible (not hidden in a separate tab as now) and would treat the Client Secret like a password.

Based on what I've read above, I think this fits within the proposal in this feature request?

[droidmonkey]

It doesn't but I plan to put the advanced (additional) attributes on the main edit page as part of this effort.

[gmckeown]

I think I may have completely misunderstood the purpose of the templates, then. From what I've read in this thread and the other, couldn't there be a template called OAuth2 Credential that presented the input like so:

[droidmonkey]

The request in this issue is a limited subset of the other request which is the general template request.

[gmckeown]

Ah, got it, thanks!

[Massimo-B]

I came here from https://github.com/keepassxreboot/keepassxc-browser/issues/1837. Having custom attributes like credit card numbers in Keepassxc, how can I get them completed inside a browser like Firefox, using keepassxc-browser?

[privatier51]

On the credit card template, please integrate a Luhn checksum algorithm to catch typos.

[trymeouteh]

When you create an entry, you should have the option to choose a template and KeePassXC should come with some templates.

The problem with many card apps like Catima and Loyalty Card Keychain on mobile, etc ks that they do not store the data in a file and instead store their data in the app itself

KeePass databases are perfect for this since KeePass clients always stores data in an encryptes file (KDBX) which allows the users to easily backup the data to the cloud or sync it to all of their devices with apps like Syncthing.

This could be for more than credit cards. Could be used for membership card and gift cards. The ability to display a barcode or QR code of the card number which can be scanned.

I would like to see a button when you tap the + button to make a new entry for cards, which will create a new entry with the following fields for a new card.

• Title (already a regular entry field)
• Card Number/String
• Card Type (Barcode, QR Code, none, etc)
• CVC
• Value (Value remaining on card)
• Expiry (already a regular entry field)
• Notes (already a regular entry field)
• Tags (already a regular entry field)
• NFC (Weather to enable NFC tap for card)

Such a feature will make KeePassXC a card card manager, gift card manager, membership card manager app and the best one on the market for desktop!

Maybe when it comes to field names for these templates, you can collaberate with these projects...

https://github.com/Kunzisoft/KeePassDX/issues/1225 https://github.com/keepassium/KeePassium

[Swoy]

How about Secure File?

I have plenty of use for a template that can give me the following new entry type:

Title Attachment Note

I currently use the normal entry type for this and add attachment as you do, but it would be awesome to push the attachment field to the front and omit all other (except maybe Expire, Title and Notes). This is extremely useful for certificates, keys or other super sensitive documents I want to store across Strongbox and KeePassXC

What is the consensus on this suggestion?

[michaelk83]

Skimming over this briefly again, it looks like the "Default" ("Web Service"?) entry layout wasn't defined. Do we leave it the same as it is now, or maybe simplify it? If additional attributes are moved to a (+) button on the main edit page, then the Default layout can be simplified to only Title, Username, Password, and URL. (All the other layouts should have a Title field as well.)

The (+) button can suggest additional common fields depending on the template:

• Default: Email, URL, TOTP, Notes, Expiry, Tags, Custom. Email and URL can be added more than once (numbered).
• Secure Note: Tags, Custom.
• Credit Card: Notes, Tags, Custom
• Identity: Phone, Email, Website, Address, Notes, Tags, Custom. All of these can be added more than once, except Notes and Tags (multiple tags would be entered in the same field, as today).

I'm not so sure anymore on whether to include Email by default in the Default layout. On the one hand, there are some arguments in favor, as discussed above. But OTOH, it can be trivially added through the (+) button when it's needed. Since it's often used instead of Username, having both shown by default would just add clutter. Maybe the Username field can automatically change to "Email" when an email address is typed into it?

Some additional thoughts from https://github.com/keepassxreboot/keepassxc/issues/9675#issuecomment-1662023690, more on the UI aspect:

Maybe replace the side bar [in the entry edit page] with a selection of the entry layouts, allowing the layout to be switched easily. Any non-empty fields would be be added to the selected layout same as they would through the (+) button. A ... option at the bottom of the layout selection bar would then show the current side bar, where you can add attachments, set auto-type, etc. (Btw, attachments could be moved to the (+) button as well.)

[K4LCIFER]

this feature focuses on adding a set of default entry templates that are shared amongst the various KeePass compatible applications.

Is it a requirement that there must be a pre-agreed-upon set of templates? I'm wondering if it would instead be possible to allow the user to also just create their own custom templates, or to edit the defaults.

[michaelk83]

I'm wondering if it would instead be possible to allow the user to also just create their own custom templates, or to edit the defaults.

The customizable stuff is in #863. That is a much bigger effort.

[K4LCIFER]

The customizable stuff is in https://github.com/keepassxreboot/keepassxc/issues/863.

Ah, my mistake. I misunderstood the comment at the end of that issue which linked to this issue -- I was under the impression that that issue was being moved to this one; I didn't realize that they were talking about two separate things. Sorry about that!

[dbalagansky]

I am not sure if this needs extra consideration for the templates, but I wanted to bring it up nevertheless. Some of the templates would benefit from custom "actions" a user can perform to share them. For example the Identity type could use the vCard format and QR codes to make it easier to share the data. The same would hold true for custom WiFi templates.

P.S.: Is there any official specification of the backing Keepass 2.x file format (namely KDBX 4)?

I second this.

Using vCard format (RFC) in, at least, an ability to import or export vCard files (combined or one contact per file) would be amazing, as the support for this format is widespread.

[mitchcapper]

Hi all. I am the (often absent) developer of https://github.com/mitchcapper/KPEntryTemplates and was pointed towards this thread by a user. I'll be honest, I tried to read the mass of this and related threads but it is quite a good bit so I have not read it all. I am working on a decent update for KPET to include switching from my advanced strings mess to using proper CustomData fields in entries. In the process will need to write a migrate function to cleanup old data for users. I like the idea of coming closer on a standardized format for custom UI. I am torn a bit between using something dead simple like @Kunzisoft's : https://github.com/Kunzisoft/KeePassDX/wiki/Templates and something more verbose like json. The KeePassDX style is close to json but still more compact (but non standard).

Did you folks end up reaching some sort of desired format?

Also, while clear that an entries template type should be stored in CustomData, I am not as sure about the template designs themselves. CustomData is clean, but Templates are not used by many users, and I kind of like the idea of using strings where a user can more easily edit the raw data if so desired (although clearly more error prone). It also gets history which im not sure if normal userdata does in the same way.

I like having a separate entry for each field, if for no reason other than its less corruptible if the user does edit the raw data (ie if you added an extra } you could just bork the specific listbox rather than the entire template.

I believe you are skipping over the UI designer right now, but if we do reach some consensus on how custom template configs work it clearly would benefit all projects in cross compat. I hope to only have one major version release where we have a data migration option, so for us now is the time to settle on our future format.

[droidmonkey]

@mitchcapper welcome!

The set of default entry layouts we decided on are here: https://github.com/keepassxreboot/keepassxc/issues/8228#issuecomment-1211902266

For this implementation, the entry's custom data field KPEX_LayoutType is set to the name of the layout. The UI arrangement of the fields is left up to the implementing application.

The totally custom layout (UI Designer) version of this thread is here: #863 Honestly, I don't think it is worth the coding time or effort to make a totally custom layout possible. However, we would want to use the same convention as the default templates, just reserve the default template names from reuse. Non-default templates would pull from the database custom data in some way to read the layout and other parameters.

See here for my theory on custom entry layouts: https://github.com/keepassxreboot/keepassxc/issues/863#issuecomment-680292058

[mitchcapper]

For this implementation, the entry's custom data field KPEX_LayoutType is set to the name of the layout. The UI arrangement of the fields is left up to the implementing application. I do see your layout types, just to confirm there is no current plan for describing how each layout in the layout type works right? I see it says KPEX_LayoutType " Credit Card" has fields XYZ, but no essential language plans for specifying layout types other than hard coding them in the actual code. I notice the "Field Names" are all custom. IE CardNumber is not stored in password but always stored in the field "CardNumber".

No problems here, replicating your templates with KPET would be fairly easy for the most part as it is just hard coded. One downside of hard coded is for things like "Secure Note" where you use the keepass notes field always. I am guessing KeePassXC does not differentiate between in memory protected fields and not, but for KeePass (and my own forks) these fields can be treated quite differently. The problem being that by hard coding it to the notes field on an entry means it can't have that protection flag ever set.

The totally custom layout (UI Designer) version of this thread is here: https://github.com/keepassxreboot/keepassxc/issues/863 I am curious about some of the design ideas you mention there:

• You store all the templates in one JSON blob attached to the database CustomData, any reason not to attach them to each individual template entry?
• User templates are stored in a separate CustomData section on the database. This would seem to imply the other templates are "Official" or "Application" based? If so why attach them to a database at all. What happens when the official template style changes do you just update everyones database on next save?
• I see the last recco you had would be for a fairly verbose JSON style configuration, this might be the right way to go (for one no custom parsers for any keepass application even if it cant understand all the design data contained) but with more complex json I would again move more towards it attached to each field rather than each entry to make manipulation easier and less error prone (if a users wants to copy a custom field to another template they just copy that advanced string from the template itself rather than have to worry about inserting some partial JSON they extract form one template into another templates position). I do like more loose JSON support (say trailing commas single/double quoting etc) but parsers for that can be trickier so for broad adaptability may be best to avoid.
• It doesn't sound like (if im not mistaken) KPXC will be using this data format for displaying UI any time soon, but you have at least put some decent time into thinking about what potentially is best.
• I will try to give it some more thought as well in terms of your suggested format rather than just some quick questions

[PhilippC]

I'm curious to read the feedback to @mitchcapper 's questions above.

From a Keepass2Android perspective:

• I'm open to support templates defined by KPEX_LayoutType in addition to the current support of KPEntryTemplates.
• I'm not planning special UI to define custom templates or to migrate templates. IMO users do not need to do this on a mobile device.
• Currently, if a database does not contain a set of templates (detected by their GUIDs), the app asks if the user wants to add them (as KPET compatible entries). If there will be different implementations for other platforms, it might be nice to ask the user in which format those should be added, because the app doesn't know what is used on the PC side.

In the Keepass2Android implementation, template support means that a template defines

• the visibility of each field (both standard fields and custom fields)
• the order in which custom fields are displayed
• if buttons are visible to add attachments or custom fields
• the initial value of a new entry's fields

I'm currently not supporting types or validation per field.