Node label changes ourside requisition editor on nodes with a foreign-source ID

Description

This issue stems from MyNMS support ticket #209.

Steps to reproduce:

0. Log in to webapp as an admin user
1. Create a new provisioning group
2. Create a node in the new provisioning group
3. Synchronize the new provisioning group
4. Go to node list
5. Click on the node created in steps 1-3
6. Click on the "Admin" link in the secondary navigation strip
7. Click on "Change Node Label"

Expected outcome: one of:
1. The webapp recognizes that this node was created via requisition, explains the situation, and directs the user to change the node's label in the requisition and re-synchronize instead

OR (probably preferable, maybe not much more work):

2. The webapp recognizes the situation, exposes the same controls, but then uses the Provisioning ReST Service to change the node label in the requisition and request a re-sync.

Actual outcome:
The webapp treats the node as it would one with no foreign-source ID. I've seen conflicting reports, one saying that the label does not change, another saying that it does change but then "snaps back" the next time the requisition is re-synchronized. Neither is correct

Environment

Any OpenNMS 1.8.10 instance with at least one node created via a provisioning requisition (aka provisioning group)

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Alejandro Galue May 20, 2011 at 11:17 AM

Fixed on revision b5a40a4991950b2b355573bef8de01959324a129 for 1.8 branch.
Fixed on revision 1316a920e53eb3a368374c911d15a4c92f60af7b for 1.9 branch.

Alejandro Galue May 20, 2011 at 6:53 AM

I ended up to avoid the usage of REST API inside NodeLabelChangeServelt because of the issues related with user authentication.

The new work flow is this:

1. Calculate the new node label depending on request parameters (no changes added).
2. Create a new instance of NodeDao and RequisitionRestService (using WebApplicationContextUtils)
3. Inside of a TransactionCallback, retrieve the OnmsNode instance, check if the node has a foreign-source and foreign-id, if that is true, update the node label through the RequisitionRestService, else, the node label will be changed by the NodeLabel class.
5. Send the nodeLabelChanged event (no changes added).
6. If the node has a foreign-source, return to a special page indicating to the user that the label will be updated through the provisioning system, else, return to the node's page.

The "special page" will display something like this:

This node was created as part of a requisition via the provisioning service.
The requested change to the node's label has been made and will be reflected immediately in the requisition, but may not take effect in the database until the next time the node or requisition is rescanned.
If you want to re-import (or synchronize) the XXXXXX requisition, click on the "Synchronize" button. That will redirect you to the Provisioning Groups page, after request the requisition import.

Button for Synchronize
Button for Go to Node's Page

XXXXXX is the name of the foreign source.

Alejandro Galue May 19, 2011 at 10:15 AM

After some tests, I ended up by adding some changes to the class NodeLabelChangeServelt.

The new workflow will be something like this:

1. Calculate the new node label depending on request parameters (no changes added).
2. Create a new instance of RestTemplate (using HttpClient with basic authentication, with a magic-user)
3. Retrieve the OnmsNode instance using the REST API with RestTemplate.
4. If the node has a foreign-source and foreign-id, the node label change will be performed using the requisition's REST API; else, the node label will be changed by the NodeLabel class.
5. Send the nodeLabelChanged event (no changes added).
6. Return to the node's page (no changes added).

I made some tests separately and it appear to work, so I'll be doing some tests with the code inside NodeLabelChangeServelt, to see if everything works as expected before commit the changes.

Alejandro Galue May 18, 2011 at 4:32 PM

My ideas:

Checking the code, there are many ways to handle this problem depending how we want to attack it.

The first way (i.e. explain the user that this operation should be addressed using the administration page for provisioning and put a link for it), looks like the fastest and easiest way to address the problem, but certainly is not so elegant.

The second way is more interesting. We can hack into org.opennms.web.nodelabel.NodeLabelChangeServlet (from opennms-webapp) or org.opennms.netmgt.utils.NodeLabel (from opennms-services), but probably an easiest solution could be listen the event uei.opennms.org/nodes/nodeLabelChanged and create an event handler inside Provisiond service, for update and re-synchronize the node's requisition.

Thoughts?