Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invited User: Force new user to choose to accept terms and conditions #1238

Open
kasugaijin opened this issue Dec 11, 2024 · 6 comments
Open
Assignees

Comments

@kasugaijin
Copy link
Collaborator

kasugaijin commented Dec 11, 2024

SuperAdmin have the ability to invite staff and fosterers to the application. These invite flows create a new User. We have a boolean on user tos_agreement that we use to track if the user accepts, or not, the terms and conditions and privacy policy. This value is nil when a user is invited.

We want to make sure that invited users (staff, fosterers) have to check true for these when they first log into the application.

I think the simplest approach is to add a filter on ApplicationController - we check the user's tos_agreement and if it is nil, or false we boot them to a page that asks them to agree to the T&C etc., and only when they do this, can they access other routes.

You will also need to create a new controller to show this new page, and accept the submission of the response (to update the tos_agreement attribute).

@kasugaijin kasugaijin added the Ready Make a comment to get assigned. label Dec 11, 2024
@mononoken mononoken self-assigned this Dec 11, 2024
@mononoken
Copy link
Collaborator

@kasugaijin I'll work on this one since I've got it fresh on my mind from the meeting 🙂

@kasugaijin
Copy link
Collaborator Author

@mononoken thanks Ken!

@kasugaijin
Copy link
Collaborator Author

One small consideration we need to make is in the org create service we actually mark the tos_agreement on that user we create as true. So we might want to remove that so they actually have to go through this flow as well.

@mononoken
Copy link
Collaborator

Good thinking

@mononoken
Copy link
Collaborator

mononoken commented Dec 12, 2024

Acceptance Criteria

  • Add an acceptance criteria page and route
  • Require all users to accept TOS before interacting with private pages and routes
    • Adopters
    • Fosterers
    • Staff
    • Staff admin
  • If invited, user should be prompted to accept TOS when setting their password
  • Make sure the original org user also has to accept TOS

@kasugaijin
Copy link
Collaborator Author

kasugaijin commented Dec 12, 2024

Acceptance Criteria

  • Add an acceptance criteria page and route

  • Require all users to accept TOS before interacting with private pages and routes

    • Adopters
    • Fosterers
    • Staff
    • Staff admin
  • If invited, user should be prompted to accept TOS when setting their password

  • Make sure the original org user also has to accept TOS

Looks good! Adopters cannot sign up without checking the TOS box on the sign up form, so they 'should' be acounted for.

For invited users, I like the idea of asking to accept ToS when they reset their password. It's a more efficient approach than the ApplicationController solution above, providing they cannot access the app manually changing the URL (I don't think they can as they should not be authenticated at this point) and the user context should be set using the URL token from Devise, so we can check their tos_agreement if necessary.

The only exception to handle is the user we create when we create an Org. We create a password and send them an email asking them to change it, but don't enforce this like we do for the invitees. One option is that we refactor how we do this in the Organizations::CreateService and invite them (like we do in the inivitations controller), so they are forced to set a password (and also accept ToS)? Happy to discuss options here.

@kasugaijin kasugaijin removed the Ready Make a comment to get assigned. label Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants