netbox-community
Allow `Tags` to be displayed in a specific order
NetBox version
v4.1.0
Feature type
New functionality
Triage priority
N/A
Proposed functionality
Add an integer Index field to the Tag object definition which can be used by the frontend to order tags first by Index, then alphabetically when displaying them.
Indexordering should be from lowest to highest value, where the lowest value has the highest priority and therefore it is displayed before any other tags- Some sort of hard limit, e.g.
-128to128, could be implemented for optimization - The default index value must be zero
- For tags with the same index, alphabetical sorting should be the default behavior. This is to ensure that, when migrating to this implementation existing behavior is preserved.
Use case
There are innumerous use cases for tags, one such case is the ability to give information about an object such as a virtual machine:
NETPY CLT01 VM108 APCHE
| | | |_ Gives a clear visual hint of the service running in this machine
| | |________ Shows the virtual machine name according to our virtualization system
| |_______________ Identifies the cluster where this machine belongs to
|_____________________ Identifies the tenant
It would be lovely to display the four tags in the aforementioned order, since that is the formal name of this object and everywhere in our internal processes and documents, we refer to this virtual machine as NETPY-CLT01-VM108-APCHE.
Having the ability to sort tags when displaying objects in Netbox will allow for further customization and integration with other systems that rely on tags for looking up objects.
Database changes
A new integer column for the Tag table definition.
External dependencies
None that I am aware of.
So if you want a standardized tag order to represent a name....why not just make that the name of whatever object you are naming? You can make custom validators that make it so names conform to a regex based on available attributes. For instance, part of our naming is <region><sitecode> which gets dynamically pulled based on the already existing attributes of the object. If the attributes weren't there, it would still be possible to write a custom validation that meets your needs.
For specifically about your VM example...cluster information already exist. In fact you can't make a VM without a cluster and a cluster can be assigned a tenant and a site.
So if you want a standardized tag order to represent a name....why not just make that the name of whatever object you are naming?
Because not all objects have names, for instance I could want to do this to an IP address.
For specifically about your VM example...cluster information already exist. In fact you can't make a VM without a cluster and a cluster can be assigned a tenant and a site.
You can actually make a VM without a cluster, it is not a requirement.
I don't want you to get attached to the naming possibilities here, this functionality can be used for many other use cases.
I don't want you to get attached to the naming possibilities here, this functionality can be used for many other use cases.
Ultimately it's the netbox team decides which I am not. But as feedback this doesn't seem like a useful addition to tags and is fairly niche and can be accomplished with other means. It's also the only example you've given so hard to think of other use-cases.
But for the index...would it be set on the tag model or within the model you are apply the tag to? For example if I have tag NETPY, am I setting the index when I initially make the tag (thus it's a "global" index) or is it set at the model where tag NETPY could have an index of 10 on one object but 15 on another? I would think (if implemented), it would make sense just to be able to re-arrange tags within the form to your desired order.
You can actually make a VM without a cluster, it is not a requirement. Turns out this is half true. I always thought it was a requirement but you need a site OR a cluster. I just saw the position of the error was under cluster and assumed it was wanting a cluster.
But for the index...would it be set on the tag model or within the model you are apply the tag to?
The proposal is for it to be added to the tag model.
So pretty much like the "display weight" of custom fields, just to get some sorting.
So pretty much like the "display weight" of custom fields, just to get some sorting.
Well when you put it like that...
There's a weight field for Prefix/VLAN roles as well, which is likewise used to effect arbitrary ordering. I think we could do that for tags.
