Mealplanner‐SocialLogin - CivicTechFredericton/mealplanner GitHub Wiki

Social Login Workflow

Description:

Add Google and Facebook login support alongside the existing standard login (username/password), allowing users the flexibility to access the Mealplanner application through their preferred login method.

Use Cases:

Use Case ID: UC-001

  • Use Case Name: Register New User
  • Actor(s): Admin
  • Description: This use case describes the steps an admin takes to register a new user with their emailID to the Mealplanner application.
  • Preconditions: The admin must be logged in to the Mealplanner Admin application.
  • Main Flow: Admin UI
    1. Admin clicks on "Register User" button.
    2. System displays a form to input user details - name, emailID, password.
    3. Admin fills out the form and clicks "Register".
    4. System validates inputs and registers the user to the application with the status set to “Pending” and role defaults to "Client".
    5. Once user registered, the table should display a user's status(pending, active, disabled/in-active). If active, it should display user's active status with which social login(s).
    6. A page reflects the last login of a user.
  • Postconditions:
    • A new user is registered with their emailID.
    • Registered user's data should be viewed in the Users page of Admin UI.
    • The user’s status is set to “Pending” by default to await activation in the application.
    • Admin should have access to edit/delete the users anytime.
    • Registered users should be log-in to the application either with standard login or Social Login.
    • Registered users can create meal-plans with their status being "Pending".
  • Alternate Flow:
    • A1: System displays appropriate error messages for missing/invalid inputs.
    • A2: If email already exists in the system, display a message: "User/Email already exists".
  • Notes:
    • Status: Pending, Active, InActive
      • Pending: When the user is registered to the system
      • Active: When the user logs-in to the application either via standard login or social login.
      • InActive: When the user leaves the organization (ie., Greener Village).
    • Role: Client, Meal Designer, Admin
      • Client: When the user is registered to the system by default 'Client'
      • Meal Designer / Admin: Admin has access to change the role of the user.

Use Case ID: UC-002

  • Use Case Name: Email Bulk Upload
  • Actor(s): Admin
  • Description: This use case describes the steps an admin takes to bulk-upload clients to the Mealplanner application
  • Preconditions: The admin must be logged in to the Mealplanner Admin application.
  • Main Flow: Admin UI
    1. Admin clicks on "Bulk Upload" button, Bulk Upload modal will be popped-up.
    2. Bulk Upload modal displays a excel or csv template for admin to download and follow that template to bulk-upload emails to the application.
    3. Admin fills out the excel or csv file with the corresponding client emails and their full name in the sheet.
    4. Admin uploads the filled sheet to the Bulk Upload modal.
    5. System validates inputs (full name and email) and verifies email in the application:
      • If the emailID exists in app.person, No update required. Temporarily store the emailID in a list and show the list, saying emails already exist.
      • If the emailID doesn't exist in app.person, a record should be created in this Person table with status "Pending", role "Client" and app.private.account record should not be created.
  • Postconditions:
    • New users are registered with their emailID to the application.
    • Bulk Uploaded client data should be viewed in the Users page of Admin UI.
    • The user’s status are set to “Pending” by default to await activation in the application.
    • Admin should have access to edit/delete the users anytime.
    • Users should be log-in to the application either with standard login or Social Login.
    • Registered users can create meal-plans with their status being "Pending".
  • Alternate Flow:
    • A1: System displays appropriate error messages for missing/invalid inputs (Full Name, EmailID).
    • A2: No Frontend and wiring implementation required. Write a script at backend with the 700 emailIDs shared by Greener Village.
  • Notes:
    • Q/A: When to create a record in app.private.account when the user is created during email bulk-upload?
    • A: No password is created for bulk upload of email case because we assume it is only going to be social login.

