Closes #6930: Add 'ID' column to object tables

[rhyser9]

Closes: #6930

Adds an 'ID' column to most object tables, which is hidden by default. This column exposes Netbox's numeric ID for that object.

The column has been added to the following tables:

• Organization > Site, Region, Site Group, Location, Rack Role, Rack, Rack Reservations, Tenant, Rack Role, Rack, Rack Reservation
• Devices > Manufacturer, Device Type, Device Role, Platform, Device, Virtual Chassis
• Device Components > Console Port, Console Server Port, Power Port, Power Outlet, Interface, Front Port, Rear Port, Device Bay, Inventory item
• IPAM > IP Addresses, IP Ranges, Prefixes, Prefix & VLAN Roles, VRFs, Route Targets, VLANs, VLAN Groups, Services
• Virtualization > Virtual Machines, VM Interfaces, Clusters, Cluster Types, Cluster Groups
• Circuits > Circuit Types, Providers, Provider Networks
• Power > Power Feeds, Power Panels
• Other > Journal Entries, Change Log Entries, Custom Fields, Custom Links, Export Templates, Webhooks, Tags, Config Contexts

Regarding the "Circuits" table, this already exposes the circuit ID under the 'ID' header. My thought would be to change the circuit ID header to 'Circuit ID', and then add the Netbox 'ID' column, but this could potentially break anything that consumes the CSV exports, and thus would need to wait for v3.1.0.

[jeremystretch]

I'm afraid your approach of explicitly declaring a separate id column of every table isn't tenable. Instead of re-declaring this column everywhere, it should be added to the parent BaseTable class so that it's inherited by each child table automatically.

Ideally, the id column should also be added to Meta.fields automatically, but I think it's fine to leave it in the individual classes as you have it for now.

[rhyser9]

Yeah, that's what I figured. I was hesitant to add it directly to the BaseTable class in case there were any children that shouldn't receive the ID column. Instead, I defined it on all the first-level children. I'll shift it back up a level.

[jeremystretch]

I'm almost certain we never use BaseTable for anything other than database objects, and all database objects have an id field, so it should be fine.

[rhyser9]

un-linkify the id column, because device component templates don't have a detail page to link to. The device detail page errors without this because there's no get_absolute_url method on the component template model.

[rhyser9]

Exclude the id column from the device component template tables in the device type detail view. It didn't really make sense to include them (though that might be subjective).

[rhyser9]

Exclude the id column from the 'Tagged Objects' table in the Tag detail view. This contains objects from several different models, so ID isn't unique. It didn't seem to make sense to include it (subjective).

[DanSheps]

Alternatively, you can create a custom field (or use a template field) and link to the appropriate objects view

[rhyser9]

Actually, I said that wrong. TaggedItem does have an ID for the TaggedItem object itself, which is not the same as the corresponding object's ID. The TaggedItem ID isn't useful information to expose, as I don't think that's accessible/usable anywhere?

I could make the ID column expose the object ID instead, but I wasn't sure how useful that is for a couple of reasons.

1. this table isn't exportable, which is the primary reason this change was requested in the first place (though, the ID column is currently on plenty of other non-exportable table views, so that's kind of moot).
2. object ID isn't inherently unique in this table, so needs to be used in conjunction with the type column in order to extract useful information
3. If linkify-ing it, the object column is already linked to that object's detail page

Though, now that I actually look at it again, it's a lot easier to properly include the object ID and linkify it than I initially thought it would be, so this isn't really a big deal to add/get working after all.

[rhyser9]

Not sure if this needs to be defined differently now that it's elevated to the BaseTable class? Also, should it move up above the Meta definition / does that matter?

[jeremystretch]

It should go above the Meta class, but I can take care of that after merge. Looks good otherwise, thanks!

[rhyser9]

Okay, I think this is ready for another review. I elevated the id column definition up to the BaseTable class. I had to override it / exclude it in a few places where the ID column either didn't make sense (somewhat subjectively), or where the linkify needed to be removed because there was nowhere to link it to.

Currently, there's an issue where CircuitsTable and VlanTable have two columns with the verbose_name 'ID'. This is because the circuit ID / vlan ID are also exposed under the 'ID' header. I think these should be updated to be called 'Circuit ID' and 'VLAN ID', but then the CSV export format changes. Is that acceptable for this PR, or should that become a separate issue (potentially targeted towards v3.1.0 instead as a breaking change)?