Add the column movement information on the timeline of the Issue detail page. #11729

New Issue

GiteaMirror · 2025-11-02T09:46:04-06:00

GiteaMirror commented

2025-11-02 09:46:04 -06:00

Originally created by @qihangnet on GitHub (Sep 26, 2023).

Feature Description

We rely on Gitea’s Projects feature for actual project management. However, we are currently unable to see the changes in the project column from the timeline on the issue details page. In other words, we cannot see when and by whom an issue was moved from one column to another. This is causing confusion in our project management.

I think if this feature is added, “Projects” will become more useful and benefit more Gitea users.

Screenshots

No response

Originally created by @qihangnet on GitHub (Sep 26, 2023). ### Feature Description We rely on Gitea’s Projects feature for actual project management. However, we are currently unable to see the changes in the project column from the timeline on the issue details page. In other words, we cannot see when and by whom an issue was moved from one column to another. This is causing confusion in our project management. I think if this feature is added, “Projects” will become more useful and benefit more Gitea users. ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 09:46:04 -06:00

GiteaMirror closed this issue

2025-11-02 09:46:04 -06:00

GiteaMirror commented

2025-11-02 09:46:05 -06:00

@mjb8086 commented on GitHub (Dec 15, 2023):

+1 on this. So I have several columns set up in the project management view, it would be better if the ticket's status would take its status from the project management columns.

I.e. if I drag it from the Backlog to 'In Progress' it becomes 'In Progress', and if I move it to testing it would show 'Testing' but currently it will always say 'Open' - even though that isn't realistically the status.

Or, even just add another badge beside 'Open' that shows the column name.

@mjb8086 commented on GitHub (Dec 15, 2023): +1 on this. So I have several columns set up in the project management view, it would be better if the ticket's status would take its status from the project management columns. I.e. if I drag it from the Backlog to 'In Progress' it becomes 'In Progress', and if I move it to testing it would show 'Testing' but currently it will always say 'Open' - even though that isn't realistically the status. Or, even just add another badge beside 'Open' that shows the column name. ![Screenshot 2023-12-15 at 22 35 03](https://github.com/go-gitea/gitea/assets/63065906/92f14bde-3ceb-4d1e-9a3a-aa212cbb9d12) ![Screenshot 2023-12-15 at 22 35 21](https://github.com/go-gitea/gitea/assets/63065906/b0ae8ef3-05cb-41c4-89ba-cba844f0bf95)

GiteaMirror commented

2025-11-02 09:46:05 -06:00

@bilogic commented on GitHub (May 9, 2024):

I.e. if I drag it from the Backlog to 'In Progress' it becomes 'In Progress', and if I move it to testing it would show 'Testing' but currently it will always say 'Open' - even though that isn't realistically the status.

Not sure if I understood you correctly, but I use open/close as a "verified" field, i.e. when it lands in the completed board, open means no one has verified that it is indeed completed and close means someone else other than the user who moved it there has verified that it is completed

So, open and close has a use case, i.e. does it require further attention?

Don't remove it please haha, adding is fine.

@bilogic commented on GitHub (May 9, 2024): > I.e. if I drag it from the Backlog to 'In Progress' it becomes 'In Progress', and if I move it to testing it would show 'Testing' but currently it will always say 'Open' - even though that isn't realistically the status. Not sure if I understood you correctly, but I use open/close as a "verified" field, i.e. when it lands in the `completed` board, `open` means no one has verified that it is indeed `completed` and `close` means someone else other than the user who moved it there has verified that it is `completed` So, open and close has a use case, i.e. does it require further attention? Don't remove it please haha, adding is fine.

GiteaMirror commented

2025-11-02 09:46:06 -06:00

@qihangnet commented on GitHub (May 9, 2024):

I think a better way is to trigger state changes through rule-based mechanisms rather than fixed logic.

@qihangnet commented on GitHub (May 9, 2024): I think a better way is to trigger state changes through rule-based mechanisms rather than fixed logic.

GiteaMirror commented

2025-11-02 09:46:06 -06:00

@bilogic commented on GitHub (May 9, 2024):

I recently started looking into event sourcing, that might be a better way to implement all these tracking activities

@bilogic commented on GitHub (May 9, 2024): I recently started looking into event sourcing, that might be a better way to implement all these tracking activities

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11729