Feat/dashbaord api calls

[jazzgrewal]

Description

Please provide a summary of the change and the issue fixed. Please include relevant context. List dependency changes.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• [x] Tested Locally

Checklist

• [x] I have read the CONTRIBUTING doc
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [x] Any dependent changes have already been accepted and merged

Further comments

---

Thanks for the PR!

Any successful deployments (not always required) will be available below.

Backend: https://nr-silva-313-backend.apps.silver.devops.gov.bc.ca/actuator/health Frontend: https://nr-silva-13-frontend.apps.silver.devops.gov.bc.ca

Once merged, code will be promoted and handed off to following workflow run. Main Merge Workflow

[webgismd]

I am happy to chat about next steps or where I can support this, if we block things as they currently are, what are some of the tasks we can address short term or long term.. I know this is end of sprint, it could be a good time to discuss in a retrospective with team? @jazzgrewal @DerekRoberts @RMCampos @PMAKIA1

[RMCampos]

what are some of the tasks we can address short term or long term..

We have some tasks on the backlog already. But I'd say we can work on some definitions such as the one @mishraomp brought up, and avoid hardcoded URLs. Retro is a perfect plate to chat about this.

[DerekRoberts]

@jazzgrewal @RMCampos Would you like a hand? I can pitch in for the vars and routing, but not tests.

[DerekRoberts]

@jazzgrewal This is a code review, not (intentionally) an argument. Please elaborate?

[DerekRoberts]

Spoke with @jazzgrewal. Tests are going to be addressed in an upcoming issue. This can be approved when we've tackled the hard links.

[DerekRoberts]

@jazzgrewal @RMCampos Hard coding should be fixed. Please confirm?

[jazzgrewal]

@DerekRoberts can we not reuset the VITE_BACKEND_URL for the BACKEND URL, I think the values are thesame for both right?

[DerekRoberts]

@jazzgrewal Not quite! VITE_BACKEND_URL has the port at the end. I also couldn't find where it was being consumed, so it could be a candidate for removal.

[jazzgrewal]

@DerekRoberts I think the port number is just for the localhost, for the test and prod we just have link without port numbers :)

[DerekRoberts]

@jazzgrewal Here! If you really want to use that envar we have to clip off :443 or find where it's being consumed to make adjustments. https://github.com/bcgov/nr-silva/blob/7be351f42cdf58fe6e01a72582ceea848b5f6c94/frontend/openshift.deploy.yml#L102

[jazzgrewal]

I tried putting: VITE_BACKEND_URL = https://nr-silva-test-backend.apps.silver.devops.gov.bc.ca:443 with 443, doesn't matter the api calls are still good. So this can be good to go without having to add another variable. and regardless when we are adding env variables in VITE we need to have the VITE. prefix or it just wont work.

[DerekRoberts]

@jazzgrewal Good job! Glad this is done. :)