2018-02-20 11:22:17 +00:00
|
|
|
|
from flask import abort, flash, redirect, render_template, session, url_for
|
2017-11-01 16:02:05 +00:00
|
|
|
|
from flask_login import current_user
|
2018-02-20 11:22:17 +00:00
|
|
|
|
from markupsafe import Markup
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
|
2018-02-20 11:22:17 +00:00
|
|
|
|
from app.main import main
|
2023-07-12 12:09:44 -04:00
|
|
|
|
from app.models.organization import Organization
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
from app.models.service import Service
|
2023-08-25 08:57:24 -07:00
|
|
|
|
from app.models.user import InvitedOrgUser, InvitedUser, OrganizationUsers, User, Users
|
2016-02-29 17:35:21 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@main.route("/invitation/<token>")
|
|
|
|
|
|
def accept_invite(token):
|
2020-03-06 11:53:55 +00:00
|
|
|
|
invited_user = InvitedUser.from_token(token)
|
2016-03-10 15:03:21 +00:00
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
|
if (
|
|
|
|
|
|
not current_user.is_anonymous
|
|
|
|
|
|
and current_user.email_address.lower() != invited_user.email_address.lower()
|
|
|
|
|
|
):
|
|
|
|
|
|
message = Markup(
|
|
|
|
|
|
"""
|
2016-04-07 15:03:36 +01:00
|
|
|
|
You’re signed in as {}.
|
|
|
|
|
|
This invite is for another email address.
|
2023-08-08 16:19:17 -04:00
|
|
|
|
<a href={} class="usa-link">Sign out</a>
|
2020-05-29 17:25:11 +01:00
|
|
|
|
and click the link again to accept this invite.
|
2016-04-26 12:12:47 +01:00
|
|
|
|
""".format(
|
2023-08-25 09:12:23 -07:00
|
|
|
|
current_user.email_address, url_for("main.sign_out")
|
|
|
|
|
|
)
|
|
|
|
|
|
)
|
2016-04-26 12:12:47 +01:00
|
|
|
|
|
|
|
|
|
|
flash(message=message)
|
|
|
|
|
|
|
2016-03-30 16:16:34 +01:00
|
|
|
|
abort(403)
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
|
if invited_user.status == "cancelled":
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
service = Service.from_id(invited_user.service)
|
2023-08-25 09:12:23 -07:00
|
|
|
|
return render_template(
|
|
|
|
|
|
"views/cancelled-invitation.html",
|
|
|
|
|
|
from_user=invited_user.from_user.name,
|
|
|
|
|
|
service_name=service.name,
|
|
|
|
|
|
)
|
|
|
|
|
|
if invited_user.status == "accepted":
|
|
|
|
|
|
session.pop("invited_user_id", None)
|
2020-08-03 13:37:34 +01:00
|
|
|
|
service = Service.from_id(invited_user.service)
|
2023-08-25 09:12:23 -07:00
|
|
|
|
return redirect(
|
|
|
|
|
|
url_for("main.service_dashboard", service_id=invited_user.service)
|
|
|
|
|
|
)
|
2016-03-10 15:03:21 +00:00
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
|
session["invited_user_id"] = invited_user.id
|
2016-03-10 11:53:29 +00:00
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
existing_user = User.from_email_address_or_none(invited_user.email_address)
|
2016-03-15 15:32:30 +00:00
|
|
|
|
|
|
|
|
|
|
if existing_user:
|
2021-08-17 16:38:37 +01:00
|
|
|
|
existing_user.update_email_access_validated_at()
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
invited_user.accept_invite()
|
|
|
|
|
|
if existing_user in Users(invited_user.service):
|
2023-08-25 09:12:23 -07:00
|
|
|
|
return redirect(
|
|
|
|
|
|
url_for("main.service_dashboard", service_id=invited_user.service)
|
|
|
|
|
|
)
|
2016-03-15 15:32:30 +00:00
|
|
|
|
else:
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
service = Service.from_id(invited_user.service)
|
2021-05-25 15:58:33 +01:00
|
|
|
|
# if the service you're being added to can modify auth type, then check if we can do this;
|
|
|
|
|
|
# if the user is a Platform Admin, we silently leave this unchanged to prevent a security
|
|
|
|
|
|
# issue where someone could switch their auth type to something less secure
|
2023-08-25 09:12:23 -07:00
|
|
|
|
if (
|
|
|
|
|
|
service.has_permission("email_auth")
|
|
|
|
|
|
and not existing_user.platform_admin
|
|
|
|
|
|
):
|
|
|
|
|
|
if invited_user.auth_type == "email_auth" or (
|
2021-05-25 15:58:33 +01:00
|
|
|
|
# they have a phone number, we want them to start using it.
|
|
|
|
|
|
# if they dont have a mobile we just ignore that option of the invite
|
2023-08-25 09:12:23 -07:00
|
|
|
|
existing_user.mobile_number
|
|
|
|
|
|
and invited_user.auth_type == "sms_auth"
|
2021-05-25 15:58:33 +01:00
|
|
|
|
):
|
|
|
|
|
|
existing_user.update(auth_type=invited_user.auth_type)
|
2019-06-27 15:48:29 +01:00
|
|
|
|
existing_user.add_to_service(
|
|
|
|
|
|
service_id=invited_user.service,
|
|
|
|
|
|
permissions=invited_user.permissions,
|
|
|
|
|
|
folder_permissions=invited_user.folder_permissions,
|
2021-03-05 12:19:36 +00:00
|
|
|
|
invited_by_id=invited_user.from_user.id,
|
2019-06-27 15:48:29 +01:00
|
|
|
|
)
|
2023-08-25 09:12:23 -07:00
|
|
|
|
return redirect(url_for("main.service_dashboard", service_id=service.id))
|
2016-03-10 11:53:29 +00:00
|
|
|
|
else:
|
2023-08-25 09:12:23 -07:00
|
|
|
|
return redirect(url_for("main.register_from_invite"))
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
2023-07-12 12:09:44 -04:00
|
|
|
|
@main.route("/organization-invitation/<token>")
|
2018-02-19 16:53:29 +00:00
|
|
|
|
def accept_org_invite(token):
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
invited_org_user = InvitedOrgUser.from_token(token)
|
2020-03-06 11:53:55 +00:00
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
|
if (
|
|
|
|
|
|
not current_user.is_anonymous
|
|
|
|
|
|
and current_user.email_address.lower() != invited_org_user.email_address.lower()
|
|
|
|
|
|
):
|
|
|
|
|
|
message = Markup(
|
|
|
|
|
|
"""
|
2018-02-19 16:53:29 +00:00
|
|
|
|
You’re signed in as {}.
|
|
|
|
|
|
This invite is for another email address.
|
2023-08-08 16:19:17 -04:00
|
|
|
|
<a class="usa-link" href={}>Sign out</a>
|
2020-05-29 17:25:11 +01:00
|
|
|
|
and click the link again to accept this invite.
|
2018-02-19 16:53:29 +00:00
|
|
|
|
""".format(
|
2023-08-25 09:12:23 -07:00
|
|
|
|
current_user.email_address, url_for("main.sign_out")
|
|
|
|
|
|
)
|
|
|
|
|
|
)
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
|
|
|
|
|
flash(message=message)
|
|
|
|
|
|
|
|
|
|
|
|
abort(403)
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
|
if invited_org_user.status == "cancelled":
|
2023-07-12 12:09:44 -04:00
|
|
|
|
organization = Organization.from_id(invited_org_user.organization)
|
2023-08-25 09:12:23 -07:00
|
|
|
|
return render_template(
|
|
|
|
|
|
"views/cancelled-invitation.html",
|
|
|
|
|
|
from_user=invited_org_user.invited_by.name,
|
|
|
|
|
|
organization_name=organization.name,
|
|
|
|
|
|
)
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
|
if invited_org_user.status == "accepted":
|
|
|
|
|
|
session.pop("invited_org_user_id", None)
|
|
|
|
|
|
return redirect(
|
|
|
|
|
|
url_for("main.organization_dashboard", org_id=invited_org_user.organization)
|
|
|
|
|
|
)
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
|
session["invited_org_user_id"] = invited_org_user.id
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
existing_user = User.from_email_address_or_none(invited_org_user.email_address)
|
2023-07-12 12:09:44 -04:00
|
|
|
|
organization_users = OrganizationUsers(invited_org_user.organization)
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
|
|
|
|
|
if existing_user:
|
2021-08-17 16:38:37 +01:00
|
|
|
|
existing_user.update_email_access_validated_at()
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
invited_org_user.accept_invite()
|
2023-07-12 12:09:44 -04:00
|
|
|
|
if existing_user not in organization_users:
|
2023-08-25 09:12:23 -07:00
|
|
|
|
existing_user.add_to_organization(
|
|
|
|
|
|
organization_id=invited_org_user.organization
|
|
|
|
|
|
)
|
|
|
|
|
|
return redirect(
|
|
|
|
|
|
url_for("main.organization_dashboard", org_id=invited_org_user.organization)
|
|
|
|
|
|
)
|
2018-02-19 16:53:29 +00:00
|
|
|
|
else:
|
2023-08-25 09:12:23 -07:00
|
|
|
|
return redirect(url_for("main.register_from_org_invite"))
|