Allow organize column #379

@thoms27 commented on GitHub (Aug 19, 2016):

Hi,

Yes, not to export, to choose which column display and the order.

Thanks :-)

@thoms27 commented on GitHub (Aug 19, 2016): Hi, Yes, not to export, to choose which column display and the order. Thanks :-)

adam commented

@mryauch commented on GitHub (Oct 26, 2016):

Hello,

Just wanted to chime in here. Picking which columns to display would certainly be helpful in the case that you have important custom fields. For instance, for circuits we have designated 'primary' 'secondary' 'tertiary' circuits, so I created a Priority custom field. Since I don't use tenants for circuits, that field is unused and wasted space in the listing of circuits, but I would love to be able to see at a glance which circuits are primary and backups.

Thanks

@mryauch commented on GitHub (Oct 26, 2016): Hello, Just wanted to chime in here. Picking which columns to display would certainly be helpful in the case that you have important custom fields. For instance, for circuits we have designated 'primary' 'secondary' 'tertiary' circuits, so I created a Priority custom field. Since I don't use tenants for circuits, that field is unused and wasted space in the listing of circuits, but I would love to be able to see at a glance which circuits are primary and backups. Thanks

adam commented

@Armadill0 commented on GitHub (Jan 20, 2017):

I would love to see this feature, too.

@Armadill0 commented on GitHub (Jan 20, 2017): I would love to see this feature, too.

adam commented

@hanej commented on GitHub (May 31, 2018):

Is this currently on track for a release?

@hanej commented on GitHub (May 31, 2018): Is this currently on track for a release?

adam commented

@mryauch commented on GitHub (Jun 1, 2018):

Originally I was interested in this feature, but honestly at this point I'm interacting with the API and making my own web interfaces to display this information anyways. I'm going the Flask route and using Netbox as a source of documentation, then interacting with the environment to compare documentation to reality.

In the circuit example I used before I'm planning on a circuit page that would grab all of the circuits in Netbox and display their BGP status and confirm if they're configured to be the 'primary' 'secondary' etc.

@mryauch commented on GitHub (Jun 1, 2018): Originally I was interested in this feature, but honestly at this point I'm interacting with the API and making my own web interfaces to display this information anyways. I'm going the Flask route and using Netbox as a source of documentation, then interacting with the environment to compare documentation to reality. In the circuit example I used before I'm planning on a circuit page that would grab all of the circuits in Netbox and display their BGP status and confirm if they're configured to be the 'primary' 'secondary' etc.

adam commented

@hanej commented on GitHub (Jun 1, 2018):

I think this is still hugely beneficial for those that would rather have everything in a single site instead of directing users to another site for some data and Netbox for others. I believe this makes sense as part of the core product.

@hanej commented on GitHub (Jun 1, 2018): I think this is still hugely beneficial for those that would rather have everything in a single site instead of directing users to another site for some data and Netbox for others. I believe this makes sense as part of the core product.

adam commented

@mryauch commented on GitHub (Jun 1, 2018):

Absolutely, it would certainly be nice to glance at Netbox and be able to see how everything is configured, but I was just illustrating on why it's not personally as important to me anymore.

This actually reminded me of how Docker allows you to set the format of commands with a simple json template.

# cat ~/.docker/config.json
{
  "psFormat": "table {{.Names}}\\t{{.Image}}\\t{{.Status}}"
}

# dps
NAMES               IMAGE                 STATUS
netbox_nginx_1      nginx:1.11-alpine     Up 13 days
netbox_app_1        netbox_app            Up 13 days
netbox_postgres_1   postgres:9.6-alpine   Up 13 days

I'm thinking just setting a template (edit: globally per view) or picking columns via the Admin panel would be sufficient, but I could see some power users wanting to be able to set columns themselves.

@mryauch commented on GitHub (Jun 1, 2018): Absolutely, it would certainly be nice to glance at Netbox and be able to see how everything is configured, but I was just illustrating on why it's not personally as important to me anymore. This actually reminded me of how Docker allows you to set the format of commands with a simple json template. ``` # cat ~/.docker/config.json { "psFormat": "table {{.Names}}\\t{{.Image}}\\t{{.Status}}" } # dps NAMES IMAGE STATUS netbox_nginx_1 nginx:1.11-alpine Up 13 days netbox_app_1 netbox_app Up 13 days netbox_postgres_1 postgres:9.6-alpine Up 13 days ``` I'm thinking just setting a template (edit: globally per view) or picking columns via the Admin panel would be sufficient, but I could see some power users wanting to be able to set columns themselves.

adam commented

Grafana Templating Example

@hanej commented on GitHub (Jun 1, 2018):

That template isn't a bad idea. It looks like a form of Jinja2. I can see doing something like this to create the template and save it as a view could work. If you take the Templating feature from Grafana and put that at the top of the view, the end user can select things like the prefix or VLAN of what they're interested in and reuse the same view to display that new data.

Also, when exporting from that view, the CSV file output would match the columns displayed on the screen. We really need this to display custom fields in with our external to internal NATS.

@hanej commented on GitHub (Jun 1, 2018): That template isn't a bad idea. It looks like a form of Jinja2. I can see doing something like this to create the template and save it as a view could work. If you take the Templating feature from Grafana and put that at the top of the view, the end user can select things like the prefix or VLAN of what they're interested in and reuse the same view to display that new data. Also, when exporting from that view, the CSV file output would match the columns displayed on the screen. We really need this to display custom fields in with our external to internal NATS. [Grafana Templating Example](https://play.grafana.org/d/000000143/templating?orgId=1)

adam commented

@lesinigo commented on GitHub (Apr 2, 2019):

My two cents here, we too have a use case involving custom fields and it would be really useful for us to customize default views. For example in the IP Addresses view we usually have three empty or "not really used" columns (NAT, Parent, Interface) but it would really help us to see the custom "fqdn" field.

As a case of columns customization we are already enjoying I'd bring the example of Redmine:

the default issues view
the same view with customized columns

In Redmine you can edit which columns to see and in what order directly from the page and they get encoded in the URL, while for our NetBox use case (and IMHO for the vast majority of people) it could probably be enough to configure columns from the admin interface.

@lesinigo commented on GitHub (Apr 2, 2019): My two cents here, we too have a use case involving custom fields and it would be really useful for us to customize default views. For example in the IP Addresses view we usually have three empty or "not really used" columns (NAT, Parent, Interface) but it would really help us to see the custom "fqdn" field. As a case of columns customization we are already enjoying I'd bring the example of Redmine: - the [default issues view](https://www.redmine.org/projects/redmine/issues) - the [same view with customized columns](https://www.redmine.org/projects/redmine/issues?utf8=✓&set_filter=1&f%5B%5D=status_id&op%5Bstatus_id%5D=o&f%5B%5D=&c%5B%5D=tracker&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=updated_on&c%5B%5D=category&c%5B%5D=cf_4&group_by=) In Redmine you can edit which columns to see and in what order directly from the page and they get encoded in the URL, while for our NetBox use case (and IMHO for the vast majority of people) it could probably be enough to configure columns from the admin interface.

adam commented

@jeremystretch commented on GitHub (Jun 24, 2019):

Blocked by #3294

@jeremystretch commented on GitHub (Jun 24, 2019): Blocked by #3294

adam commented

@havedill commented on GitHub (Nov 5, 2019):

+1 for this. We're automatically storing ansible facts into custom fields on the hosts. Would be great to choose these fields as display columns when on the devices/ virtual machines view

@havedill commented on GitHub (Nov 5, 2019): +1 for this. We're automatically storing ansible facts into custom fields on the hosts. Would be great to choose these fields as display columns when on the devices/ virtual machines view

adam commented

@Grokzen commented on GitHub (Nov 11, 2019):

@havedill I have implemented rendering of customfields in our own local netbox fork, and having more then 2-3 customfield columns is not something that you want to go to right now with how the CF:s is structured internally inside the database. The lookups and data fetching through django-tables is horrible in those scenarios and it makes the table rendering horrible slow. Yes i know there is probably a much faster way to render the column and prefetch the data then what i do, which is basically that i use a template column and a class method on the model to get up the CFV for that model object. So for a table with 50 rows, it would make 50 looksup to render one single column and scale that up with more rows and more columns and the performance will drop like a stone in water.

@Grokzen commented on GitHub (Nov 11, 2019): @havedill I have implemented rendering of customfields in our own local netbox fork, and having more then 2-3 customfield columns is not something that you want to go to right now with how the CF:s is structured internally inside the database. The lookups and data fetching through django-tables is horrible in those scenarios and it makes the table rendering horrible slow. Yes i know there is probably a much faster way to render the column and prefetch the data then what i do, which is basically that i use a template column and a class method on the model to get up the CFV for that model object. So for a table with 50 rows, it would make 50 looksup to render one single column and scale that up with more rows and more columns and the performance will drop like a stone in water.

adam commented

@Arkasha99 commented on GitHub (Feb 7, 2020):

Hi guys!
How's it going with this issue? Does anyone work on this? If anyone does, I could help you.

@Arkasha99 commented on GitHub (Feb 7, 2020): Hi guys! How's it going with this issue? Does anyone work on this? If anyone does, I could help you.

adam commented