Skip to content

Allow Tags to be displayed in a specific order #17841

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
BrunoBlanes opened this issue Oct 23, 2024 · 8 comments
Closed

Allow Tags to be displayed in a specific order #17841

BrunoBlanes opened this issue Oct 23, 2024 · 8 comments
Assignees
Labels
complexity: medium Requires a substantial but not unusual amount of effort to implement netbox status: accepted This issue has been accepted for implementation status: backlog Awaiting selection for work type: feature Introduction of new functionality to the application
Milestone

Comments

@BrunoBlanes
Copy link
Contributor

BrunoBlanes commented Oct 23, 2024

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.

  • Index ordering 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. -128 to 128, 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.

@BrunoBlanes BrunoBlanes added status: needs triage This issue is awaiting triage by a maintainer type: feature Introduction of new functionality to the application labels Oct 23, 2024
@Mailstorm-ctrl
Copy link

Mailstorm-ctrl commented Oct 23, 2024

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.

@BrunoBlanes
Copy link
Contributor Author

BrunoBlanes commented Oct 23, 2024

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.

@Mailstorm-ctrl
Copy link

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.

@BrunoBlanes
Copy link
Contributor Author

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.

@chris240189
Copy link

So pretty much like the "display weight" of custom fields, just to get some sorting.

@BrunoBlanes
Copy link
Contributor Author

So pretty much like the "display weight" of custom fields, just to get some sorting.

Well when you put it like that...

@jeremystretch jeremystretch added the netbox label Nov 1, 2024 — with Linear
@jeremystretch
Copy link
Member

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.

@jeremystretch jeremystretch added needs milestone Awaiting prioritization for inclusion with a future NetBox release complexity: medium Requires a substantial but not unusual amount of effort to implement status: backlog Awaiting selection for work and removed status: needs triage This issue is awaiting triage by a maintainer labels Feb 6, 2025
@jeremystretch jeremystretch removed the needs milestone Awaiting prioritization for inclusion with a future NetBox release label Feb 20, 2025
@jeremystretch jeremystretch added this to the v4.3 milestone Feb 20, 2025
@jnovinger jnovinger self-assigned this Mar 14, 2025
@jnovinger jnovinger added the status: accepted This issue has been accepted for implementation label Mar 17, 2025
@jnovinger
Copy link
Member

Fixed in #18930

jeremystretch pushed a commit that referenced this issue Mar 20, 2025
* Fixes #17443: Adds ExportTemplate.file_name field

* Addresses PR feedback

- Adds `file_name` to `ExportTemplateBulkEditForm.nullable_fields`
- Shortens max length of `ExportTemplate.file_name` to 200 chars
- Adds tests for `ExportTemplateFilterSet.file_extension`

* Fixes migration conflict caused by fix for #17841
jnovinger pushed a commit that referenced this issue Apr 11, 2025
* #14591, #17841: Adjust default weighting

* Fix tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: medium Requires a substantial but not unusual amount of effort to implement netbox status: accepted This issue has been accepted for implementation status: backlog Awaiting selection for work type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

5 participants