Use Case ID: UC-003

  • Use Case Name: Login with Google
  • Actor(s): User (Client, Admin, Meal Designer)
  • Description: This use case describes the steps a user takes to log in to the Mealplanner application using their registered Google account.
  • Preconditions:
    • The user must be registered by an admin using their emailID.
    • Only new user's initial status in app.person table is "Pending".
    • Existing user's log-in for the 1st time after app release will have status to "Pending" in app.person.
  • Main Flow - Meal Planner UI:
    1. User clicks the "Continue with Google" button on the login page.
    2. The system initiates Google OAuth and authenticates the user's email.
    3. The backend verifies if the email exists in app.person table.
    4. If valid and with successful authentication access is granted, and the user is redirected to the "Terms & Conditions" page.
    5. User status update during Google login: a. If the user's current status is "Pending", the system updates their status to "Active". b. If the user is already Active, no change to status occurs.
    6. User's log-in timestamp and auth_channel will be recorded in app.session table for every login.
    7. The user is granted access to the Mealplanner application.
  • Postconditions:
    • The user successfully logs in to the Mealplanner application using Google authentication.
  • Alternate Flow: A1: If the email is not registered display an error: "This email is not authorized for Google login."
  • Notes:
    1. Q/A: A registered user can log in only through the assigned login method.
    2. A: The same user can login with Google or Facebook or password.

Use Case ID: UC-004

  • Use Case Name: Login with Facebook
  • Actor(s): User (Client, Admin, Meal Designer)
  • Description: This use case describes the steps a user takes to log in to the Mealplanner application using their registered Facebook account.
  • Preconditions:
    • The user must be registered by an admin using their emailID.
    • Only new user's initial status in app.person table is "Pending".
    • Existing user's log-in for the 1st time after app release will have status to "Pending" in app.person.
  • Main Flow - Meal Planner UI:
    1. User clicks the "Continue with Facebook" button on the login page.
    2. The system initiates authenticates for the user's emailID.
    3. The backend verifies if the email exists in app.person table.
    4. If valid and with successful authentication access is granted, and the user is redirected to the "Terms & Conditions" page.
    5. User status update during Google login: a. If the user's current status is "Pending", the system updates their status to "Active". b. If the user is already Active, no change to status occurs.
    6. The user is granted access to the Mealplanner application.
  • Postconditions:
    • The user successfully logs in to the Mealplanner application using Facebook authentication.
  • Alternate Flow: A1: If the email is not registered display an error: "This email is not authorized for Facebook login."
  • Notes:
    • Q/A: A registered user can log in only through the assigned login method.
    • A: The same user can login with Google or Facebook or password.

Use Case ID: UC-005

  • Use Case Name: Meal Planner Login
  • Actor(s): User (Client, Admin, Meal Designer)
  • Description: This use case describes the backend operations to be performed once the new/existing user log-in to application
  • Preconditions: The user must be registered with their emailID to access the application.
  • Main Flow: Meal Planner UI
    1. New/Existing user should log-in to the application either with standard login or social login.
    2. If the user logs-in with social login, record the details in the table app.social_login for the following details:
      • provider: (Google or Facebook).
      • provider_user_id: "ans234shdsx" (Created by provider from id token)
      • access_token: (expires in 1 hour or so).
      • refresh_token: (expires in 6 months).
      • id_token: unique jwt token that has user info.
      • token_response:jsonb: Check whether this field has fullName and email. If not, do another request to get and store them.
      • is_active:boolean: allows the system to temporarily deactivate a user's social login (for some valid reason) without permanently deleting the record. Eg.,In case Facebook login gets hacked this would give the admin the option to just disable that social login alone and keep the user active in the person table.
    3. Post creation of record in app.social_login, check if the user status is "Pending" in app.person table, then update the status to "Active".
    4. If the user logs-in with standard login and status is Active, skip to step 5 else set status to "Active" in app.person table.
    5. Create the record in Session table that records the timestamp and auth_channel - (Google, Facebook, Password) of that person_id.
  • Postconditions:
    • A user set to Active along with recording the log in Sessions table.
  • Notes:
    • Q/A:
      • The above social_login creation is for first time users of social login. For frequent social login, does the record to be updated?
      • A: When the existing user logs in after we push the latest release, the timestamp is derived based on the request and response when the user actually logs in and that timestamp is stored in the app.session table as a record.
      • A: If the same user should login with Gmail and Facebook, create a 2 separate records in app.social_login table one for Google and another for Facebook login.