Change Details

Currently you can only add a project by herald, but not remove it. The detailed rules and options in herald could allow a nice automatic project sorting on incoming tasks, thus a rule showing a status "X" (like closed) is reached, the task could be unassigned from an issues navigation project by an herald rule.

Currently you can only add a project by herald, but not remove it. The detailed rules and options in herald could allow a nice automatic project sorting on incoming tasks, thus a rule showing a status "X" (like closed) is reached, the task could be unassigned from an issues navigation project by an herald rule. Use case: {F378195} This is meant to result in three different projects managing the issues. (As they will stay open over the whole lifecycle they should not clutter the workboards of the other teams. Issue navigation does not need to see them anymore, when they are waiting for development or in quality assurance stepping.) {F378198} This is meant to be a flexible and modular team design, all reports go into an issue navigation team then get their special status like "Development: Game" "Development: Web" "Development: API" "Development: Registry" "Support: Sales" "Support: Tech" "Support: General" And thus assigned their project, and also UN-assigned the issue navigation. (So the navigator has the "status" as central tool to navigate them, and herald picks them up in that status and adjusts assigned projects. A "commit comment" then closes the issue, depending on project herald could then forward this to a "quality assurance team", that will look into the issue again. This may be wanted in all functional situations, while working on a customer support task, this review may not make sense, and herald could just leave it in that final closed state. - Andy (just read the feature request guidelines, and added our specific use case) T7848 is also related to this, as a triggered status change could bypass the "resolve by commit needs a closed status" and selectively can reopen and sent tasks to specific "projects/groups/teams" to handle them.

Currently you can only add a project by herald, but not remove it. The detailed rules and options in herald could allow a nice automatic project sorting on incoming tasks, thus a rule showing a status "X" (like closed) is reached, the task could be unassigned from an issues navigation project by an herald rule. Use case: {F378195} This is meant to result in three different projects managing the issues. (As they will stay open over the whole lifecycle they should not clutter the workboards of the other teams. Issue navigation does not need to see them anymore, when they are waiting for development or in quality assurance stepping.) {F378198} This is meant to be a flexible and modular team design, all reports go into an issue navigation team then get their special status like "Development: Game" "Development: Web" "Development: API" "Development: Registry" "Support: Sales" "Support: Tech" "Support: General" And thus assigned their project, and also UN-assigned the issue navigation. (So the navigator has the "status" as central tool to navigate them, and herald picks them up in that status and adjusts assigned projects. A "commit comment" then closes the issue, depending on project herald could then forward this to a "quality assurance team", that will look into the issue again. This may be wanted in all functional situations, while working on a customer support task, this review may not make sense, and herald could just leave it in that final closed state. - Andy (just read the feature request guidelines, and added our specific use case) T7848 is also related to this, as a triggered status change could bypass the "resolve by commit needs a closed status" and selectively can reopen and sent tasks to specific "projects/groups/teams" to handle them.