Change Details

Phabricator allows users to add existing, external mailing lists (like a Google Group or a Mailman list) so mail can be sent to them. Often, these lists might have an address like `engineering-list@lists.mycompany.com`. Previously, Mailing Lists were a standalone application. The application has been removed, and mailing lists are now special users instead, similar to bot users. - To create a new mailing list, you'll now go to {nav People > Create New User} and select a "Mailing List" user. - To browse lists, you'll now go to {nav People} and search for mailing list users. - To edit lists, you'll now go to the list user's profile and use the options there. - General documentation on these users is available in **[[ https://secure.phabricator.com/book/phabricator/article/users/ | User Guide: Account Roles ]]**. **Upgrading**: When you upgrade, we'll attempt to migrate all your existing mailing lists and turn them into new "mailing list" users, then update all the things they're CC'd on to point at the new users. For the most part, the intent is that things will work automatically on their own. I've tried to make this relatively clean, but it won't be perfect because the mapping isn't perfect. Some things you may want to review after upgrading: - You might want to change the usernames we generate for the new list users. Because lists are now users, they must obey the rules for valid usernames -- notably, they may no longer contain `@` in their names. You can change usernames in {nav Edit Settings > Change Username}. - You may want to delete some lists completely. You can click "Delete User" on a profile for instructions, which will point you at how to use `bin/remove destroy` to delete the user. - If you have Herald rules which add mailing lists, they'll need to be updated to add the new list users instead. - If you have saved search queries which use mailing lists (this should be exceptionally rare), you'll need to update them manually. - If users add mailing lists from the CLI (for example, in `arc diff`), typing the full list address should still work, but using the list username may be simpler. - Some old transactions which referred to lists may no longer render correctly. Since I believe this is a minor cosmetic issue but would require a large amount of effort to fix, I don't currently intend to address it. **Motivation**: We're primarily closing a small hole in policy controls, described in T6367. Previously, when Alice did something which sent mail, we would always use Alice's settings and permissions to build that mail. Using the actor's settings meant that if Alice uses Phabricator in Spanish, Bob would receive mail about her actions in Spanish, even if Bob uses Phabricator in German. While amusing, this is undesirable. Using the actor's permissions meant that if Alice can see an object described in the mail (for example, a project which was added to a task), Bob will receive mail showing the project's name, even if he does not have permission to see the project. This rarely has much impact in practice, but still represents a violation of policy controls. To fix this problem, we'll soon build a mail message separately for each target, and use appropriate permissions and settings. This created a problem: the old standalone mailing lists did not have permissions, and there was no reasonable default permission set we could give them which would work well in many cases. Converting them into users allows them to be given policy access normally through projects, policies, and (in the future) Spaces. You can find more discussion of the context and motivation in T8387. **New Features**: Because mailing lists are now users, you can configure more settings for them in {nav People > Profile > Edit Settings}. In particular, you can now configure "Account" to choose a translation (this won't work today, but will after T6367 finishes), "Email Format" to send HTML mail, and "Email Preferences" to reduce the amount of mail sent to the list.

Phabricator allows users to add existing, external mailing lists (like a Google Group or a Mailman list) so mail can be sent to them. Often, these lists might have an address like `engineering-list@lists.mycompany.com`. Previously, Mailing Lists were a standalone application. The application has been removed, and mailing lists are now special users instead, similar to bot users. - To create a new mailing list, you'll now go to {nav People > Create New User} and select a "Mailing List" user. - To browse lists, you'll now go to {nav People} and search for mailing list users. - To edit lists, you'll now go to the list user's profile and use the options there. - General documentation on these users is available in **[[ https://secure.phabricator.com/book/phabricator/article/users/ | User Guide: Account Roles ]]**. **Upgrading**: When you upgrade, we'll attempt to migrate all your existing mailing lists and turn them into new "mailing list" users, then update all the things they're CC'd on to point at the new users. For the most part, the intent is that things will work automatically on their own. I've tried to make this relatively clean, but it won't be perfect because the mapping isn't perfect. Some things you may want to review after upgrading: - You might want to change the usernames we generate for the new list users. Because lists are now users, they must obey the rules for valid usernames -- notably, they may no longer contain `@` in their names. You can change usernames in {nav Profile > Change Username}. - You may want to delete some lists completely. You can click "Delete User" on a profile for instructions, which will point you at how to use `bin/remove destroy` to delete the user. - If you have Herald rules which add mailing lists, they'll need to be updated to add the new list users instead. - If you have saved search queries which use mailing lists (this should be exceptionally rare), you'll need to update them manually. - If users add mailing lists from the CLI (for example, in `arc diff`), typing the full list address should still work, but using the list username may be simpler. - Some old transactions which referred to lists may no longer render correctly. Since I believe this is a minor cosmetic issue but would require a large amount of effort to fix, I don't currently intend to address it. **Motivation**: We're primarily closing a small hole in policy controls, described in T6367. Previously, when Alice did something which sent mail, we would always use Alice's settings and permissions to build that mail. Using the actor's settings meant that if Alice uses Phabricator in Spanish, Bob would receive mail about her actions in Spanish, even if Bob uses Phabricator in German. While amusing, this is undesirable. Using the actor's permissions meant that if Alice can see an object described in the mail (for example, a project which was added to a task), Bob will receive mail showing the project's name, even if he does not have permission to see the project. This rarely has much impact in practice, but still represents a violation of policy controls. To fix this problem, we'll soon build a mail message separately for each target, and use appropriate permissions and settings. This created a problem: the old standalone mailing lists did not have permissions, and there was no reasonable default permission set we could give them which would work well in many cases. Converting them into users allows them to be given policy access normally through projects, policies, and (in the future) Spaces. You can find more discussion of the context and motivation in T8387. **New Features**: Because mailing lists are now users, you can configure more settings for them in {nav People > Profile > Edit Settings}. In particular, you can now configure "Account" to choose a translation (this won't work today, but will after T6367 finishes), "Email Format" to send HTML mail, and "Email Preferences" to reduce the amount of mail sent to the list.

Phabricator allows users to add existing, external mailing lists (like a Google Group or a Mailman list) so mail can be sent to them. Often, these lists might have an address like `engineering-list@lists.mycompany.com`. Previously, Mailing Lists were a standalone application. The application has been removed, and mailing lists are now special users instead, similar to bot users. - To create a new mailing list, you'll now go to {nav People > Create New User} and select a "Mailing List" user. - To browse lists, you'll now go to {nav People} and search for mailing list users. - To edit lists, you'll now go to the list user's profile and use the options there. - General documentation on these users is available in **[[ https://secure.phabricator.com/book/phabricator/article/users/ | User Guide: Account Roles ]]**. **Upgrading**: When you upgrade, we'll attempt to migrate all your existing mailing lists and turn them into new "mailing list" users, then update all the things they're CC'd on to point at the new users. For the most part, the intent is that things will work automatically on their own. I've tried to make this relatively clean, but it won't be perfect because the mapping isn't perfect. Some things you may want to review after upgrading: - You might want to change the usernames we generate for the new list users. Because lists are now users, they must obey the rules for valid usernames -- notably, they may no longer contain `@` in their names. You can change usernames in {nav Edit SettingsProfile > Change Username}. - You may want to delete some lists completely. You can click "Delete User" on a profile for instructions, which will point you at how to use `bin/remove destroy` to delete the user. - If you have Herald rules which add mailing lists, they'll need to be updated to add the new list users instead. - If you have saved search queries which use mailing lists (this should be exceptionally rare), you'll need to update them manually. - If users add mailing lists from the CLI (for example, in `arc diff`), typing the full list address should still work, but using the list username may be simpler. - Some old transactions which referred to lists may no longer render correctly. Since I believe this is a minor cosmetic issue but would require a large amount of effort to fix, I don't currently intend to address it. **Motivation**: We're primarily closing a small hole in policy controls, described in T6367. Previously, when Alice did something which sent mail, we would always use Alice's settings and permissions to build that mail. Using the actor's settings meant that if Alice uses Phabricator in Spanish, Bob would receive mail about her actions in Spanish, even if Bob uses Phabricator in German. While amusing, this is undesirable. Using the actor's permissions meant that if Alice can see an object described in the mail (for example, a project which was added to a task), Bob will receive mail showing the project's name, even if he does not have permission to see the project. This rarely has much impact in practice, but still represents a violation of policy controls. To fix this problem, we'll soon build a mail message separately for each target, and use appropriate permissions and settings. This created a problem: the old standalone mailing lists did not have permissions, and there was no reasonable default permission set we could give them which would work well in many cases. Converting them into users allows them to be given policy access normally through projects, policies, and (in the future) Spaces. You can find more discussion of the context and motivation in T8387. **New Features**: Because mailing lists are now users, you can configure more settings for them in {nav People > Profile > Edit Settings}. In particular, you can now configure "Account" to choose a translation (this won't work today, but will after T6367 finishes), "Email Format" to send HTML mail, and "Email Preferences" to reduce the amount of mail sent to the list.