[Feature] Add automated project board

[delvh]

Description

GitHub has a feature for projects that automatically get updated when certain events occur.
This is in my opinion one of the most requested features to be added for project boards, as it saves a lot of time, when all issues are automatically categorized correctly.
In the end, a mechanism similar to that GitHub is using should be implemented.
By that I mean:

1. all issues start in the Uncategorized/To do category when they are created (as far as I know that was recently implemented, maybe a week ago)
2. once a branch is opened aimed at fixing the issue, the issue gets moved to In progress (here, Gitea can track that even better than GitHub because GitHub only looks for whether someone has been assigned to the issue if I'm not mistaken) EDIT: Okay, my memory seems to have betrayed me. As it seems, users have to manually add an issue into the In Progress board. That can be improved here as Gitea stores branches related to issues.
   2a) When the branch gets closed without merging, or when someone removes the affiliation between branch and issue manually (drop down menu in issues view (clear references)), the issue gets sent back into Uncategorized/To do.
   2b) If a PR exists wanting to fix the issue, and the underlying branch gets deleted, the PR should also be added into Done/Not worked on (see 6.)
   2c) When testing this, I noticed a little bug: When an issue has a branch assigned and the branch gets deleted without merging, the issue will still think it depends upon the non-existing branch.
3. As soon as a PR gets opened, the issue gets moved into Under Review (Review in progress). The PR automatically gets added to the given project as we can assume that a PR for a specific issue is meant for the same project into the same category as the issue - if this is one of the rare cases where this is not the case, the user should manually move it themselves…
4. Once the PR is ready to get merged, the issue (and the PR?) get moved into Approved.
5. When the PR is closed (and the issue with it) they get both moved into Done
6. If an issue/ PR is closed without merging/ fixing, they might automatically be moved into
   a) Done - if we say they have been closed so they should be treated as a normal closed issue
   b) Not worked on - if we say that while they might be closed, they should somehow be marked as closed but not because it was fixed
   (the choice here is up to the person(s) implementing it)

All of this can be added as a separate menu item Automated KanBan in the Create Project dialogue.

Graphically, I'd say we can orient on the design GitHub chose in combination with the currently available project boards.

To keep this branch at least somewhat "small", I'd suggest that adding a Manage button for each automated board (see Screenshot below) should be postponed for later.
For now, it should suffice if users delete and recreate a project (board) if they don't want it automated anymore.

Screenshots

Current design used by GitHub:

[DominiqueFuchs]

Hi,

I was about to open a proposal issue, then I saw this one from the kanban plans in #14710.

I'd like to see some automation regarding the addition and removal of labels mapping the board/column names, eg.

• Drag issue to 'To Do' board, a corresponding 'To Do' label is added. Same holds for all other boards.
• Likewise, labels matching a board name get removed that when an issue is dragged away from a board.

I'm not sure if Github or GitLab does this, but I remember at least one if them doing it that way and it felt just natural.

This could either be implemented as an activation on board-level (ellipses menu: checkbox 'automatic board label' or similar) or as a project setting aka 'use automatic labels'.

After thinking a bit about this after reading about your plans here, I think these are different things. While the fully-automated boards would be rather managed by code actions (and the board itself is a mere reflection of the current state), my proposal is for pro-active kanban usage.

The reason why I think this would be useful is that workflows are different and often (at least here on my side) the are no actual code changes (immediately) even though there is active work going on behind the scenes. Even simpler, this could just be someone grepping an issue because she has actively blocked some time next week to get it done. Thus, she would put it on "in progress" (and removing 'to do' because then no one else filtering on 'to do' issues would considering this, too).

What do you think about this?

[eeyrjmr]

This would be a really good addition.
Right now the kanban are a sort of "for indication purposes only" and unless some wrangler actually reviews the board and moves items around it can just sit there.

At the very least closed issues should be migrated to a "done" column while some stretch goal of automated workflow would be great (driven by tags?)

[flipkickmedia]

If Gitea is to be used in Agile/Sprints, typically the developer might see what was left to do on the board, and drag the item, rather than the other way round by adding a label.

It might be a good idea, to allow labels to progress the item, and the kanban to add labels when an item is moved from one column to the next.

In QA, once the item is in the done column (developer done) labels could then be used to tag items in PR which don't pass QA.

If your PR process does not include QA and this is done after the PR is approved, again labels or columns could be used to allow the code to be merged.

[boomam]

I think this could be worth adding - having the option there to allow automation of issues/etc. based on a teams preference would go a long way to improving the potential for productivity, and at the least, bringing feature parity with the other git platforms.
An example for myself would be that when things get a specific label, or specific milestone, that they are automatically able to be moved, tagged, etc. to another board.