You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of custom fields only allows for a single value. I propose that we allow to add multiple instances of a custom field much the same tags can be applied to almost anything
Use Case
To add static routes on a device, I currently use a custom field attached to an interface IP using the following format:
<prefix>/<prefixlen> via gateway[,<prefix>/<prefixlen> via gateway]
Example:
192.0.2.0/24 via 203.0.113.1,198.51.100.0/24 via 203.0.113.1
This is currently cumbersome for a few reasons:
The field length is limited
It can be hard to create, read, and edit for large numbers of values
It's hard to validate
Instead, it would be cleaner to be able to add multiple instances of a custom field such that each value could be added, edited, removed, and validated individually.
ie.
192.0.2.0/24 via 203.0.113.1
198.51.100.0/24 via 203.0.113.1
Database Changes
I would imagine new tables need to be created for the new 1:M relationships.
External Dependencies
The text was updated successfully, but these errors were encountered:
Environment
Proposed Functionality
The current implementation of custom fields only allows for a single value. I propose that we allow to add multiple instances of a custom field much the same tags can be applied to almost anything
Use Case
To add static routes on a device, I currently use a custom field attached to an interface IP using the following format:
<prefix>/<prefixlen> via gateway[,<prefix>/<prefixlen> via gateway]
Example:
192.0.2.0/24 via 203.0.113.1,198.51.100.0/24 via 203.0.113.1
This is currently cumbersome for a few reasons:
Instead, it would be cleaner to be able to add multiple instances of a custom field such that each value could be added, edited, removed, and validated individually.
ie.
192.0.2.0/24 via 203.0.113.1
198.51.100.0/24 via 203.0.113.1
Database Changes
I would imagine new tables need to be created for the new 1:M relationships.
External Dependencies
The text was updated successfully, but these errors were encountered: