2023-01-29 14:02:07 +01:00
|
|
|
from django.conf import settings
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
from django.db import transaction
|
2020-06-11 00:54:34 +02:00
|
|
|
from django.http import HttpRequest, HttpResponse
|
2021-04-16 00:57:30 +02:00
|
|
|
from django.utils.translation import gettext as _
|
2023-01-29 14:02:07 +01:00
|
|
|
from django.utils.translation import override as override_language
|
2024-05-06 17:35:51 +02:00
|
|
|
from pydantic import Json
|
2020-06-11 00:54:34 +02:00
|
|
|
|
2023-01-29 14:02:07 +01:00
|
|
|
from zerver.actions.message_send import do_send_messages, internal_prep_private_message
|
2022-04-14 23:30:17 +02:00
|
|
|
from zerver.actions.user_groups import (
|
2022-03-02 11:58:37 +01:00
|
|
|
add_subgroups_to_user_group,
|
2023-09-29 01:45:53 +02:00
|
|
|
bulk_add_members_to_user_groups,
|
|
|
|
bulk_remove_members_from_user_groups,
|
2020-06-11 00:54:34 +02:00
|
|
|
check_add_user_group,
|
|
|
|
check_delete_user_group,
|
2023-06-15 05:24:23 +02:00
|
|
|
do_change_user_group_permission_setting,
|
2024-05-15 15:44:18 +02:00
|
|
|
do_deactivate_user_group,
|
2020-06-11 00:54:34 +02:00
|
|
|
do_update_user_group_description,
|
|
|
|
do_update_user_group_name,
|
2022-03-02 11:58:37 +01:00
|
|
|
remove_subgroups_from_user_group,
|
2020-06-11 00:54:34 +02:00
|
|
|
)
|
2023-07-17 09:43:11 +02:00
|
|
|
from zerver.decorator import require_member_or_admin, require_user_group_create_permission
|
2024-05-16 17:58:43 +02:00
|
|
|
from zerver.lib.exceptions import JsonableError
|
2023-01-29 14:02:07 +01:00
|
|
|
from zerver.lib.mention import MentionBackend, silent_mention_syntax_for_user
|
2021-06-30 18:35:50 +02:00
|
|
|
from zerver.lib.response import json_success
|
2024-07-26 11:15:15 +02:00
|
|
|
from zerver.lib.typed_endpoint import PathOnly, typed_endpoint, typed_endpoint_without_parameters
|
2020-06-11 00:54:34 +02:00
|
|
|
from zerver.lib.user_groups import (
|
2024-04-29 05:51:48 +02:00
|
|
|
AnonymousSettingGroupDict,
|
2024-05-16 17:58:43 +02:00
|
|
|
GroupSettingChangeRequest,
|
2020-06-11 00:54:34 +02:00
|
|
|
access_user_group_by_id,
|
2024-05-15 15:44:18 +02:00
|
|
|
access_user_group_for_deactivation,
|
2023-06-14 16:48:58 +02:00
|
|
|
access_user_group_for_setting,
|
2023-07-03 08:01:01 +02:00
|
|
|
check_user_group_name,
|
2021-10-09 20:02:39 +02:00
|
|
|
get_direct_memberships_of_users,
|
2024-05-28 11:22:42 +02:00
|
|
|
get_group_setting_value_for_api,
|
2022-04-04 13:59:25 +02:00
|
|
|
get_subgroup_ids,
|
2022-04-27 11:59:25 +02:00
|
|
|
get_user_group_direct_member_ids,
|
2022-03-24 11:39:57 +01:00
|
|
|
get_user_group_member_ids,
|
2022-03-18 14:38:11 +01:00
|
|
|
is_user_in_group,
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
lock_subgroups_with_respect_to_supergroup,
|
2024-05-16 17:58:43 +02:00
|
|
|
parse_group_setting_value,
|
2020-06-11 00:54:34 +02:00
|
|
|
user_groups_in_realm_serialized,
|
2024-05-16 17:58:43 +02:00
|
|
|
validate_group_setting_value_change,
|
2020-06-11 00:54:34 +02:00
|
|
|
)
|
2022-03-18 14:38:11 +01:00
|
|
|
from zerver.lib.users import access_user_by_id, user_ids_to_users
|
2024-05-16 17:58:43 +02:00
|
|
|
from zerver.models import NamedUserGroup, UserProfile
|
2023-12-15 01:16:00 +01:00
|
|
|
from zerver.models.users import get_system_bot
|
2021-02-16 01:19:02 +01:00
|
|
|
from zerver.views.streams import compose_views
|
2020-06-11 00:54:34 +02:00
|
|
|
|
2017-11-01 10:04:16 +01:00
|
|
|
|
2024-08-09 12:30:44 +02:00
|
|
|
@transaction.atomic(durable=True)
|
2023-07-17 09:20:50 +02:00
|
|
|
@require_user_group_create_permission
|
2024-05-06 17:35:51 +02:00
|
|
|
@typed_endpoint
|
2021-02-12 08:19:30 +01:00
|
|
|
def add_user_group(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-05-06 17:35:51 +02:00
|
|
|
*,
|
|
|
|
name: str,
|
2024-07-26 11:15:15 +02:00
|
|
|
members: Json[list[int]],
|
2024-05-06 17:35:51 +02:00
|
|
|
description: str,
|
2023-07-25 14:57:19 +02:00
|
|
|
can_manage_group: Json[int | AnonymousSettingGroupDict] | None = None,
|
2024-07-12 02:30:23 +02:00
|
|
|
can_mention_group: Json[int | AnonymousSettingGroupDict] | None = None,
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> HttpResponse:
|
2017-11-01 10:04:16 +01:00
|
|
|
user_profiles = user_ids_to_users(members, user_profile.realm)
|
2023-07-03 08:01:01 +02:00
|
|
|
name = check_user_group_name(name)
|
2023-06-14 16:48:58 +02:00
|
|
|
|
|
|
|
group_settings_map = {}
|
|
|
|
request_settings_dict = locals()
|
2024-04-18 10:50:51 +02:00
|
|
|
for setting_name, permission_config in NamedUserGroup.GROUP_PERMISSION_SETTINGS.items():
|
2024-04-29 05:51:48 +02:00
|
|
|
if setting_name not in request_settings_dict: # nocoverage
|
2023-06-14 16:48:58 +02:00
|
|
|
continue
|
|
|
|
|
2024-04-29 05:51:48 +02:00
|
|
|
if request_settings_dict[setting_name] is not None:
|
2024-05-30 05:45:38 +02:00
|
|
|
setting_value = parse_group_setting_value(
|
|
|
|
request_settings_dict[setting_name], setting_name
|
|
|
|
)
|
2023-06-14 16:48:58 +02:00
|
|
|
setting_value_group = access_user_group_for_setting(
|
2024-04-29 05:51:48 +02:00
|
|
|
setting_value,
|
2023-06-14 16:48:58 +02:00
|
|
|
user_profile,
|
|
|
|
setting_name=setting_name,
|
2023-09-18 16:55:58 +02:00
|
|
|
permission_configuration=permission_config,
|
2023-06-14 16:48:58 +02:00
|
|
|
)
|
|
|
|
group_settings_map[setting_name] = setting_value_group
|
|
|
|
|
2022-11-21 03:37:11 +01:00
|
|
|
check_add_user_group(
|
2023-06-14 16:48:58 +02:00
|
|
|
user_profile.realm,
|
|
|
|
name,
|
|
|
|
user_profiles,
|
|
|
|
description,
|
|
|
|
group_settings_map=group_settings_map,
|
|
|
|
acting_user=user_profile,
|
2022-11-21 03:37:11 +01:00
|
|
|
)
|
2022-01-31 13:44:02 +01:00
|
|
|
return json_success(request)
|
2017-11-02 07:53:08 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2019-06-18 16:43:22 +02:00
|
|
|
@require_member_or_admin
|
2024-07-26 11:15:15 +02:00
|
|
|
@typed_endpoint_without_parameters
|
2018-08-16 02:44:51 +02:00
|
|
|
def get_user_group(request: HttpRequest, user_profile: UserProfile) -> HttpResponse:
|
|
|
|
user_groups = user_groups_in_realm_serialized(user_profile.realm)
|
2022-01-31 13:44:02 +01:00
|
|
|
return json_success(request, data={"user_groups": user_groups})
|
2018-08-16 02:44:51 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-08-09 10:41:30 +02:00
|
|
|
@transaction.atomic(durable=True)
|
2023-07-17 09:43:11 +02:00
|
|
|
@require_member_or_admin
|
2024-05-06 17:35:51 +02:00
|
|
|
@typed_endpoint
|
2021-02-12 08:19:30 +01:00
|
|
|
def edit_user_group(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-05-06 17:35:51 +02:00
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[int],
|
2024-07-12 02:30:23 +02:00
|
|
|
name: str | None = None,
|
|
|
|
description: str | None = None,
|
2023-07-25 13:13:52 +02:00
|
|
|
can_manage_group: Json[GroupSettingChangeRequest] | None = None,
|
2024-07-12 02:30:23 +02:00
|
|
|
can_mention_group: Json[GroupSettingChangeRequest] | None = None,
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> HttpResponse:
|
2023-07-25 13:13:52 +02:00
|
|
|
if (
|
|
|
|
name is None
|
|
|
|
and description is None
|
|
|
|
and can_manage_group is None
|
|
|
|
and can_mention_group is None
|
|
|
|
):
|
2021-06-30 18:35:50 +02:00
|
|
|
raise JsonableError(_("No new data supplied"))
|
2017-11-02 07:53:08 +01:00
|
|
|
|
2024-05-16 16:00:25 +02:00
|
|
|
user_group = access_user_group_by_id(
|
|
|
|
user_group_id, user_profile, for_read=False, allow_deactivated=True
|
|
|
|
)
|
|
|
|
|
|
|
|
if user_group.deactivated and (
|
|
|
|
description is not None or can_mention_group is not None or can_manage_group is not None
|
|
|
|
):
|
|
|
|
raise JsonableError(_("You can only change name of deactivated user groups"))
|
2017-11-02 07:53:08 +01:00
|
|
|
|
2023-02-26 16:47:58 +01:00
|
|
|
if name is not None and name != user_group.name:
|
2023-07-03 08:01:01 +02:00
|
|
|
name = check_user_group_name(name)
|
2022-11-21 03:43:48 +01:00
|
|
|
do_update_user_group_name(user_group, name, acting_user=user_profile)
|
2017-11-02 07:53:08 +01:00
|
|
|
|
2023-02-26 16:47:58 +01:00
|
|
|
if description is not None and description != user_group.description:
|
2022-11-21 03:45:16 +01:00
|
|
|
do_update_user_group_description(user_group, description, acting_user=user_profile)
|
2017-11-02 07:53:08 +01:00
|
|
|
|
2023-06-15 05:24:23 +02:00
|
|
|
request_settings_dict = locals()
|
2024-04-18 10:50:51 +02:00
|
|
|
for setting_name, permission_config in NamedUserGroup.GROUP_PERMISSION_SETTINGS.items():
|
2024-04-30 15:16:58 +02:00
|
|
|
if setting_name not in request_settings_dict: # nocoverage
|
|
|
|
continue
|
2023-06-15 05:24:23 +02:00
|
|
|
|
2024-04-30 15:16:58 +02:00
|
|
|
if request_settings_dict[setting_name] is None:
|
2023-06-15 05:24:23 +02:00
|
|
|
continue
|
|
|
|
|
2024-05-02 15:52:23 +02:00
|
|
|
setting_value = request_settings_dict[setting_name]
|
2024-05-30 05:45:38 +02:00
|
|
|
new_setting_value = parse_group_setting_value(setting_value.new, setting_name)
|
2024-05-02 15:52:23 +02:00
|
|
|
|
|
|
|
expected_current_setting_value = None
|
|
|
|
if setting_value.old is not None:
|
2024-05-30 05:45:38 +02:00
|
|
|
expected_current_setting_value = parse_group_setting_value(
|
|
|
|
setting_value.old, setting_name
|
|
|
|
)
|
2024-05-02 15:52:23 +02:00
|
|
|
|
2024-04-30 15:16:58 +02:00
|
|
|
current_value = getattr(user_group, setting_name)
|
2024-05-28 11:22:42 +02:00
|
|
|
current_setting_api_value = get_group_setting_value_for_api(current_value)
|
2024-05-02 15:52:23 +02:00
|
|
|
if validate_group_setting_value_change(
|
2024-05-28 11:22:42 +02:00
|
|
|
current_setting_api_value, new_setting_value, expected_current_setting_value
|
2024-05-02 15:52:23 +02:00
|
|
|
):
|
2023-06-15 05:24:23 +02:00
|
|
|
setting_value_group = access_user_group_for_setting(
|
2024-04-30 15:16:58 +02:00
|
|
|
new_setting_value,
|
2023-06-15 05:24:23 +02:00
|
|
|
user_profile,
|
|
|
|
setting_name=setting_name,
|
2023-09-18 16:55:58 +02:00
|
|
|
permission_configuration=permission_config,
|
2024-04-30 15:16:58 +02:00
|
|
|
current_setting_value=current_value,
|
2023-06-15 05:24:23 +02:00
|
|
|
)
|
|
|
|
do_change_user_group_permission_setting(
|
2024-05-28 11:22:42 +02:00
|
|
|
user_group,
|
|
|
|
setting_name,
|
|
|
|
setting_value_group,
|
|
|
|
old_setting_api_value=current_setting_api_value,
|
|
|
|
acting_user=user_profile,
|
2023-06-15 05:24:23 +02:00
|
|
|
)
|
|
|
|
|
2022-01-31 13:44:02 +01:00
|
|
|
return json_success(request)
|
2017-11-02 08:15:14 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2023-07-17 09:43:11 +02:00
|
|
|
@require_member_or_admin
|
2024-07-26 11:15:15 +02:00
|
|
|
@typed_endpoint
|
2021-02-12 08:19:30 +01:00
|
|
|
def delete_user_group(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-07-26 11:15:15 +02:00
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[Json[int]],
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> HttpResponse:
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
# For deletion, the user group's recursive subgroups and the user group itself are locked.
|
|
|
|
with lock_subgroups_with_respect_to_supergroup(
|
|
|
|
[user_group_id], user_group_id, acting_user=user_profile
|
|
|
|
) as context:
|
|
|
|
check_delete_user_group(context.supergroup, acting_user=user_profile)
|
2022-01-31 13:44:02 +01:00
|
|
|
return json_success(request)
|
2017-11-02 08:53:30 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-05-15 15:44:18 +02:00
|
|
|
@typed_endpoint
|
|
|
|
@transaction.atomic
|
|
|
|
def deactivate_user_group(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[Json[int]],
|
|
|
|
) -> HttpResponse:
|
|
|
|
user_group = access_user_group_for_deactivation(user_group_id, user_profile)
|
|
|
|
do_deactivate_user_group(user_group, acting_user=user_profile)
|
|
|
|
return json_success(request)
|
|
|
|
|
|
|
|
|
2023-07-17 09:43:11 +02:00
|
|
|
@require_member_or_admin
|
2024-07-26 11:15:15 +02:00
|
|
|
@typed_endpoint
|
2021-02-12 08:19:30 +01:00
|
|
|
def update_user_group_backend(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-07-26 11:15:15 +02:00
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[Json[int]],
|
|
|
|
delete: Json[list[int]] | None = None,
|
|
|
|
add: Json[list[int]] | None = None,
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> HttpResponse:
|
2017-11-02 08:53:30 +01:00
|
|
|
if not add and not delete:
|
2021-06-30 18:35:50 +02:00
|
|
|
raise JsonableError(_('Nothing to do. Specify at least one of "add" or "delete".'))
|
2017-11-02 08:53:30 +01:00
|
|
|
|
2024-07-26 11:15:15 +02:00
|
|
|
thunks = []
|
|
|
|
if add:
|
|
|
|
thunks.append(
|
|
|
|
lambda: add_members_to_group_backend(
|
|
|
|
request, user_profile, user_group_id=user_group_id, members=add
|
|
|
|
)
|
|
|
|
)
|
|
|
|
if delete:
|
|
|
|
thunks.append(
|
|
|
|
lambda: remove_members_from_group_backend(
|
|
|
|
request, user_profile, user_group_id=user_group_id, members=delete
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|
2022-01-31 15:27:58 +01:00
|
|
|
data = compose_views(thunks)
|
|
|
|
|
2022-01-31 13:44:02 +01:00
|
|
|
return json_success(request, data)
|
2017-11-02 08:53:30 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2023-01-29 14:02:07 +01:00
|
|
|
def notify_for_user_group_subscription_changes(
|
|
|
|
acting_user: UserProfile,
|
2024-07-12 02:30:17 +02:00
|
|
|
recipient_users: list[UserProfile],
|
2024-04-17 05:45:32 +02:00
|
|
|
user_group: NamedUserGroup,
|
2023-01-29 14:02:07 +01:00
|
|
|
*,
|
|
|
|
send_subscription_message: bool = False,
|
|
|
|
send_unsubscription_message: bool = False,
|
|
|
|
) -> None:
|
|
|
|
realm = acting_user.realm
|
|
|
|
mention_backend = MentionBackend(realm.id)
|
|
|
|
|
|
|
|
notifications = []
|
|
|
|
notification_bot = get_system_bot(settings.NOTIFICATION_BOT, realm.id)
|
|
|
|
for recipient_user in recipient_users:
|
|
|
|
if recipient_user.id == acting_user.id:
|
|
|
|
# Don't send notification message if you subscribed/unsubscribed yourself.
|
|
|
|
continue
|
|
|
|
if recipient_user.is_bot:
|
|
|
|
# Don't send notification message to bots.
|
|
|
|
continue
|
|
|
|
if not recipient_user.is_active:
|
|
|
|
# Don't send notification message to deactivated users.
|
|
|
|
continue
|
|
|
|
|
|
|
|
with override_language(recipient_user.default_language):
|
|
|
|
if send_subscription_message:
|
|
|
|
message = _("{user_full_name} added you to the group {group_name}.").format(
|
|
|
|
user_full_name=silent_mention_syntax_for_user(acting_user),
|
|
|
|
group_name=f"@_*{user_group.name}*",
|
|
|
|
)
|
|
|
|
if send_unsubscription_message:
|
|
|
|
message = _("{user_full_name} removed you from the group {group_name}.").format(
|
|
|
|
user_full_name=silent_mention_syntax_for_user(acting_user),
|
|
|
|
group_name=f"@_*{user_group.name}*",
|
|
|
|
)
|
|
|
|
|
|
|
|
notifications.append(
|
|
|
|
internal_prep_private_message(
|
|
|
|
sender=notification_bot,
|
|
|
|
recipient_user=recipient_user,
|
|
|
|
content=message,
|
|
|
|
mention_backend=mention_backend,
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|
|
|
|
if len(notifications) > 0:
|
|
|
|
do_send_messages(notifications)
|
|
|
|
|
|
|
|
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
@transaction.atomic
|
2021-02-12 08:19:30 +01:00
|
|
|
def add_members_to_group_backend(
|
2024-07-26 11:15:15 +02:00
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
|
|
|
user_group_id: int,
|
|
|
|
members: list[int],
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> HttpResponse:
|
2023-06-17 00:27:42 +02:00
|
|
|
user_group = access_user_group_by_id(user_group_id, user_profile, for_read=False)
|
2023-03-31 12:11:51 +02:00
|
|
|
member_users = user_ids_to_users(members, user_profile.realm)
|
2024-04-17 05:45:32 +02:00
|
|
|
existing_member_ids = set(
|
|
|
|
get_direct_memberships_of_users(user_group.usergroup_ptr, member_users)
|
|
|
|
)
|
2018-02-19 13:38:18 +01:00
|
|
|
|
2023-03-31 12:11:51 +02:00
|
|
|
for member_user in member_users:
|
|
|
|
if member_user.id in existing_member_ids:
|
2021-02-12 08:19:30 +01:00
|
|
|
raise JsonableError(
|
|
|
|
_("User {user_id} is already a member of this group").format(
|
2023-03-31 12:11:51 +02:00
|
|
|
user_id=member_user.id,
|
2021-02-12 08:19:30 +01:00
|
|
|
)
|
|
|
|
)
|
2017-11-02 08:53:30 +01:00
|
|
|
|
2023-03-31 12:11:51 +02:00
|
|
|
member_user_ids = [member_user.id for member_user in member_users]
|
2023-09-29 01:45:53 +02:00
|
|
|
bulk_add_members_to_user_groups([user_group], member_user_ids, acting_user=user_profile)
|
2023-01-29 14:02:07 +01:00
|
|
|
notify_for_user_group_subscription_changes(
|
|
|
|
acting_user=user_profile,
|
|
|
|
recipient_users=member_users,
|
|
|
|
user_group=user_group,
|
|
|
|
send_subscription_message=True,
|
|
|
|
)
|
2022-01-31 13:44:02 +01:00
|
|
|
return json_success(request)
|
2017-11-02 08:53:30 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
@transaction.atomic
|
2021-02-12 08:19:30 +01:00
|
|
|
def remove_members_from_group_backend(
|
2024-07-26 11:15:15 +02:00
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
|
|
|
user_group_id: int,
|
|
|
|
members: list[int],
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> HttpResponse:
|
2017-11-02 08:53:30 +01:00
|
|
|
user_profiles = user_ids_to_users(members, user_profile.realm)
|
2023-06-17 00:27:42 +02:00
|
|
|
user_group = access_user_group_by_id(user_group_id, user_profile, for_read=False)
|
2022-04-27 11:59:25 +02:00
|
|
|
group_member_ids = get_user_group_direct_member_ids(user_group)
|
2018-02-19 13:38:18 +01:00
|
|
|
for member in members:
|
2021-02-12 08:19:30 +01:00
|
|
|
if member not in group_member_ids:
|
2023-07-17 22:40:33 +02:00
|
|
|
raise JsonableError(
|
|
|
|
_("There is no member '{user_id}' in this user group").format(user_id=member)
|
|
|
|
)
|
2018-02-19 13:38:18 +01:00
|
|
|
|
2022-03-12 09:44:14 +01:00
|
|
|
user_profile_ids = [user.id for user in user_profiles]
|
2023-09-29 01:45:53 +02:00
|
|
|
bulk_remove_members_from_user_groups([user_group], user_profile_ids, acting_user=user_profile)
|
2023-01-29 14:02:07 +01:00
|
|
|
notify_for_user_group_subscription_changes(
|
|
|
|
acting_user=user_profile,
|
|
|
|
recipient_users=user_profiles,
|
|
|
|
user_group=user_group,
|
|
|
|
send_unsubscription_message=True,
|
|
|
|
)
|
2022-01-31 13:44:02 +01:00
|
|
|
return json_success(request)
|
2022-03-02 11:58:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
def add_subgroups_to_group_backend(
|
2024-07-26 11:15:15 +02:00
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
|
|
|
user_group_id: int,
|
|
|
|
subgroup_ids: list[int],
|
2022-03-02 11:58:37 +01:00
|
|
|
) -> HttpResponse:
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
with lock_subgroups_with_respect_to_supergroup(
|
|
|
|
subgroup_ids, user_group_id, user_profile
|
|
|
|
) as context:
|
|
|
|
existing_direct_subgroup_ids = context.supergroup.direct_subgroups.all().values_list(
|
|
|
|
"id", flat=True
|
|
|
|
)
|
|
|
|
for group in context.direct_subgroups:
|
|
|
|
if group.id in existing_direct_subgroup_ids:
|
|
|
|
raise JsonableError(
|
|
|
|
_("User group {group_id} is already a subgroup of this group.").format(
|
|
|
|
group_id=group.id
|
|
|
|
)
|
2022-03-02 11:58:37 +01:00
|
|
|
)
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
|
|
|
|
recursive_subgroup_ids = {
|
|
|
|
recursive_subgroup.id for recursive_subgroup in context.recursive_subgroups
|
|
|
|
}
|
|
|
|
if user_group_id in recursive_subgroup_ids:
|
|
|
|
raise JsonableError(
|
|
|
|
_(
|
|
|
|
"User group {user_group_id} is already a subgroup of one of the passed subgroups."
|
|
|
|
).format(user_group_id=user_group_id)
|
2022-03-02 11:58:37 +01:00
|
|
|
)
|
|
|
|
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
add_subgroups_to_user_group(
|
|
|
|
context.supergroup, context.direct_subgroups, acting_user=user_profile
|
2023-06-10 10:00:56 +02:00
|
|
|
)
|
2022-03-02 11:58:37 +01:00
|
|
|
return json_success(request)
|
|
|
|
|
|
|
|
|
|
|
|
def remove_subgroups_from_group_backend(
|
2024-07-26 11:15:15 +02:00
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
|
|
|
user_group_id: int,
|
|
|
|
subgroup_ids: list[int],
|
2022-03-02 11:58:37 +01:00
|
|
|
) -> HttpResponse:
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
with lock_subgroups_with_respect_to_supergroup(
|
|
|
|
subgroup_ids, user_group_id, user_profile
|
|
|
|
) as context:
|
|
|
|
# While the recursive subgroups in the context are not used, it is important that
|
|
|
|
# we acquire a lock for these rows while updating the subgroups to acquire the locks
|
|
|
|
# in a consistent order for subgroup membership changes.
|
|
|
|
existing_direct_subgroup_ids = context.supergroup.direct_subgroups.all().values_list(
|
|
|
|
"id", flat=True
|
|
|
|
)
|
|
|
|
for group in context.direct_subgroups:
|
|
|
|
if group.id not in existing_direct_subgroup_ids:
|
|
|
|
raise JsonableError(
|
|
|
|
_("User group {group_id} is not a subgroup of this group.").format(
|
|
|
|
group_id=group.id
|
|
|
|
)
|
2022-03-02 11:58:37 +01:00
|
|
|
)
|
|
|
|
|
user_groups: Make locks required for updating user group memberships.
**Background**
User groups are expected to comply with the DAG constraint for the
many-to-many inter-group membership. The check for this constraint has
to be performed recursively so that we can find all direct and indirect
subgroups of the user group to be added.
This kind of check is vulnerable to phantom reads which is possible at
the default read committed isolation level because we cannot guarantee
that the check is still valid when we are adding the subgroups to the
user group.
**Solution**
To avoid having another transaction concurrently update one of the
to-be-subgroup after the recursive check is done, and before the subgroup
is added, we use SELECT FOR UPDATE to lock the user group rows.
The lock needs to be acquired before a group membership change is about
to occur before any check has been conducted.
Suppose that we are adding subgroup B to supergroup A, the locking protocol
is specified as follows:
1. Acquire a lock for B and all its direct and indirect subgroups.
2. Acquire a lock for A.
For the removal of user groups, we acquire a lock for the user group to
be removed with all its direct and indirect subgroups. This is the special
case A=B, which is still complaint with the protocol.
**Error handling**
We currently rely on Postgres' deadlock detection to abort transactions
and show an error for the users. In the future, we might need some
recovery mechanism or at least better error handling.
**Notes**
An important note is that we need to reuse the recursive CTE query that
finds the direct and indirect subgroups when applying the lock on the
rows. And the lock needs to be acquired the same way for the addition and
removal of direct subgroups.
User membership change (as opposed to user group membership) is not
affected. Read-only queries aren't either. The locks only protect
critical regions where the user group dependency graph might violate
the DAG constraint, where users are not participating.
**Testing**
We implement a transaction test case targeting some typical scenarios
when an internal server error is expected to happen (this means that the
user group view makes the correct decision to abort the transaction when
something goes wrong with locks).
To achieve this, we add a development view intended only for unit tests.
It has a global BARRIER that can be shared across threads, so that we
can synchronize them to consistently reproduce certain potential race
conditions prevented by the database locks.
The transaction test case lanuches pairs of threads initiating possibly
conflicting requests at the same time. The tests are set up such that exactly N
of them are expected to succeed with a certain error message (while we don't
know each one).
**Security notes**
get_recursive_subgroups_for_groups will no longer fetch user groups from
other realms. As a result, trying to add/remove a subgroup from another
realm results in a UserGroup not found error response.
We also implement subgroup-specific checks in has_user_group_access to
keep permission managing in a single place. Do note that the API
currently don't have a way to violate that check because we are only
checking the realm ID now.
2023-06-17 04:39:52 +02:00
|
|
|
remove_subgroups_from_user_group(
|
|
|
|
context.supergroup, context.direct_subgroups, acting_user=user_profile
|
|
|
|
)
|
|
|
|
|
2022-03-02 11:58:37 +01:00
|
|
|
return json_success(request)
|
|
|
|
|
|
|
|
|
2023-07-17 09:43:11 +02:00
|
|
|
@require_member_or_admin
|
2024-07-26 11:15:15 +02:00
|
|
|
@typed_endpoint
|
2022-03-02 11:58:37 +01:00
|
|
|
def update_subgroups_of_user_group(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-07-26 11:15:15 +02:00
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[Json[int]],
|
|
|
|
delete: Json[list[int]] | None = None,
|
|
|
|
add: Json[list[int]] | None = None,
|
2022-03-02 11:58:37 +01:00
|
|
|
) -> HttpResponse:
|
|
|
|
if not add and not delete:
|
|
|
|
raise JsonableError(_('Nothing to do. Specify at least one of "add" or "delete".'))
|
|
|
|
|
2024-07-26 11:15:15 +02:00
|
|
|
thunks = []
|
|
|
|
if add:
|
|
|
|
thunks.append(
|
|
|
|
lambda: add_subgroups_to_group_backend(
|
|
|
|
request, user_profile, user_group_id=user_group_id, subgroup_ids=add
|
|
|
|
)
|
|
|
|
)
|
|
|
|
if delete:
|
|
|
|
thunks.append(
|
|
|
|
lambda: remove_subgroups_from_group_backend(
|
|
|
|
request, user_profile, user_group_id=user_group_id, subgroup_ids=delete
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|
2022-03-02 11:58:37 +01:00
|
|
|
data = compose_views(thunks)
|
|
|
|
|
|
|
|
return json_success(request, data)
|
2022-03-18 14:38:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
@require_member_or_admin
|
2024-07-26 11:15:15 +02:00
|
|
|
@typed_endpoint
|
2022-03-18 14:38:11 +01:00
|
|
|
def get_is_user_group_member(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-07-26 11:15:15 +02:00
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[Json[int]],
|
|
|
|
user_id: PathOnly[Json[int]],
|
|
|
|
direct_member_only: Json[bool] = False,
|
2022-03-18 14:38:11 +01:00
|
|
|
) -> HttpResponse:
|
|
|
|
user_group = access_user_group_by_id(user_group_id, user_profile, for_read=True)
|
|
|
|
target_user = access_user_by_id(user_profile, user_id, for_admin=False)
|
|
|
|
|
|
|
|
return json_success(
|
|
|
|
request,
|
|
|
|
data={
|
|
|
|
"is_user_group_member": is_user_in_group(
|
|
|
|
user_group, target_user, direct_member_only=direct_member_only
|
|
|
|
)
|
|
|
|
},
|
|
|
|
)
|
2022-03-24 11:39:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
@require_member_or_admin
|
2024-07-26 11:15:15 +02:00
|
|
|
@typed_endpoint
|
2022-03-24 11:39:57 +01:00
|
|
|
def get_user_group_members(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-07-26 11:15:15 +02:00
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[Json[int]],
|
|
|
|
direct_member_only: Json[bool] = False,
|
2022-03-24 11:39:57 +01:00
|
|
|
) -> HttpResponse:
|
|
|
|
user_group = access_user_group_by_id(user_group_id, user_profile, for_read=True)
|
|
|
|
|
|
|
|
return json_success(
|
|
|
|
request,
|
|
|
|
data={
|
|
|
|
"members": get_user_group_member_ids(user_group, direct_member_only=direct_member_only)
|
|
|
|
},
|
|
|
|
)
|
2022-04-04 13:59:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
@require_member_or_admin
|
2024-07-26 11:15:15 +02:00
|
|
|
@typed_endpoint
|
2022-04-04 13:59:25 +02:00
|
|
|
def get_subgroups_of_user_group(
|
|
|
|
request: HttpRequest,
|
|
|
|
user_profile: UserProfile,
|
2024-07-26 11:15:15 +02:00
|
|
|
*,
|
|
|
|
user_group_id: PathOnly[Json[int]],
|
|
|
|
direct_subgroup_only: Json[bool] = False,
|
2022-04-04 13:59:25 +02:00
|
|
|
) -> HttpResponse:
|
|
|
|
user_group = access_user_group_by_id(user_group_id, user_profile, for_read=True)
|
|
|
|
|
|
|
|
return json_success(
|
|
|
|
request,
|
|
|
|
data={"subgroups": get_subgroup_ids(user_group, direct_subgroup_only=direct_subgroup_only)},
|
|
|
|
)
|