Skip to content

Conversation

@ashutosh-engineer
Copy link

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
Copy link
Author

c11d8486-8637-4efd-969c-45d8753ddd4a

@robvanderveer
Copy link
Collaborator

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
Copy link
Author

ashutosh-engineer commented Jan 19, 2026

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
Copy link
Collaborator

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

@ashutosh-engineer
Copy link
Author

ashutosh-engineer commented Jan 20, 2026

@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.

Happy to open the PR in this form or adjust if you’d prefer any changes first.

Screenshot 2026-01-20 084239 image image

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

@ashutosh-engineer
Copy link
Author

ashutosh-engineer commented Jan 20, 2026

@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.

- Backend: Add read-only OpenCRE routing to existing graph traversal logic
- Frontend: Remove hardcoded OpenCRE entry to prevent dropdown duplication
- Make backend standards API the single source of truth for OpenCRE
- No data, schema, or ontology changes - only exposes existing relationships
- Remove generated bundle.js file from version control
- Add bundle.js and bundle.js.LICENSE.txt to .gitignore
- These are build artifacts that should not be tracked
Signed-off-by: ashutosh-engineer <ashutoshsingh6376@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add OpenCRE itself to mapanalysis

2 participants