-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
55 changed files
with
858 additions
and
453 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,27 +1,86 @@ | ||
# UPGRADE the version of Metabase if you’re running 45 or below | ||
# PIDP/OneHealthID Documentation | ||
### Purpose: | ||
This document serves as a guide for new developers joining the project, providing them with insights into the project's technical environment, development workflow, and onboarding process. Its purpose is to facilitate a smooth transition for new team members by offering documentation of project processes and procedures, enabling them to quickly grasp project requirements, standards, and best practices. | ||
### Introduction: | ||
The OneHealth ID app serves as a crucial tool for doctors, nurses, and various healthcare professionals, streamlining their access to multiple services and logins. Within this application, users encounter different types of logins tailored to the operational structure of the BC government and its associated health authorities. | ||
### Technical Environment: | ||
**Backend:** .NET framework (6.0) & Entity Framework | ||
|
||
### 1. Download the latest version of Metabase image from docker hub | ||
**Frontend:** Nx workspace, Angular framework (v17), Angular material | ||
|
||
`docker pull metabase/metabase:latest` | ||
**Database:** Postgres SQL Npgsql ([Entity Framework Core provider for PostgreSQL](https://github.com/npgsql/efcore.pg)) | ||
|
||
### 2. Login to OpenShift | ||
`oc login <token>` | ||
**Containerization:** Docker (Docker Desktop is an application installed to provide an Interface to manage the containers) | ||
|
||
### 3. Switch to the desired project | ||
`oc project <namescapce>` | ||
**Version Control:** Git (GUI applications such as GitKraken, GH Desktop leverage) | ||
|
||
### 4. Tag the downloaded image | ||
**IDE:** Visual Studio or Visual Studio code | ||
|
||
`docker tag metabase/metabase:latest image-registry.apps.silver.devops.gov.bc.ca/<namespace>/metabase:<image-version>` | ||
**Database Management Tool:** DBeaver (for managing and interacting with the database) | ||
|
||
### 5. Login to docker and Push the image to the metabase imagestream in tools namespace | ||
**Hosting:** Red Hat OpenShift, deployed using GitHub Actions. | ||
|
||
`docker login -u 'oc whoami' -p <password> image-registry.apps.silver.devops.gov.bc.ca/<namespace>` | ||
### Codebase Overview: | ||
#### Architecture Overview: | ||
**Data:** This folder has the context class containing all configured tables using the Entity Model. Migration-related instances are stored in the subfolder named Migrations. Model configurations are managed in the configuration subfolder under the data folder. | ||
|
||
`docker push image-registry.apps.silver.devops.gov.bc.ca/<namespace>/metabase:<image-version>` | ||
**Extensions:** Extension Methods are organized in this folder, categorized based on class types. | ||
|
||
### 6. Point the latest image in metabase imagestream to the newly downlowded image | ||
**Features:** In this directory, all API-related code, including controllers, Command, and Query handler classes for each module, are maintained with subfolders for better organization. | ||
|
||
`oc tag metabase:v0.47.2 metabase:latest` | ||
**Infrastructure:** This folder encompasses commonly used services throughout the project, such as configuring services, injecting interfaces and dependent classes, integrating API calls using HTTP Client, and implementing Authorization services. | ||
|
||
**Logs:** Log files with extensions log & Json are stored in this folder, configured in the program class. | ||
|
||
**Models:** All model classes containing only properties for respective features/tables are created here. | ||
- Separate class files are maintained for each feature. | ||
- Table column names are mapped to class properties. | ||
- Constants are stored in the Lookups subfolder for each model. | ||
|
||
**Domain Events:** | ||
Configured under the DomainEvents subfolder for specific classes, these events are raised as needed. | ||
#### Code Organization: | ||
**PIDP Project:** This project serves as the interface for APIs interacting with the UI Application. All requests and responses occur within this project. Validation and authorization are performed using Keycloak, with token generation facilitated through JWT. | ||
|
||
**Design Pattern:** Following the CQRS pattern (Command and Query Responsibility Segregation) | ||
|
||
**Naming convention, file organization, and Comments:** | ||
- Follow the [C# identifier names rules and conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names) and [Angular style guide](https://angular.dev/style-guide) | ||
- Static files or logged files should be maintained in separate folders. | ||
- Only include comments when necessary to provide clarification or context for complex logic, prioritize self-explanatory code when possible. | ||
|
||
### Development Workflow: | ||
#### Ticket Management: | ||
Agile methodology is followed, with the team working during a 2-week sprint. | ||
- Sprint planning sessions determine the sprint size, included tickets, and priority items. | ||
- Prior to sprint planning, tickets are discussed, refined, and scored during a refinement session. | ||
- After a ticket is assigned in JIRA, developers review the ticket details, including requirements, acceptance criteria, and any relevant documentation. | ||
- Once the scope and understanding are clear, developers proceed to work on the ticket. | ||
#### Version Control: | ||
Developers utilize Git for version control to manage changes to the codebase. | ||
- Before starting work on a ticket, developers create a new branch from the develop branch, usually following a naming convention that includes the ticket number and a brief description. (Use all lower case for your branch names to avoid casing issues) | ||
- Throughout the development process, developers commit their changes to the local branch, providing meaningful commit messages to track progress and changes. | ||
- Periodically, developers push their local branches to the remote repository (e.g., GitHub) to collaborate with other team members and ensure backup of their work. | ||
- Once the ticket is completed and ready for review, developers create a Pull Request (PR) to merge their changes into the develop branch, triggering the code review process. | ||
#### Code Review Process: | ||
Once the developer considers the task completed, they create a Pull Request (PR) to merge their changes into the develop branch. | ||
- Other developers are assigned to review the PR. | ||
- Reviewers provide feedback through comments or during a call. | ||
- After addressing any feedback and ensuring the code meets the projects standards, the PR is approved. | ||
- Upon approval, the changes are merged into the develop branch. | ||
- Developers may add the `Ready For Review` label on the PR when codes changes are awaiting review. If the PR is blocked or is not production code, the `DO NOT MERGE` label is added to the PR. | ||
#### Deployment Process: | ||
- After merging into the develop branch, changes are deployed to the test environment for further testing. | ||
- Upon successful testing, changes are deployed to the production environment. | ||
### Setup Instructions: | ||
|
||
https://github.com/bcgov/moh-pidp/tree/develop/workspace#readme | ||
|
||
https://github.com/bcgov/moh-pidp/blob/develop/backend/webapi/README.md | ||
|
||
### My Onboarding Process: | ||
- The Scrum Master provided a walkthrough of the project. | ||
- I was introduced to the project's version control system and given access to the code repository for collaboration. | ||
- As part of the onboarding process, I familiarized myself with the project's Agile methodology, sprint planning, and iterative development practices. | ||
- The development team has provided valuable feedback and thorough reviews on Pull requests, enhancing my understanding of the codebase and refining my skills. | ||
- I participated in team meetings, stand-ups, and retrospective sessions to gain insights into project progress and contribute to continuous improvement efforts. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
98 changes: 98 additions & 0 deletions
98
...end/webapi.tests/Features/CommonEventHandlers/UpdateKeycloakAfterCollegeLicenceUpdated.cs
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,98 @@ | ||
namespace PidpTests.Features.CommonEventHandlers; | ||
|
||
using FakeItEasy; | ||
using MassTransit; | ||
using System.Text.Json; | ||
using Xunit; | ||
|
||
using Pidp.Features.CommonHandlers; | ||
using static Pidp.Features.CommonHandlers.UpdateKeycloakAttributesConsumer; | ||
using Pidp.Infrastructure.HttpClients.Plr; | ||
using Pidp.Models; | ||
using Pidp.Models.DomainEvents; | ||
using Pidp.Models.Lookups; | ||
using PidpTests.TestingExtensions; | ||
|
||
public class UpdateKeycloakAfterCollegeLicenceUpdatedTests : InMemoryDbTest | ||
{ | ||
[Theory] | ||
[MemberData(nameof(RecordData))] | ||
public async void UpdateKeycloakAfterCollegeLicenceUpdated_OneLicence_BusPushedWithMatchingJson(IEnumerable<PlrRecord> expectedRecords) | ||
{ | ||
var party = this.TestDb.HasAParty(party => | ||
{ | ||
party.Cpn = "aCpnn"; | ||
party.LicenceDeclaration = new PartyLicenceDeclaration | ||
{ | ||
LicenceNumber = "12345", | ||
CollegeCode = CollegeCode.Pharmacists | ||
}; | ||
}); | ||
|
||
List<UpdateKeycloakAttributes> capturedMessages = new(); | ||
var bus = A.Fake<IBus>(); | ||
A.CallTo(() => bus.Publish(A<UpdateKeycloakAttributes>._, A<CancellationToken>._)) | ||
.Invokes(i => capturedMessages.Add(i.GetArgument<UpdateKeycloakAttributes>(0)!)); | ||
var plrClient = A.Fake<IPlrClient>(); | ||
A.CallTo(() => plrClient.GetRecordsAsync(A<string>._)).Returns(expectedRecords); | ||
|
||
var consumer = this.MockDependenciesFor<UpdateKeycloakAfterCollegeLicenceUpdated>(plrClient, bus); | ||
|
||
await consumer.Handle(new CollegeLicenceUpdated(party.Id), new CancellationToken()); | ||
|
||
Assert.Single(capturedMessages); | ||
|
||
var message = capturedMessages.Single(); | ||
Assert.Equal(party.PrimaryUserId, message.UserId); | ||
Assert.Single(message.Attributes); | ||
|
||
var attribute = message.Attributes.Single(); | ||
Assert.Equal("college_licence_info", attribute.Key); | ||
Assert.Single(attribute.Value); | ||
|
||
var busRecords = JsonSerializer.Deserialize<IEnumerable<PlrRecord>>(attribute.Value[0], new JsonSerializerOptions() { PropertyNamingPolicy = JsonNamingPolicy.CamelCase })!; | ||
|
||
AssertThat.CollectionsAreEquivalent(expectedRecords, busRecords, (expected, bus) => | ||
expected.CollegeId == bus.CollegeId | ||
&& expected.MspId == bus.MspId | ||
&& expected.ProviderRoleType == bus.ProviderRoleType | ||
&& expected.StatusCode == bus.StatusCode | ||
&& expected.StatusReasonCode == bus.StatusReasonCode | ||
); | ||
} | ||
|
||
public static IEnumerable<object[]> RecordData() | ||
{ | ||
yield return new object[] { new[] | ||
{ | ||
new PlrRecord | ||
{ | ||
CollegeId = "12345", | ||
MspId = "Msp123", | ||
ProviderRoleType = "RoleType", | ||
StatusCode = "ACTIVE", | ||
StatusReasonCode = "GS" | ||
} | ||
}}; | ||
|
||
yield return new object[] { new[] | ||
{ | ||
new PlrRecord | ||
{ | ||
CollegeId = "12345", | ||
MspId = "Msp123", | ||
ProviderRoleType = "RoleType", | ||
StatusCode = "ACTIVE", | ||
StatusReasonCode = "GS" | ||
}, | ||
new PlrRecord | ||
{ | ||
CollegeId = "54321", | ||
MspId = "Msp222", | ||
ProviderRoleType = "RoleType2", | ||
StatusCode = "ACTIVE??", | ||
StatusReasonCode = "GS??" | ||
} | ||
}}; | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.