Enable OpenCRE as selectable standard in map-analysis

[ashutosh-engineer]

This PR enables OpenCRE to be selected on either the left or right side in the map-analysis view.

• UI-only change
• No data or ontology changes
• Uses existing mappings

Fixes #469

[ashutosh-engineer]

[robvanderveer]

Dear @ashutosh-engineer , with all due respect: based on that question I have to conclude that your understanding of the OpenCRE data structure fundementals is currently insufficient to make a reliable change. The essence of OpenCRE is that a standard links to CREs and because other standards also link to those CREs, they link to each other. In other words, OpenCRE forms an intrinsic part of the graph. I strongly advice not to go ahead and make changes before this understanding is solid.

[ashutosh-engineer]

Dear @ashutosh-engineer , with all due respect: based on that question I have to conclude that your understanding of the OpenCRE data structure fundementals is currently insufficient to make a reliable change. The essence of OpenCRE is that a standard links to CREs and because other standards also link to those CREs, they link to each other. In other words, OpenCRE forms an intrinsic part of the graph. I strongly advice not to go ahead and make changes before this understanding is solid.

Thanks for the earlier clarification — I spent some time going through the codebase and the map-analysis logic to make sure I fully understand the model.

My understanding now is:

1. OpenCRE is not a standard document, but the CRE layer of the graph itself.
   2.This is a read-only graph traversal concern, not a data modeling or ontology change.
   3.Existing map-analysis already works as: Standard → CRE → Standard, where CREs are currently implicit.
   4.Supporting OpenCRE in map-analysis is about exposing those existing CRE nodes by adjusting query patterns, not adding data or creating new nodes.

Concretely, this means:
1.Matching all NeoCRE nodes (without filtering by a “standard name”)
2. Allowing CRE nodes as valid endpoints in the traversal
3.Keeping everything read-only, with no schema or mapping changes

If this understanding aligns with your expectations, please let me know if it’s okay for me to proceed with backend change following this approach.

Thanks for the guidance, Sir

[robvanderveer]

Excellent, please proceed and feel free to abort this task if you feel uncomfortable with the complexity.

[ashutosh-engineer]

@robvanderveer
Thanks for the go-ahead. Here’s a concise summary of what I implemented and how it was verified locally.

What was done:

• Added read-only backend support for OpenCRE in map-analysis by routing requests when either side is “OpenCRE”.
• Implemented OpenCRE-specific traversal using existing graph relationships only (no data, schema, or ontology changes).
• Handled all three cases:
  • Standard → OpenCRE
  • OpenCRE → Standard
  • OpenCRE → OpenCRE (CRE hierarchy)
• Updated the standards endpoint to include “OpenCRE” when CREs exist in the database.
• Removed frontend-side injection to avoid duplicate “OpenCRE”; the backend is the single source of truth.

How it was verified:

• Ran the app locally with Neo4j and Redis.
• Used minimal test data (3 CREs + 3 CWE entries) to validate routing and behavior.
• Confirmed:
  • “OpenCRE” appears exactly once in both dropdowns.
  • No 500 errors when selecting OpenCRE on either side.
  • Backend correctly executes OpenCRE-specific traversal; with limited data, returning “no result” is expected because of no relationships.
• Known local limitation (make --upstream_sync also sync the gap analysis graph progressively #534) acknowledged; full results depend on a populated Neo4j dataset.

The limited set of standards was intentional and only meant to validate routing and traversal behavior locally.

[ashutosh-engineer]

@robvanderveer The changes have been implemented and verified locally with minimal test data.

I have committed the recent code in the PR, please let me know if you’d prefer this submitted as-is in its current form, or if you’d like any adjustments first.