Skip to content

Notes on T-350

“IV Admin can generate an invitation to the vetportal”

This will need to be broken down in to multiple steps

  1. Method to view existing ‘employee’ users (or people intended to be users)
  2. Method to view status of any existing invitations
  3. Method to generate an invitation email to a specific user
  4. Invitation will need to be tracked (when sent, check if email was opened, check if invitation link was clicked - potentially invalidate the link after clicking or X days).

Will need to bring in ‘api’ stuff and some repository stuff from other branch as basis (api token migration, basic app blade api_token integration)

There is already an ‘employees’ page (point 1 above), to save a bit of time we’ll base an invitation process in from the specific employee view screen.

/indevets/employees/37180386/edit

Thinking about an ‘invitation’ vue component that can be embedded on the right side of that screen for now.

Show a status - not invited, invited, clicked, registered.

We’ll connect the user account to the employee record.

May need to have a user_role table with multiple roles - diffferent roles per location perhaps?

api endpoints… GET /api/invitation - get list of all invitations GET /api/invitation/for/ - get list of all invitations for specific employeeid PUT /api/invitation/ - create new invitation POST /api/invitation/ - update invitation DELETE /api/invitation/ - delete invitation GET /api/invitation/ - get specific invitation info (may not be needed) POST /api/invitation//register - register the user - update invitation status

Tech Needs

  • api_token migration/template/vue/ajax setup
  • migration to add ‘user_id’ to employees table.
  • migration for ‘invitation’
  • new role - ROLE_EMPLOYEE?
  • event sourcing package to record events (not using projectors right now, but storable events?)
  • mailable message

Invitation migration

  • UUID?
  • sender_id
  • employee_id
  • dates
  • body of text?
  • invitation code
  • expiration date
  • status
  • metadata (blob of activity - click/views/etc?)

testing

  • hit api to generate invite
  • prevent duplicate invites within X minutes? (nah)
  • test click endpoint
  • change system time - check for expired invitation code

Misc

When a user logs in, we’ll need to check ‘role’. If they’re an employee, we’ll need to load the employee information - essentially this will be a related ‘profile’ of their data.

“POST /api/invitation//register” toss up here between ‘post’ - updating - and ‘put’ - creating we’re doing both - updating the invitation, but also creating a new user record. should be done in one step from the point of view of the api consumer though.

changing ‘accepted_tos’ from boolean to integer to hold unix timestamp Migration hitting.. Datatype mismatch: 7 ERROR: column “accepted_tos” cannot be cast automatically to type integer
HINT: You might need to specify “USING accepted_tos::integer”.
This will be dropped and readded - accepted_tos isn’t being used right now so this will not affect anything.

Initial mockups did not ask for first/last names current db has these marked as not null/required. will have invitation service pull these from employee record related from invitation and populate in user record to start with - users can change later.

invitation expiration - this is calculated and saved, using a constant from the model.

Invitation::EXPIRATION_MINUTES = 60 * 6;

Could possibly be a config var with a getExpirationMinutesValue() instead, but constant felt more discoverable at the moment.

Note

api_token work was rolled back

Testing

Note you may need to modify config/app.php 

'env' => "testing", //env('APP_ENV', 'production'),

The APP_ENV is built in to docker image and not overrideable via ‘env’ changes.

This can impact running tests, and some tests may not work without ‘testing’ environment flag set.

UPDATES

Oct 2020 - Expiration time was updated to 30 days.

Oct 2020 - Modifying process to allow for user creation up front with associated user_id on the invitation. When accepting invitation, user will be activated and updated with new user info and password, vs new user record created.

This will allow for user mgt to flow more cohesively from the user mgr - user will have specific type/role, and associate info/history related to ‘employee/dr’ type. Will need a reinvite here as well as from the ‘employee’ page.

Old process of direct invite of existing dr record will still exist, but be only exist for the remaining existing dr records.
New doctor records will be created as ‘user-first’ vs ‘dr first’.

Flow

User ‘invite’ screen will take first/last/email and create a user record and assoiated employee record, then send invite with user_id on the invitation record.

When ‘accepting’ the invite, if the user_id record is on the invitation, the user info will be updated with the user-supplied info.

Alternative flow/idea for existing employee records 1

We just create a user record for them, then send them manual email instructions telling them they’ll get a link to create a new password, then also initiate a ‘reset password’ process for each.

Alternative flow/idea for existing employee records 2

Modify the existing ‘invite’ process to create related ‘user’ record for each person, then carry on as normal with the original ‘flow’ above.