Change Details

Let's define the case of the Security project mentioned at T3820. The strong case for this feature are open source projects, who don't have the //luxury// of operating in an intranet accessed by users covered by NDAs. Because open source projects are really open, they really need private areas to handle sensitive information. The following use cases are extracted from Wikimedia's Bugzilla workflow for security issues. I'm calling the project and team "Security", but the same would be applied to other areas like i.e. procurement. * A Security product only visible to the Security team (supported in Phabricator) * A task created for the Security project could not bypass the project policies, e.g. nobody can create accidentally a task for the Security project that is "Visible to all". * When a task reported elsewhere is moved to the Security project, the reporter and anyone CCed still can see this specific task without joining the Security team, they can post comments, and they will keep receiving the related notifications. ** In Bugzilla you can only choose one product for a task, maybe in Phabricator we wouldn't talk about "moving"but about "adding" and "removing" the Security project to a task. * When a task is solved, it is moved out from the Security project to wherever appropriate, becoming visible to all users. * "//A handful of times each year, someone reports private data as part of a security bug (IP addresses, etc). We need to be able to make those specific comments invisible, or be able to delete them//", our Security expert says. The data should not be visible in some diff either. Since these are rare situations, if developing a UI for this would be expensive, a hackish-backend solution would be fine. Related use cases that would allow us to solve more problems: * Members of the Security team can add manually other users in CC, to give them access to a specific task in the Security project, allowing them to receive notifications as well (supported, I guess). * Registered and non-registered users can report tasks for the Security project via email. * Registered and non-registered users can comment to tasks for the Security project via email, after receiving the email address from the Security team.

Let's define the case of the Security project mentioned at T390 and T3820. The strong case for this feature are open source projects, who don't have the //luxury// of operating in an intranet accessed by users covered by NDAs. Because open source projects are really open, they really need private areas to handle sensitive information. The following use cases are extracted from Wikimedia's Bugzilla workflow for security issues. I'm calling the project and team "Security", but the same would be applied to other areas like i.e. procurement. * A Security product only visible to the Security team (supported in Phabricator) * A task created for the Security project could not bypass the project policies, e.g. nobody can create accidentally a task for the Security project that is "Visible to all". * When a task reported elsewhere is moved to the Security project, the reporter and anyone CCed still can see this specific task without joining the Security team, they can post comments, and they will keep receiving the related notifications. ** In Bugzilla you can only choose one product for a task, maybe in Phabricator we wouldn't talk about "moving" but about "adding" and "removing" the Security project to a task. * When a task is solved, it is moved out from the Security project to wherever appropriate, becoming visible to all users. * "//A handful of times each year, someone reports private data as part of a security bug (IP addresses, etc). We need to be able to make those specific comments invisible, or be able to delete them//", our Security expert says. The data should not be visible in some diff either. Since these are rare situations, if developing a UI for this would be expensive, a hackish-backend solution would be fine. Related use cases that would allow us to solve more problems: * Members of the Security team can add manually other users in CC, to give them access to a specific task in the Security project, allowing them to receive notifications as well (supported, I guess). * Registered and non-registered users can report tasks for the Security project via email. * Registered and non-registered users can comment to tasks for the Security project via email, after receiving the email address from the Security team.

Let's define the case of the Security project mentioned at T390 and T3820. The strong case for this feature are open source projects, who don't have the //luxury// of operating in an intranet accessed by users covered by NDAs. Because open source projects are really open, they really need private areas to handle sensitive information. The following use cases are extracted from Wikimedia's Bugzilla workflow for security issues. I'm calling the project and team "Security", but the same would be applied to other areas like i.e. procurement. * A Security product only visible to the Security team (supported in Phabricator) * A task created for the Security project could not bypass the project policies, e.g. nobody can create accidentally a task for the Security project that is "Visible to all". * When a task reported elsewhere is moved to the Security project, the reporter and anyone CCed still can see this specific task without joining the Security team, they can post comments, and they will keep receiving the related notifications. ** In Bugzilla you can only choose one product for a task, maybe in Phabricator we wouldn't talk about "moving" but about "adding" and "removing" the Security project to a task. * When a task is solved, it is moved out from the Security project to wherever appropriate, becoming visible to all users. * "//A handful of times each year, someone reports private data as part of a security bug (IP addresses, etc). We need to be able to make those specific comments invisible, or be able to delete them//", our Security expert says. The data should not be visible in some diff either. Since these are rare situations, if developing a UI for this would be expensive, a hackish-backend solution would be fine. Related use cases that would allow us to solve more problems: * Members of the Security team can add manually other users in CC, to give them access to a specific task in the Security project, allowing them to receive notifications as well (supported, I guess). * Registered and non-registered users can report tasks for the Security project via email. * Registered and non-registered users can comment to tasks for the Security project via email, after receiving the email address from the Security team.