Fix requisition cache when accessing the Requisitions UI via "Edit in Requisition"

Description

As part of the work in https://opennms.atlassian.net/browse/NMS-10364#icft=NMS-10364, a new link was added to the node page to jump to the requisition UI for the node in question, to modify its settings on the requisition.

That AngularJS app uses a cache to avoid calling the ReST API to request all the data all the time, as this can be very expensive, especially on systems with hundreds or thousands of requisitions with hundreds or thousands of nodes on each of them.

So, when someone clicks on "Edit in Requisition", the proper page is displayed, as the Angular app supports routing via URL. But, when clicking on Save, the default behavior is going back to the requisition, and because the cache is empty, that will retrieve the whole requisition from the server, and when clicking back again, it will retrieve all the requisitions from the server.

Another side effect, and the reason of this JIRA issue, is that all the nodes will appear in red because the logic to obtain the requisition statistics to figure out if the node was persisted or not is also cached, and it is only requested when getting all the requisitions, which is, in theory, a bug, as that should work for a single requisition as well.

Another potential enhancement could be showing a modal window with similar content, hide the navigation links, and add "Save and Import". Both save operations will update the requisition and close the modal without the need to reload the requisition. If this makes sense, a new JIRA issue will be created for this feature.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Alejandro Galue November 5, 2019 at 8:42 PM

https://github.com/OpenNMS/opennms/pull/2800

This second PR improves the original solution to avoid undesired side effects.

Alejandro Galue October 23, 2019 at 8:16 PM

Fixed

Details

Assignee

Reporter

Affects versions

Priority

PagerDuty

Created October 23, 2019 at 11:47 AM
Updated November 5, 2019 at 9:11 PM
Resolved November 2, 2019 at 1:22 AM