You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Add description varchar field (nullable) to the maint_component table (MaintenanceComponent model).
Populate the new description field for all maintenance components that still exist as part of the migration
Populate the description field for maintenance components with opaque primary keys as they are added to a maintenance task
Update the maintenance task UI to show the description field for components that have been deleted.
The text was updated successfully, but these errors were encountered:
Today, when a netbox (say, with a primary key of
42
and 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
42
isn'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
description
varchar field (nullable) to themaint_component
table (MaintenanceComponent
model).description
field for all maintenance components that still exist as part of the migrationdescription
field for maintenance components with opaque primary keys as they are added to a maintenance taskThe text was updated successfully, but these errors were encountered: