settings: Add two realm settings to restrict direct messages.

[Vector73]

1st commit adds is_any_user_in_group function in lib/user_groups.py.

2nd commit adds two realm settings:

• direct_message_initiator_group - ID of the user group whose members can initiate direct message thread.
• direct_message_permission_group - ID of the user group of which at least member must be included as sender or recipient in personal and group direct messages.

3rd commit removes private_message_policy setting.

Fixes: #24467

Screenshots and screen captures:

Screenshots

Self-review checklist

• Self-reviewed the changes for clarity and maintainability
  (variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

• Explains differences from previous plans (e.g., issue description).
• Highlights technical choices and bugs encountered.
• Calls out remaining decisions and concerns.
• Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

• Each commit is a coherent idea.
• Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

• Visual appearance of the changes.
• Responsiveness and internationalization.
• Strings and tooltips.
• End-to-end functionality of buttons, interactions and flows.
• Corner cases, error conditions, and easily imagined bugs.

[zulipbot]

Hello @zulip/server-settings members, this pull request was labeled with the "area: settings (admin/org)" label, so you may want to check it out!

[timabbott]

This first commit should have a commit message explaining why it's desirable and correct to remove this -- I know it's in the PR description, but it's the commits that are most handy for posterity.

[Vector73]

Added commit description.

[Vector73]

• Changed error strings in web client:
  direct_message_permission_group:
  if nobody_system_group, "Direct messages are disabled in this organization.";
  else, "This conversation does not include any users who can authorize it.".

direct_message_intitiator_group: "You are not allowed to start direct message conversations."

• Changed setting label of:
  direct_message_permission_group to "Who can authorize a direct message conversation";
  direct_message_initiator_group to "Who can start a direct message conversation".

Also added Learn more link to /help/restrict-direct-messages in narrow and compose banners.

[alya]

Let's put the help ? on the section heading rather than each of the options, since they go to the same place anyway. It'll be more consistent with other sections in this settings panel as well.

[alya]

We aren't ready to allow non-system groups to be used for permissions settings, so the UI options should be limited to system groups + nobody for now (confirmed with @timabbott ).

[alya]

Looking good other than that! I didn't test exhaustively, but did try a few variations of permission configurations.

[alya]

I noted that if you are composing a DM to a new conversation while viewing another conversation, and you aren't allowed to start conversations, you get a server banner when you try to send, but not a warning banner before you send. @timabbott tells me this is not easy to improve upon, though, so it's fine to leave as-is.

Both types of banners for reference:

[chrisbobbe]

Is there a distinct error code when POST /messages fails because of the new setting? I didn't see one when reading the api_docs/changelog.md changes.

I guess we don't necessarily need a distinct code as long as the error contains a user-facing string we can show the user. Does it?

[timabbott]

This has a reasonable user-facing error string, so there's no special code for it. The web app displays that server-provided string in at least one-error handling case (though in most situations, that doesn't get used just because the web app won't let you try composing to recipients if it knows you don't have permission, there's a few ways to evade that).

My recommendation for mobile is just to have generic code for displaying generic 400 error sending failures to the user.

[timabbott]

This check is OK for now but probably not the ideal way to check if nobody can authorize direct messages.

Can you do a follow-up commit that exports a function interface, user_groups.is_empty_group(realm.realm_direct_message_permission_group), replacing all the role:nobody checks in the web frontend?

That implementation should probably work by just walking the actual membership to see if it's empty.

[timabbott]

Let's put the help ? on the section heading rather than each of the options, since they go to the same place anyway. It'll be more consistent with other sections in this settings panel as well.

Done.

[timabbott]

We aren't ready to allow non-system groups to be used for permissions settings, so the UI options should be limited to system groups + nobody for now (confirmed with @timabbott ).

I think this is probably an issue that we need to audit all the group-based settings that we've merged recently for. I don't really remember what the right way to control this is; @sahil839 can you perhaps put up a follow-up PR for adjusting that?

I think otherwise this is good to merge, so I'm going to do that to keep the migration numbering going. @Vector73 please follow-up on #28470 (comment).

@alya FYI.

[sahil839]

I think this is probably an issue that we need to audit all the group-based settings that we've merged recently for. I don't really remember what the right way to control this is; @sahil839 can you perhaps put up a follow-up PR for adjusting that?

We show user defined groups as options in a couple of newly added settings as we have the UI to allow a single user group to be used for a setting. I don't see any problem in allowing them to provide users the flexibility to create a user group with the intended members for now till we add the UI to allow a combination of users and groups.

[Vector73]

@Vector73 please follow-up on #28470 (comment).

Opened a follow-up PR #30810.