Hello, I believe it would be very interesting having custom fields which get calculated from other fields.
In my specific case, I have a CODE field whose value needs to be PIN + OTP, the pin is stored in a custom field called PIN, and it would be cool to be able to create field CODE with value $PIN$OTP, where the $ values get translated to the correct fields.
I think you are on a good track, although $fieldname likely would run into ambiguities. For example if I had both PIN and PIN1 fields, would a reference to $PIN1 mean I wanted to use the first field, appending a digit to the end, or did I mean to reference the second field. Modern languages solve this with brackets e.g. abc{fieldname}def
I’d also suggest it not necessary to limit it to fields both within the vault entry. Also allowing abc{vaultentry:fieldname}def would make this a very powerful capability and could be a solution for another FR, Field References (Ability to set different usernames for different websites using the same password).
I also think it would be necessary to have a new field type (perhaps “calculated”) so one does not need to worry about escaping dollar signs or an open brackets if all they want to do is paste in their value (e.g. an autogenerate password).
Again, great feature request. It has my vote.
1 Like
Although I can see this could be useful for such a situation, I’m afraid it’s probably too niche to justify the effort required: string/variable interpolation is a hard problem in programming, and exposing that to the user would not be without its share of hard to track bugs.
In my opinion, this is one case where the service requiring you to input {pin}{otp} is actually the one at fault: those are separate authentication factors, and should be asked for one at a time; there seems to be no security advantage in asking the user to collapse N auth factors into a single string.