Display related columns on DeviceComponents table

[llamafilm]

Fixes: #19590

Add additional columns to all DeviceComponents tables (including Interfaces, Power Ports, Device Bays, etc.)

• Device Description
• Device Location
• Device Site
• Device Serial
• Device Type
• Location Contacts
• All Device custom fields, prefixed with Device:
• All Location custom fields, prefixed with Location:

Add additional column to Device Bay table

• Installed Device Description

The custom fields are prefixed with Device: or Location:. The colon helps differentiate them as custom fields, but I'm open to feedback if there's a better way of labeling.

[llamafilm]

An example of why Installed Device Description is helpful for Device Bays. Non-rackmount equipment is typically modeled as a "child" of a Generic 1U Shelf parent.

Description describes to the bay itself, which is typically unused (by us).
Device Description describes the Device which contains the bay.
Installed Device Description refers to the device installed in the bay.

[llamafilm]

An example of how we will use some of these extra columns. This makes the Interface table look more like the spreadsheets of yore.

[jnovinger]

Thanks for the contribution, @llamafilm. The addition of second-order relations like device__location__contacts and automatic injection of dynamic custom field lookups creates expensive queries that don't scale for large installations and maintenance headaches down the road. These additions are not going to be accepted.

The original FR requested "Device Location and Device Site" but this adds 7+ columns, many more if including all of those dynamic custom fields automatically. Focus on just the two fields you specifically requested in issue #19590. This PR needs to be refactored to address only the specific fields requested in the original FR and to remove the automatic custom field injection and the second-order relation to contacts.

For access to data beyond what's available, users can use Export Templates or the REST/GraphQL APIs.

[llamafilm]

Ok, I thought you might say that. I understand your concern about complexity and performance with custom fields and contacts.

Can we please keep Device Description and Installed Device Description? That doesn't add anything to the SQL query and I've had multiple users ask for it.

[jnovinger]

Can we please keep Device Description and Installed Device Description? That doesn't add anything to the SQL query and I've had multiple users ask for it.

While this may seem like a reasonable request, I have to respectfully decline. Our process requires focusing on what was specifically outlined in the original feature request. Staying within the original scope prevents unplanned feature creep and ensures we can properly assess the maintenance commitment for each addition. I realize this seems arbitrary, but it is the process we have. If these additional fields are truly important, please consider filing a separate feature request that outlines the specific use case.