Skip to content

Commit

Permalink
chore: updates login instructions (removes references to creation_req…
Browse files Browse the repository at this point in the history
…uest table) (#2238)
  • Loading branch information
emi-hi authored Sep 4, 2024
1 parent 200672e commit 13d8c4c
Showing 1 changed file with 66 additions and 17 deletions.
83 changes: 66 additions & 17 deletions developer-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,10 +13,10 @@ zeva_minio_1
zeva_rabbitmq_1
zeva_mailslurper_1


## Running on an M1 Macbook

M1 macbooks run on a different chip than intel macbooks and pcs, which can cause problems with Docker. Currently it should be fine for either but if there's an issue in the future we may need to specify the source of some images.

## Code style and Linting

We use [Eslint](https://eslint.org/) to lint the app's code and [Prettier](https://prettier.io/) to format it. The following npm scripts can be used to trigger linting and formatting:
Expand Down Expand Up @@ -56,7 +56,61 @@ This will only run tests that match the test name pattern you provide.

The application requires users to be authenticated using IDIR or BCeID.

When developing locally, you may want to assign different users to different profiles, for example, have a 'government' profile as well as a 'supplier' profile. Your IDIR should be used for your government account and your BCeID account should be used for supplier accounts. You can insert your own user_profile objects into the database according to which identity provider you are loggin in with. The user_creation_request table is used to map external users to Zeva users. A user_creation_request entry will have to exist with your keycloak_email and external_username in order to map your IDIR/BCeID account within the system. You can also update the user_role's for your user by adding to the cross table between user_profile and role (user_role). Please reach out to a team member if you have any questions.
When developing locally, you may want to assign different users to different profiles, for example, have a 'government' profile as well as a 'supplier' profile. Your IDIR should be used for your government account and your BCeID account should be used for supplier accounts. You can insert your own user_profile objects into the database.

### Insert your first user

to add your idir account:

in a terminal window:

```
docker-compose exec db psql -U postgres zeva
INSERT into user_profile (username, keycloak_email, is_active, create_user) VALUES ('your username', '[email protected]', 't', 'your name');
```

the above code will create your new user in the system with just the required fields. For the purpose of this example your new user has an id of 123. If your email matches your idir email, the app should automatically map your profile when you first log into the system.

If your keycloak_user_id does not get filled/mapped, you can fill in the keycloak_user_id field manually by printing out your user token. To do this, open this file backend/api/keycloak_authentication.py and add a print statement after the user token is created, I added it on line 95 as so:

```
print("********")
print(user_token['preferred_username'])
print("********")
```

then, log into keycloak then look for the printed text in your backend container. It will look something like

```
********
df34439shgf5675343df57632e@idir
********
```

Copy the text between asterisks and update your user_profile record to use this as value for the keycloak_user_id field. You should now also add an organization_id to your user. For idir users, the organization should be Government of British Columbia, check the organization table for the id and fill in your user_profile record

```
select id from organization where organization_name = 'Government of British Columbia';
update user_profile set organization_id = 1 where user_id = 123;
```

You will not be able to see much yet as your user does not have roles, so roles need to be added using our join table, user_role.

To find the government roles use this code:

```
select * from role where is_government_role = True;
```

Pick a role that you want to be. Administrator is recommended because then you can update your roles from within the app, for the purpose of this that has an id of 1. Analysts can recommend approvals for vehicles, sales, transfers, model year reports, etc, and Directors can issue credits and approve those things so if you are testing any of those you will need those permissions.

```
insert into user_role (role_id, user_profile_id, create_user) values (1, 123, 'your name');
```

Now you should be able to log in as an idir user.

To log in as bceid, you need a developmental bceid account. We have several set up on the team, so reach out to the team for the login information.

## Code Changes

Expand Down Expand Up @@ -84,14 +138,6 @@ Here are a few examples of branch names:
to view the database via docker use:
docker-compose exec db psql -U postgres zeva

### To insert your first idir user

INSERT INTO user_profile (
create_timestamp, update_timestamp, username, first_name, last_name, is_active, keycloak_email, display_name, organization_id, create_user)
VALUES (
NOW(), NOW(), 'idirusername', 'Firstname', 'Lastname', TRUE,
'[email protected]', 'displayname', 1, 'SYSTEM');

#### Copy down Test/Prod data from Openshift

Copy test/prod data into your local database using the /openshift/import-data.sh script
Expand All @@ -114,15 +160,18 @@ if theres permission issues with lchown while running the script, run the script

if there's still issues, it might be a corrupted .tar file. See if someone else can export it and put it in the openshift folder. Then comment out the import script up until the tar gets copied into a local container. Then try running it.

Another issue that has come up was fixed by removing a lock in the database.
Another issue that has come up was fixed by removing a lock in the database.
Locks were removed by using this statement:

```
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE pid <> pg_backend_pid();
this may be enough to run the script but also the public schema can be deleted and recreated
FROM pg_stat_activity
WHERE pid <> pg_backend_pid();
```

this may be enough to run the script but also the public schema can be deleted and recreated
DROP SCHEMA public cascade;

CREATE SCHEMA public AUTHORIZATION postgres;

then the script can be run.

then the script can be run.

0 comments on commit 13d8c4c

Please sign in to comment.