Changes proposed in this pull request:
A new permission controls whether the user can add more than 2 user recipients to a discussion. This allows restricting the feature to simple direct messages and control who can create group discussions separately.
The texts in the recipients modal have not been modified, but if you try adding a third recipient to a new discussion and don't have the permission, the other recipient will be removed and the newly selected recipient added.
The permission only affects the user count. If the actor has permission to add groups, those are still unlimited and unaffected. It probably doesn't make sense to restrict user count while allowing groups but it'll work.
Reviewers should focus on:
This first version is not "backward compatible", users who update would lose functionality until they customize the new permission. I guess we should copy the value of discussion.startPrivateDiscussionWithUsers into discussion.addMoreThanTwoUserRecipients with a migration? The challenge is that if users forget to run the migrations they will encounter the issue anyway, and the migration needs to do nothing if run later, but has no way of knowing if the lack of value is indication of a choice for "admin" or that no choice was made...
I think there are also edge cases regarding leaving. You could add a "third" recipient at the same time as you remove yourself, which still meets the 2 recipients rule.
This PR was sponsored by a client.
Confirmed
[x] Frontend changes: tested on a local Flarum installation.
[ ] Backend changes: tests are green (run composer test).
Changes proposed in this pull request: A new permission controls whether the user can add more than 2 user recipients to a discussion. This allows restricting the feature to simple direct messages and control who can create group discussions separately.
The texts in the recipients modal have not been modified, but if you try adding a third recipient to a new discussion and don't have the permission, the other recipient will be removed and the newly selected recipient added.
The permission only affects the user count. If the actor has permission to add groups, those are still unlimited and unaffected. It probably doesn't make sense to restrict user count while allowing groups but it'll work.
Reviewers should focus on: This first version is not "backward compatible", users who update would lose functionality until they customize the new permission. I guess we should copy the value of
discussion.startPrivateDiscussionWithUsersintodiscussion.addMoreThanTwoUserRecipientswith a migration? The challenge is that if users forget to run the migrations they will encounter the issue anyway, and the migration needs to do nothing if run later, but has no way of knowing if the lack of value is indication of a choice for "admin" or that no choice was made...I think there are also edge cases regarding leaving. You could add a "third" recipient at the same time as you remove yourself, which still meets the 2 recipients rule.
This PR was sponsored by a client.
Confirmed
composer test).