Old asset field "maintContractNumber" in legacy requisitions breaks provisioning after uprading to 1.10
Description
Acceptance / Success Criteria
None
is duplicated by
Lucidchart Diagrams
Activity
Show:
Seth Leger April 5, 2012 at 12:27 PM
I added a @Transient property that matches the old name and added a unit test to ensure that the XML value is persisted to the object properly. Marking as fixed.
commit bd981f8fa1b4e7ed78e2a1e47503da1eafcfc50f
Seth Leger April 5, 2012 at 10:14 AM
Because this is affecting existing installs, we need to come up with a solution ASAP in 1.10.
Fixed
Details
Details
Assignee
Seth Leger
Seth LegerReporter
Jeff Gehlbach
Jeff GehlbachLabels
Components
Fix versions
Affects versions
Priority
BlockerPagerDuty
PagerDuty Incident
PagerDuty
PagerDuty Incident
Created February 17, 2012 at 2:34 PM
Updated January 27, 2017 at 4:21 PM
Resolved April 5, 2012 at 12:27 PM
In OpenNMS 1.8, there was an asset field named "maintContractNumber". In OpenNMS 1.10, this field's name was shortened to just "maintContract".
The database changes are handled automatically, but it seems we missed the case where a user still has requisitions (either static on disk or dynamically generated) that use the old name for this field. Because of a long-standing bug in Provisiond, the presence in a requisition of an invalid asset record field name causes the synchronization of the entire requisition to abort silently. When this happens, the most obvious symptom is that all physical interfaces disappear from the nodes defined in the requisition.
Not sure what to do about this, but it's impacting at least one support customer (see https://mynms.opennms.com/Ticket/Display.html?id=1065) so we need to do something about it.