darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-02-10 13:23:40 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
a088409dfeba315d3719e9e6d147ddf96cd75b0f
notifications-admin/app/utils/user_permissions.py

52 lines
1.8 KiB
Python
Raw Normal View History

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 itertools import chain
Start to remove use of the term "roles" We don't use this term consistently and it's not defined anywhere. Since most of the Admin app deals with user-facing permssions, it's OK to just use the term "permissions". Where both types of permission are present in the same file, we can more clearly distinguish them as "UI permissions" and "DB permissions".
2021-07-22 14:25:22 +01:00
permission_mappings = {
big commit with letters removal
2022-12-05 15:33:44 -05:00
# TODO: consider turning off email-sending permissions during SMS pilot
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"send_messages": ["send_texts", "send_emails"],
"manage_templates": ["manage_templates"],
"manage_service": ["manage_users", "manage_settings"],
"manage_api_keys": ["manage_api_keys"],
"view_activity": ["view_activity"],
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
}
Start to remove use of the term "roles" We don't use this term consistently and it's not defined anywhere. Since most of the Admin app deals with user-facing permssions, it's OK to just use the term "permissions". Where both types of permission are present in the same file, we can more clearly distinguish them as "UI permissions" and "DB permissions".
2021-07-22 14:25:22 +01:00
all_ui_permissions = set(permission_mappings.keys())
all_db_permissions = set(chain(*permission_mappings.values()))
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
Rename unclear "permissions" attributes These are more than a list of permissions: each item includes the label to use when displaying it as an option on a form. Switching to a name that reflects how the attributes are used will help to avoid confusion when we rename some of the other attributes in the same file in later commits.
2021-07-22 14:15:24 +01:00
permission_options = (
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
("view_activity", "See dashboard"),
("send_messages", "Send messages"),
("manage_templates", "Add and edit templates"),
("manage_service", "Manage settings, team and usage"),
("manage_api_keys", "Manage API integration"),
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
)
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
def translate_permissions_from_db_to_ui(db_permissions):
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
"""
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
Given a list of database permissions, return a set of UI permissions
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
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
A UI permission is returned if all of its DB permissions are in the permission list that is passed in.
Any DB permissions in the list that are not known permissions are also returned.
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
"""
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
unknown_database_permissions = set(db_permissions) - all_db_permissions
Update the broadcast roles We've added new broadcast roles in the database (`create_broadcasts` and `approve_broadcasts`). Adding these has meant we've needed to do a bit of a rewrite of the roles and permissions code since this had been based on the assumption that each database permission only belongs to one admin role - this is no longer true. This means that flipping the roles dict round to create a dict which contains database permissions as the keys is no longer possible. We can't necessarily tell which admin role someone has given a database permission. To check if a user has an admin role given a list of database permissions, the user must now have ALL the database permissions mapped to that role (instead of just one). This works because no one has the `manage_users` permission without also having the `manage_settings` (and similar for the other admin roles which map to multiple database permissions). Some test data was changed because it was using admin roles where database permissions are actually used when the app is running. I've kept the functionality of the `translate_permissions_from_db_to_admin_roles` function passing through any unknown roles it is passed as an argument. This is not necessary, so can be changed later if we decide it will not ever be used. However, removing it would require updating a lot of tests since the tests rely on this behaviour.
2021-06-18 15:09:11 +01:00
return {
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
ui_permission
for ui_permission, db_permissions_for_ui_permission in permission_mappings.items()
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
if set(db_permissions_for_ui_permission) <= set(db_permissions)
Update the broadcast roles We've added new broadcast roles in the database (`create_broadcasts` and `approve_broadcasts`). Adding these has meant we've needed to do a bit of a rewrite of the roles and permissions code since this had been based on the assumption that each database permission only belongs to one admin role - this is no longer true. This means that flipping the roles dict round to create a dict which contains database permissions as the keys is no longer possible. We can't necessarily tell which admin role someone has given a database permission. To check if a user has an admin role given a list of database permissions, the user must now have ALL the database permissions mapped to that role (instead of just one). This works because no one has the `manage_users` permission without also having the `manage_settings` (and similar for the other admin roles which map to multiple database permissions). Some test data was changed because it was using admin roles where database permissions are actually used when the app is running. I've kept the functionality of the `translate_permissions_from_db_to_admin_roles` function passing through any unknown roles it is passed as an argument. This is not necessary, so can be changed later if we decide it will not ever be used. However, removing it would require updating a lot of tests since the tests rely on this behaviour.
2021-06-18 15:09:11 +01:00
} | unknown_database_permissions
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
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
def translate_permissions_from_ui_to_db(ui_permissions):
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
"""
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
Given a list of UI permissions (ie: checkboxes on a permissions edit page), return a set of DB permissions
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
Continue to remove "roles" terminology This renames the two functions we have to translate between UI and DB permissions, as well as some of their associated variables to make it clearer which kind of permission they contain.
2021-07-22 14:38:45 +01:00
Looks them up in the mapping, falling back to just passing through if they're not recognised.
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
"""
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
return set(
chain.from_iterable(
permission_mappings.get(ui_permission, [ui_permission])
for ui_permission in ui_permissions
)
)
Reference in New Issue Copy Permalink