Today, when a netbox (say, with a primary key of 42 and a sysname of example-sw) is added as a maintenance task component, and later the netbox is deleted, the maintenance task will display the component as Netbox: 42 (Component was deleted).
This is intentional, i.e. we want to keep a record of the fact that something was added to a task, even if that something no longer exists in NAV.
However, referring to the netbox as 42 isn't helpful, when all users have known it as example-sw. The netbox record itself is gone, but if the maintenance component itself could record the netbox' sysname when it was added, this could be shown instead.
This is less crucial for locations and rooms, as they do not have opaque integer primary keys in NAV, but string primary keys that are identifiable even after they have been deleted. We might need a description for services, though.
The desired solution
[x] Add description varchar field (nullable) to the maint_component table (MaintenanceComponent model).
[x] Populate the new description field for all maintenance components that still exist as part of the migration
[x] Populate the description field for maintenance components with opaque primary keys as they are added to a maintenance task
[x] Update the maintenance task UI to show the description field for components that have been deleted.
Today, when a netbox (say, with a primary key of
42and a sysname ofexample-sw) is added as a maintenance task component, and later the netbox is deleted, the maintenance task will display the component asNetbox: 42 (Component was deleted).This is intentional, i.e. we want to keep a record of the fact that something was added to a task, even if that something no longer exists in NAV.
However, referring to the netbox as
42isn't helpful, when all users have known it asexample-sw. The netbox record itself is gone, but if the maintenance component itself could record the netbox' sysname when it was added, this could be shown instead.This is less crucial for locations and rooms, as they do not have opaque integer primary keys in NAV, but string primary keys that are identifiable even after they have been deleted. We might need a description for services, though.
The desired solution
descriptionvarchar field (nullable) to themaint_componenttable (MaintenanceComponentmodel).descriptionfield for all maintenance components that still exist as part of the migrationdescriptionfield for maintenance components with opaque primary keys as they are added to a maintenance task