2018-01-11 22:36:13 +00:00
|
|
|
import pytest
|
2018-02-20 11:22:17 +00:00
|
|
|
|
2021-03-08 12:51:35 +00:00
|
|
|
from app.models.user import AnonymousUser, InvitedOrgUser, InvitedUser, User
|
2021-07-15 11:57:33 +01:00
|
|
|
from tests.conftest import SERVICE_ONE_ID, USER_ONE_ID
|
2019-07-01 15:22:08 +01:00
|
|
|
|
|
|
|
|
|
2021-05-12 14:57:21 +01:00
|
|
|
def test_anonymous_user(notify_admin):
|
2019-07-01 15:22:08 +01:00
|
|
|
assert AnonymousUser().is_authenticated is False
|
2023-07-12 12:09:44 -04:00
|
|
|
assert AnonymousUser().default_organization.name is None
|
|
|
|
|
assert AnonymousUser().default_organization.domains == []
|
|
|
|
|
assert AnonymousUser().default_organization.organization_type is None
|
2016-01-23 23:14:50 +00:00
|
|
|
|
|
|
|
|
|
2021-05-12 14:57:21 +01:00
|
|
|
def test_user(notify_admin):
|
2023-08-25 09:12:23 -07:00
|
|
|
user_data = {
|
|
|
|
|
"id": 1,
|
|
|
|
|
"name": "Test User",
|
|
|
|
|
"email_address": "test@user.gsa.gov",
|
|
|
|
|
"mobile_number": "+12021231234",
|
|
|
|
|
"state": "pending",
|
2024-08-23 12:59:00 -07:00
|
|
|
"preferred_timezone": "America/Chicago",
|
2023-08-25 09:12:23 -07:00
|
|
|
"failed_login_count": 0,
|
|
|
|
|
"platform_admin": False,
|
|
|
|
|
}
|
2016-01-23 23:14:50 +00:00
|
|
|
user = User(user_data)
|
|
|
|
|
|
|
|
|
|
assert user.id == 1
|
2023-08-25 09:12:23 -07:00
|
|
|
assert user.name == "Test User"
|
|
|
|
|
assert user.email_address == "test@user.gsa.gov"
|
|
|
|
|
assert user.mobile_number == "+12021231234"
|
|
|
|
|
assert user.state == "pending"
|
2016-01-23 23:14:50 +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
|
|
|
# user has ten failed logins before being locked
|
2021-03-19 14:11:37 +00:00
|
|
|
assert user.MAX_FAILED_LOGIN_COUNT == 10
|
2016-01-23 23:14:50 +00:00
|
|
|
assert user.failed_login_count == 0
|
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
|
|
|
assert user.locked is False
|
2016-01-23 23:14:50 +00:00
|
|
|
|
|
|
|
|
# set failed logins to threshold
|
2021-03-19 14:11:37 +00:00
|
|
|
user.failed_login_count = 10
|
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
|
|
|
assert user.locked is True
|
2018-01-11 22:36:13 +00:00
|
|
|
|
|
|
|
|
with pytest.raises(TypeError):
|
2023-08-25 09:12:23 -07:00
|
|
|
user.has_permissions("to_do_bad_things")
|
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
|
|
|
|
|
|
|
|
|
2021-05-12 14:57:21 +01:00
|
|
|
def test_activate_user(notify_admin, api_user_pending, mock_activate_user):
|
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
|
|
|
assert User(api_user_pending).activate() == User(api_user_pending)
|
2023-08-25 09:12:23 -07:00
|
|
|
mock_activate_user.assert_called_once_with(api_user_pending["id"])
|
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
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
def test_activate_user_already_active(
|
|
|
|
|
notify_admin, api_user_active, mock_activate_user
|
|
|
|
|
):
|
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
|
|
|
assert User(api_user_active).activate() == User(api_user_active)
|
|
|
|
|
assert mock_activate_user.called is False
|
2019-06-13 19:00:17 +01:00
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
@pytest.mark.parametrize(
|
2023-09-08 17:58:06 -04:00
|
|
|
("is_platform_admin", "value_in_session", "expected_result"),
|
2023-08-25 09:12:23 -07:00
|
|
|
[
|
|
|
|
|
(True, True, False),
|
|
|
|
|
(True, False, True),
|
|
|
|
|
(True, None, True),
|
|
|
|
|
(False, True, False),
|
|
|
|
|
(False, False, False),
|
|
|
|
|
(False, None, False),
|
|
|
|
|
],
|
|
|
|
|
)
|
2022-01-04 18:33:23 +00:00
|
|
|
def test_platform_admin_flag_set_in_session(
|
|
|
|
|
client_request, mocker, is_platform_admin, value_in_session, expected_result
|
|
|
|
|
):
|
2019-06-13 19:00:17 +01:00
|
|
|
session_dict = {}
|
|
|
|
|
if value_in_session is not None:
|
2023-08-25 09:12:23 -07:00
|
|
|
session_dict["disable_platform_admin_view"] = value_in_session
|
2019-06-13 19:00:17 +01:00
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
mocker.patch.dict("app.models.user.session", values=session_dict, clear=True)
|
2019-06-13 19:00:17 +01:00
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
assert (
|
|
|
|
|
User({"id": 1, "platform_admin": is_platform_admin}).platform_admin
|
|
|
|
|
== expected_result
|
|
|
|
|
)
|
2020-12-09 10:54:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_has_live_services(
|
|
|
|
|
client_request,
|
2023-07-12 12:09:44 -04:00
|
|
|
mock_get_non_empty_organizations_and_services_for_user,
|
2020-12-09 10:54:07 +00:00
|
|
|
fake_uuid,
|
|
|
|
|
):
|
2023-08-25 09:12:23 -07:00
|
|
|
user = User(
|
|
|
|
|
{
|
|
|
|
|
"id": fake_uuid,
|
|
|
|
|
"platform_admin": False,
|
|
|
|
|
}
|
|
|
|
|
)
|
2020-12-09 10:54:07 +00:00
|
|
|
assert len(user.live_services) == 5
|
|
|
|
|
for service in user.live_services:
|
|
|
|
|
assert service.live
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_has_live_services_when_there_are_no_services(
|
|
|
|
|
client_request,
|
2023-07-12 12:09:44 -04:00
|
|
|
mock_get_organizations_and_services_for_user,
|
2020-12-09 10:54:07 +00:00
|
|
|
fake_uuid,
|
|
|
|
|
):
|
2023-08-25 09:12:23 -07:00
|
|
|
assert (
|
|
|
|
|
User(
|
|
|
|
|
{
|
|
|
|
|
"id": fake_uuid,
|
|
|
|
|
"platform_admin": False,
|
|
|
|
|
}
|
|
|
|
|
).live_services
|
|
|
|
|
== []
|
|
|
|
|
)
|
2020-12-09 10:54:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_has_live_services_when_service_is_not_live(
|
|
|
|
|
client_request,
|
2023-07-12 12:09:44 -04:00
|
|
|
mock_get_empty_organizations_and_one_service_for_user,
|
2020-12-09 10:54:07 +00:00
|
|
|
fake_uuid,
|
|
|
|
|
):
|
2023-08-25 09:12:23 -07:00
|
|
|
assert (
|
|
|
|
|
User(
|
|
|
|
|
{
|
|
|
|
|
"id": fake_uuid,
|
|
|
|
|
"platform_admin": False,
|
|
|
|
|
}
|
|
|
|
|
).live_services
|
|
|
|
|
== []
|
|
|
|
|
)
|
store invited org user ids in session
first of a two step process to remove invited user objects from the
session. we're removing them because they're of variable size, and with
a lot of folder permissions they can cause the session to exceed the 4kb
cookie size limit and not save properly.
this commit looks at invited org users only.
in this step, start saving the invited org user's id to the
session alongside the session object. Then, if the invited_org_user_id
is present in the next step of the invite flow, fetch the user object
from the API instead of from the session. If it's not present (due to a
session set by an older instance of the admin app), then just use the
old code to get the entire object out of the session.
For invites where the user is small enough to persist to the cookie,
this will still save both the old and the new way, but will always make
an extra check to the API, I think this minor performance hit is totally
fine. For invites where the user is too big to persist, they'll still
fail for now, and will need to wait until the next PR comes along and
stops saving the large invited user object to the session entirely.
2021-03-08 10:01:12 +00:00
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
def test_invited_user_from_session_uses_id(
|
|
|
|
|
client_request, mocker, mock_get_invited_user_by_id
|
|
|
|
|
):
|
|
|
|
|
session_dict = {"invited_user_id": USER_ONE_ID}
|
|
|
|
|
mocker.patch.dict("app.models.user.session", values=session_dict, clear=True)
|
2021-03-08 12:51:35 +00:00
|
|
|
|
|
|
|
|
assert InvitedUser.from_session().id == USER_ONE_ID
|
|
|
|
|
|
2021-03-12 15:57:46 +00:00
|
|
|
mock_get_invited_user_by_id.assert_called_once_with(USER_ONE_ID)
|
2021-03-08 12:51:35 +00:00
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
def test_invited_user_from_session_returns_none_if_nothing_present(
|
|
|
|
|
client_request, mocker
|
|
|
|
|
):
|
|
|
|
|
mocker.patch.dict("app.models.user.session", values={}, clear=True)
|
2021-03-08 12:51:35 +00:00
|
|
|
assert InvitedUser.from_session() is None
|
|
|
|
|
|
|
|
|
|
|
2022-01-04 18:33:23 +00:00
|
|
|
def test_invited_org_user_from_session_uses_id(
|
|
|
|
|
client_request, mocker, mock_get_invited_org_user_by_id, sample_org_invite
|
|
|
|
|
):
|
2023-08-25 09:12:23 -07:00
|
|
|
session_dict = {"invited_org_user_id": sample_org_invite["id"]}
|
|
|
|
|
mocker.patch.dict("app.models.user.session", values=session_dict, clear=True)
|
store invited org user ids in session
first of a two step process to remove invited user objects from the
session. we're removing them because they're of variable size, and with
a lot of folder permissions they can cause the session to exceed the 4kb
cookie size limit and not save properly.
this commit looks at invited org users only.
in this step, start saving the invited org user's id to the
session alongside the session object. Then, if the invited_org_user_id
is present in the next step of the invite flow, fetch the user object
from the API instead of from the session. If it's not present (due to a
session set by an older instance of the admin app), then just use the
old code to get the entire object out of the session.
For invites where the user is small enough to persist to the cookie,
this will still save both the old and the new way, but will always make
an extra check to the API, I think this minor performance hit is totally
fine. For invites where the user is too big to persist, they'll still
fail for now, and will need to wait until the next PR comes along and
stops saving the large invited user object to the session entirely.
2021-03-08 10:01:12 +00:00
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
assert InvitedOrgUser.from_session().id == sample_org_invite["id"]
|
store invited org user ids in session
first of a two step process to remove invited user objects from the
session. we're removing them because they're of variable size, and with
a lot of folder permissions they can cause the session to exceed the 4kb
cookie size limit and not save properly.
this commit looks at invited org users only.
in this step, start saving the invited org user's id to the
session alongside the session object. Then, if the invited_org_user_id
is present in the next step of the invite flow, fetch the user object
from the API instead of from the session. If it's not present (due to a
session set by an older instance of the admin app), then just use the
old code to get the entire object out of the session.
For invites where the user is small enough to persist to the cookie,
this will still save both the old and the new way, but will always make
an extra check to the API, I think this minor performance hit is totally
fine. For invites where the user is too big to persist, they'll still
fail for now, and will need to wait until the next PR comes along and
stops saving the large invited user object to the session entirely.
2021-03-08 10:01:12 +00:00
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
mock_get_invited_org_user_by_id.assert_called_once_with(sample_org_invite["id"])
|
store invited org user ids in session
first of a two step process to remove invited user objects from the
session. we're removing them because they're of variable size, and with
a lot of folder permissions they can cause the session to exceed the 4kb
cookie size limit and not save properly.
this commit looks at invited org users only.
in this step, start saving the invited org user's id to the
session alongside the session object. Then, if the invited_org_user_id
is present in the next step of the invite flow, fetch the user object
from the API instead of from the session. If it's not present (due to a
session set by an older instance of the admin app), then just use the
old code to get the entire object out of the session.
For invites where the user is small enough to persist to the cookie,
this will still save both the old and the new way, but will always make
an extra check to the API, I think this minor performance hit is totally
fine. For invites where the user is too big to persist, they'll still
fail for now, and will need to wait until the next PR comes along and
stops saving the large invited user object to the session entirely.
2021-03-08 10:01:12 +00:00
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
def test_invited_org_user_from_session_returns_none_if_nothing_present(
|
|
|
|
|
client_request, mocker
|
|
|
|
|
):
|
|
|
|
|
mocker.patch.dict("app.models.user.session", values={}, clear=True)
|
store invited org user ids in session
first of a two step process to remove invited user objects from the
session. we're removing them because they're of variable size, and with
a lot of folder permissions they can cause the session to exceed the 4kb
cookie size limit and not save properly.
this commit looks at invited org users only.
in this step, start saving the invited org user's id to the
session alongside the session object. Then, if the invited_org_user_id
is present in the next step of the invite flow, fetch the user object
from the API instead of from the session. If it's not present (due to a
session set by an older instance of the admin app), then just use the
old code to get the entire object out of the session.
For invites where the user is small enough to persist to the cookie,
this will still save both the old and the new way, but will always make
an extra check to the API, I think this minor performance hit is totally
fine. For invites where the user is too big to persist, they'll still
fail for now, and will need to wait until the next PR comes along and
stops saving the large invited user object to the session entirely.
2021-03-08 10:01:12 +00:00
|
|
|
assert InvitedOrgUser.from_session() is None
|
2021-07-15 11:57:33 +01:00
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
def test_set_permissions(
|
|
|
|
|
client_request, mocker, active_user_view_permissions, fake_uuid
|
|
|
|
|
):
|
|
|
|
|
mock_api = mocker.patch("app.models.user.user_api_client.set_user_permissions")
|
|
|
|
|
mock_event = mocker.patch("app.models.user.create_set_user_permissions_event")
|
2021-07-15 11:57:33 +01:00
|
|
|
|
|
|
|
|
User(active_user_view_permissions).set_permissions(
|
|
|
|
|
service_id=SERVICE_ONE_ID,
|
2023-08-25 09:12:23 -07:00
|
|
|
permissions={"manage_templates"},
|
2021-07-15 11:57:33 +01:00
|
|
|
folder_permissions=[],
|
|
|
|
|
set_by_id=fake_uuid,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
mock_api.assert_called_once()
|
|
|
|
|
mock_event.assert_called_once_with(
|
|
|
|
|
service_id=SERVICE_ONE_ID,
|
2023-08-25 09:12:23 -07:00
|
|
|
user_id=active_user_view_permissions["id"],
|
|
|
|
|
original_ui_permissions={"view_activity"},
|
|
|
|
|
new_ui_permissions={"manage_templates"},
|
2021-07-15 11:57:33 +01:00
|
|
|
set_by_id=fake_uuid,
|
|
|
|
|
)
|
2021-07-15 12:13:42 +01:00
|
|
|
|
|
|
|
|
|
2022-01-04 18:33:23 +00:00
|
|
|
def test_add_to_service(client_request, mocker, api_user_active, fake_uuid):
|
2023-08-25 09:12:23 -07:00
|
|
|
mock_api = mocker.patch("app.models.user.user_api_client.add_user_to_service")
|
|
|
|
|
mock_event = mocker.patch("app.models.user.create_add_user_to_service_event")
|
2021-07-15 12:13:42 +01:00
|
|
|
|
|
|
|
|
User(api_user_active).add_to_service(
|
|
|
|
|
service_id=SERVICE_ONE_ID,
|
2023-08-25 09:12:23 -07:00
|
|
|
permissions={"manage_templates"},
|
2021-07-15 12:13:42 +01:00
|
|
|
folder_permissions=[],
|
|
|
|
|
invited_by_id=fake_uuid,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
mock_api.assert_called_once()
|
|
|
|
|
mock_event.assert_called_once_with(
|
|
|
|
|
service_id=SERVICE_ONE_ID,
|
2023-08-25 09:12:23 -07:00
|
|
|
user_id=api_user_active["id"],
|
2021-07-15 12:13:42 +01:00
|
|
|
invited_by_id=fake_uuid,
|
2023-08-25 09:12:23 -07:00
|
|
|
ui_permissions={"manage_templates"},
|
2021-07-15 12:13:42 +01:00
|
|
|
)
|