Replace userAuthGroup with userRole in vehicles - Part 2

[krishnan-aot]

Description

• Replace userAuthGroup with userRole in vehicles
• Corresponding alignment changes in frontend to change userAuthGroup to userRole in request and response bodies. Note that this is only a subset of changes to align with API change. There will be additional PRs to modify the language in frontend.

Some core terminology changes regarding permissions:

• roles will be claims
• userAuthGroup will be role

This is because, PPC_CLERK , SYS_ADMIN etc. among IDIR and COMPANY_ADMIN , PERMIT_APPLICANT among BCeID are all roles a user can take on. They should have been called roles to begin with.

READ-DOCUMENT, READ-PERMIT, WRITE-PERMIT etc. are all claims useful in a claim based authorization model. However, in our system, we never talk about these claims to business and for the most part, they aren't even aware of the development around this. They only care about the user's role like PPC_CLERK. These should have been called claims to begin with.

But because we misnamed claims as roles, we had to call the actual roles as userAuthGroups, we were stuck in a perennial confusion cycle of how to consolidate authorization and kept mixing up terminology and hence our permission implementation became a lot of custom calculation when in reality we needed a simple role based authorization scheme.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• 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

• Test A
• Test B

Checklist

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

Further comments

---

Thanks for the PR!

Deployments, as required, will be available below:

• Frontend
• Vehicles
• Dops
• Policy
• Scheduler

Please create PRs in draft mode. Mark as ready to enable:

• Analysis Workflow

After merge, new images are promoted to:

• Merge Workflow

---

Thanks for the PR!

Deployments, as required, will be available below:

• Frontend
• Vehicles
• Dops
• Policy
• Scheduler

Please create PRs in draft mode. Mark as ready to enable:

• Analysis Workflow

After merge, new images are promoted to:

• Merge Workflow

[sonarcloud]

Quality Gate passed for 'onroutebc_scheduler'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[sonarcloud]

Quality Gate passed for 'onroutebc_policy'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[sonarcloud]

Quality Gate passed for 'onroutebc dops'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[sonarcloud]

Quality Gate failed for 'onroutebc vehicles'

Failed conditions
63.2% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[sonarcloud]

Quality Gate failed for 'onroutebc frontend'

Failed conditions
28.4% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[krishnan-aot]

@zgong-gov Marking all of your comments as resolved as I'll create new tickets to correct the terminology in the frontend.