snipe
[Feature]: Multivalued custom fields
Snipe-IT Version
(Grokability Hosted)
How can we help?
Right now the only option to get multiple (editable) values are: Textarea, Multiple custom values with different names The latter is unusable for scenario where you need multiple values but you do not know how many. The example is an IPv4 Address. I can have a PC with1, 2, 3 even sometimes more IPv4 addresses and I want to have them documented nicely in the Snipe-IT. Textarea helps to some extend, but options like holding unique values won't work properly there. And you have to be very specific with reg exp controlling such values as this is becoming multiline expression.
So general idea is to be able to configure a single custom text field value as multi-value type. It could have also a fixed amount of values or simply left flexible (with some hard limit defined). Multi-value custom field could be unique - it means it should verify if all sub-values are unique inside the whole DB, and while editing there should be an option to dynamically add / remove new values within defined limit (if applicable). Reg exp check would apply to a single value. I know this could be challenging, but this would make some things more reasonable and clear, also considering API exchange (where values could be returned as a json array and would not have to be re-interpreted. Bonus -> List Box as a multi-value. The same behavior as multi valued text field, but instead of entering text a single choice list is defined and makes possible for each values only to chose from the list. Something like this would be a godsend f.e. for choosing VLANs connected to an asset.
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
No, I meant something like this:
Checkboxes allows only to mark values from predefined list. It could be helpful with my "Bonus" point with one caveat -> Checkboxes are alright when you have only few values. If you have dozens or hundreds then they are useless, that's where would Multivalued List Boxes shine.
I see what you mean. I'm not really sure how we'd do that, since they're single fields on the asset table, so they'd need to be stored in one field. It's an interesting idea, for sure though. We'll definitely give it some consideration.