Issues receiving team comments are showing up in the Needs Triage column

[jeffhandley]

When a team member comments on or otherwise updates an issue, the fabricbot config is adding the issue to the issue triage board if it's not already on the board. We did not intend for actions taken by a team member to cause an issue to show up in the Needs Triage column, but this is happening for issues that weren't previously on the board. Here's an example:

dotnet/runtime#27509 (comment)

In that example, when the issue was closed by a team member, it was added to the Needs Triage column. The cause of this is similar to #5 where we have the Needs Triage column configured as the To do preset and the Triaged column as the Done preset. There's a conflict here where the GitHub project board automation moves the item into the Needs Triage column by default and the automation to move to Triaged does not fire. To work around this, we will need to move away from the project board automation presets and instead configure FabricBot to prevent the item landing in the wrong column, or use a scheduled search to move items to the Done column if closed.

[jeffhandley]

I'm leaning toward abandoning the project board automation. Especially with #3 in mind, we'll need a pattern for the logic that determines which column an item should go into when it simultaneously needs to be added to the board and moved into a column.

[jeffhandley]

The root cause is our logic around checking if the user doesn't have "write" permission. It turns out the permission checks are for "at most" instead of "at least." That means a user that has admin or maintain permissions will not match the "has write permission" condition. And we also need to consider triage permission here too.

We will be able to invert our "has write permission" condition to "does not have read permission" though, as that would mean the user has at most Read permission, which includes external contributors not part of any team.

[ghost]

jeffhandley has "Admin" permissions