Allow kanban/project board to set labels on column switch

[KlavsKlavsen]

Feature Description

It would be great if the gitea kanban board columns could be configured to set/clear labels on issues.
F.ex. if I have 3 columns:
uncategorized(default), in-progress, resolved
tasks all show up in "uncategorized" by default.
If I could configre on "in-progress" column that it set label "in-progress" (and cleared other 'column labels' - then I could use issue-filtering f.ex. - to easily find all issues in-progress.. (and if I use same column labels across projects - I could find issues across org in same state.
If I then drag the issue to "resolved" - then I could set it to set "resolved" label - and again clear "other column labels" - so it would remove "in-progress" label automaticly too - and I could also set it to "close task" in the resolved column (so it would disappear - as its done).

It should be fairly simple to implement - and would make it possible for anyone to build any "state system" they wanted, using labels - and keeping gitea simple still.

Screenshots

No response

[delvh]

So, if I understand it correctly, you basically want something similar to #14359?
The only difference would be when the automation happens: In your case, it happens when moving an issue in the project instead of when opening/closing/… a PR.
That's absolutely on the plan, simply no one has implemented it yet.
But I do see that we need to strictly define what types of automation are possible before implementing anything.

[KlavsKlavsen]

No. Its actually the reverse. What I am suggesting is that you manipulate the tickets state by dragging it "left or right" - ie. between columns on kanban board. This is how it works in Jira, Redmine and other kanban boards.
As I read #14359 - its about changing an issues state - based on externals.. (PR merges etc.) - and thats all fine - and could work very well with what I propose.

In redmine and jira f.ex. - one can build very advanced workflows - as one needs to - so issues can have as many "states" as one wants.

AFAIK gitea does not want to replicate such advanced behavior - and thats why I instead suggest the flexibile solutions of allowing "automatic label add/remove" when issues are moved between columns (and auto resolve/reject - on columns set to do that).

If this is done - then one could solve #14359 by simply adding/removing labels - so it is then shown in the "right coulmn" on kanban board - if thats what you want to do.

[ojohnny]

I actually started a bit on #14359 last week, and in my PoC I support triggering an action (e.g. add a label) when issues are moved between columns (among other triggers/actions, such as moving the ticket when it gets a specific label).

So if that is the way we want to go then I think this could be satisfied by #14359. I think this discussion serves as good input for the UX for project board automation though.

Edit: To clarify, I think an exclusive label set (only one label in the set can be active) used in combination with a "add label when issue is moved to this column" automation rule would satisfy the requirements of this issue.

[KlavsKlavsen]

its important you also remove label though
and you need to know which labels to remove (ie. those that is set by other columns in same board only).. it does not sound like your approach will handle that very well?

So I still think its two different things.. my idea is "about labels used/managed" by a kanban board - and won't work as "general issue automation".. But your ideas are cool and gives entirely different benefits that would well together with the "label=column"-correlation

[ojohnny]

its important you also remove label though
and you need to know which labels to remove (ie. those that is set by other columns in same board only).. it does not sound like your approach will handle that very well?

If you use Scoped labels with the Exclusive flag set, then the label will automatically be removed when another label in the same scoped label set is added. So if you create a scoped label set with one label per column in your board and mark the exclusive flag then it would be automatically handled by the label system.

Other than that, removing a label is just another action, but might be more complicated for the user to setup.

[KlavsKlavsen]

@ojohnny Fantastic - loving scoped labels - that saves me a lot of headache. With that - then yes - a system of rules that enables me to "set a label on issue if it changes kanban column" would solve it (as the exclusive part would clear other labels of same scope)

[KlavsKlavsen]

I still believe this "label" per column - really should be part of kanban - so you just simply set it as part of optional column config (set label: x)

[MathewBiddle]

+1

I still believe this "label" per column - really should be part of kanban - so you just simply set it as part of optional column config (set label: x)

[neilvandyke]

I loved using a feature like this (Board columns determined by Scoped Labels) in GitLab, for lightweight Kanban-ish project management.

An additional reason that Board columns linked to Labels was nice was that column changes in project management created entries in the Issue's chronological history view.

That reflection in Issue history is also a reason for the use of labels for board columns to be optional. Since I can imagine use cases in Gitea for Project boards, in which the user doesn't want to have to use Labels, and -- perhaps more importantly -- doesn't want the noisy shuffling of tasks around a board to be shown in an Issue's history page. For example, imagine a speculative what-if exercise, about pivoting a product, or re-tasking a team, done with a board.)

[stack-one-tech]

+1 😄

That would be amazing!

[KlavsKlavsen]

We implemented it as a PR (and it works great for us).. but we have not been able to get a clear idea of what needs to be fixed in our PR for it to be merged :(

#28745

[lunny]

@KlavsKlavsen Thank you for your pull request. Firstly, that pull request needs a database migration, see #28745 (comment). A column was added but without migration will break some old database when upgrading.
Another thought is that I think your pull request will be replaced by #30205 because it's more flexible. I will continue the work on #30205 and bring it to v1.24. Sorry for the unclear review on that pull request. Please let me know if you have different idea.

[silkentrance]

@lunny @KlavsKlavsen since this is going to be a part of the project workflow feature, is this still an open issue or will it be resolved by #30205?

[lunny]

@lunny @KlavsKlavsen since this is going to be a part of the project workflow feature, is this still an open issue or will it be resolved by #30205?

I will resolve this in #30205