[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.

[JVimes]

I'd also like to see dragging to last column close the issue. Keeping it in sync both directions applies to certain types of columns. Maybe special "closed" column type.

[ojohnny]

I have started working on this to add support for having multiple automation rules per project, where each rule basically has a trigger (e.g. this specific label was added to an issue in the project) and an action (e.g. move the issue to the In Progress column), and if the rule is applicable to issues, pull requests, or both. I have also added some kind of protection against "bad logic" in that each rule will only be executed at most once per "trigger chain", so infinite loops of actions is not possible.

I'm currently contemplating if we want one (optional) condition entry on each rule as well (e.g. only execute rule if issue is not closed/has this specific label/etc), but we could probably add that later if we need it as well.

Should I create a PR with the "backend parts" separately before starting working on being able to setup custom rules in the frontend?

I'm thinking of starting out with being able to configure the automation rules for "Basic Kanban" in app.ini and adding an "Automated Kanban" entry to the project template selection as some kind of "step one" for this feature, and that setting up custom rules per project in the UI could be in a future PR.

My weekend is quite booked, but perhaps I could focus on creating a PR next weekend or so.^{(famous last words)}

[KlavsKlavsen]

Hows PR coming.. anything we can maybe chip in on to help?

[ojohnny]

Hows PR coming.. anything we can maybe chip in on to help?

Life got a bit busy and I am currently moving 🙃 I have something that I think is working but would probably need to be a bit cleaned up / restructured before being merged. I can see if I can push what I have done so far as a draft PR, seeing as I wont have much time to continue working on it for at least a week.

[KlavsKlavsen]

Yeah - life has a tendency to do that :)

[ojohnny]

I created a PR now with what I have managed to do so far, feel free to play around with it and provide feedback :) Note that the feature is locked behind a configuration and is by default off.

Sorry for the delay.

[jwildeboer]

Idea for a simpler approach:

Auto-mapping between column names in the kanban and labels for an issue. Meaning that when you have column names like Backlog, Ready, Doing, Done you'd also have the same names as label for an issue (with the exclusive function, so map to a label called $PROJECTNAME/$COLUMNAME).

This way the workflow and implementation becomes really simple. When you change the label on an issue, it automagically moves the issue on the kanban and the other way round - when you move an issue on the kanban, it automatically sets the label for the issue.

When you add or change the name of a column in the kanban, you also add or change the name of the label in the background.

Maybe make it one-way only to stick to the typical flow: you cannot change the label on the issue itself, only via kanban. But that should be all. No complicated rulesets, just simple mapping between column names and issue labels.

[KlavsKlavsen]

@jwildeboer thats the exact approach I suggested previously :) IMHO it should be enabled with a setting on kanban/project to "sync to label" - and you could then just set the label "per column"..
We use status/ - and have set them to be exclusive, so duplicates are not allowed :) - and would be great if just moving the issue in kanban, added the corresponding label.

We are trying to make the current PR for a more "generic approach" working though.

[revoio]

+1

thank you @ojohnny for #27835. but it sounds it's blocked :(

[KlavsKlavsen]

@jwildeboer we implemented the simpler approach here: #28745 - it works great for us, and we'll gladly adjust whats needed to get it merged :)

[lunny]

This is what Github's project workflow configuration looks like.

[KlavsKlavsen]

@lunny yes - thats the much more advanced and flexible approach "do anything".. that we don't really have a need for.. we just need the simple default for kanbans that is there in redmine, jira etc. - that issue gets "resolved" when moved to "closing column" and that labels are applied to match the column its in (so its clear on issue - which kanban column its in - instead of today where gitea has no such data on issue). (labels is our proposal to indicate the placement in kanban column).

[lunny]

@lunny yes - thats the much more advanced and flexible approach "do anything".. that we don't really have a need for.. we just need the simple default for kanbans that is there in redmine, jira etc. - that issue gets "resolved" when moved to "closing column" and that labels are applied to match the column its in (so its clear on issue - which kanban column its in - instead of today where gitea has no such data on issue). (labels is our proposal to indicate the placement in kanban column).

I'm working on #30205 which will store the events and actions on a yaml file but do similar things like GH did.