feat(myopencre): implement MyOpenCRE frontend functionality behind backend capability flag

[PRAteek-singHWY]

Summary

This PR introduces the MyOpenCRE frontend functionality, enabling the MyOpenCRE feature to be conditionally displayed based on the ENABLE_MYOPENCRE runtime flag. This feature ensures that MyOpenCRE functionality is only available when the flag is enabled, in alignment with the backend capability gating.

This PR depends on #700, which implements the backend for MyOpenCRE. With this PR, we have connected the frontend to the backend, allowing MyOpenCRE UI elements to appear and function only when the backend provides the capability signal.

Files Modified

The following files were modified as part of this PR:

• application/frontend/src/hooks/index.ts
• application/frontend/src/hooks/useCapabilities.ts (New file)
• application/frontend/src/hooks/useLocationFromOutsideRoute.tsx
• application/frontend/src/routes.tsx
• application/frontend/src/scaffolding/Header/Header.tsx
• application/frontend/src/scaffolding/MainContentArea/MainContentArea.tsx
• application/frontend/src/scaffolding/Router/Router.tsx

Other changes are incidental (formatting, imports) and do not affect the logical behavior of the application.

What Changed

• Frontend capability hook: The useCapabilities hook was added to fetch the myopencre capability from the backend and conditionally render the MyOpenCRE UI.
• Dynamic MyOpenCRE display: The MyOpenCRE UI elements (like CSV import/export buttons) are now shown only if the ENABLE_MYOPENCRE flag is enabled (i.e., if myopencre is true).
• Integration with backend capability signal: The frontend is now connected to the /api/capabilities endpoint, which informs whether MyOpenCRE should be displayed based on the current deployment configuration.

Why This Change Was Introduced

The MyOpenCRE feature requires administrative control for self-hosted deployments. By gating the feature behind a runtime flag, it prevents accidental exposure on public platforms and ensures that it’s only accessible when explicitly enabled. This PR ensures that the frontend only shows the MyOpenCRE features when they are actually available, preventing user confusion.

This change:

• Ensures that MyOpenCRE UI elements are hidden unless ENABLE_MYOPENCRE=true is set.
• Provides the necessary frontend changes to work with the backend capability signal.
• Lays the groundwork for future user role-based gating once user authentication and roles are implemented.

Testing

• ENABLE_MYOPENCRE=false (default):

  • The MyOpenCRE UI elements are not displayed.

• ENABLE_MYOPENCRE=true:

  • The MyOpenCRE UI elements appear and are fully functional.

Stacking / Follow-ups

This PR depends on #700 for the backend functionality (capability gating).

• Future UI-focused PRs (such as MyOpenCRE: add CSV import preview, confirmation step, and improved UX safeguards #685 for preview and MyOpenCRE: add inline help for CSV preparation #686 for help guide) will be rebased onto the main branch after this PR is merged, as they rely on this frontend functionality.

Next Steps

• A follow-up PR will integrate feature flagging for user roles (once Add support for users #586 is completed), allowing us to expose or hide MyOpenCRE based on the user’s role (e.g., admin vs non-admin).

Conclusion

This PR provides the frontend functionality for MyOpenCRE based on the backend ENABLE_MYOPENCRE flag. It ensures that MyOpenCRE is only available when the backend allows it and is ready to be used in self-hosted deployments. Future work will refine user role-based controls and feature flagging for even finer control.

[PRAteek-singHWY]

Hey @northdpole , Sir Thanks for the feedback earlier ! I've implemented runtime flag gating for MyOpenCRE to ensure it’s only available on self-hosted/admin-controlled OpenCRE instances. This prevents accidental exposure on platforms like opencre.org.

With this setup, MyOpenCRE will only be active when enabled via the ENABLE_MYOPENCRE flag on self-hosted instances. For opencre.org, the feature remains inactive.

Looking ahead, once user scoping (#586) is in place, we’ll implement feature flagging at the user level to control visibility based on roles (e.g., admin vs non-admin), offering finer access control.

Appreciate your guidance, and I look forward to continuing the work! Would love to hear your thoughts on this!