<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=16565) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=16565) </details> <!--IssueSummary end--> When you have an active todo for a target (typically an issue or an MR), you won't get a new todo for that same event. However, it would be very handy to know: 1. How many times todo-creating events have been issued on that target. (In general, the higher, the more important.) 2. Which todo was most recently bumped. 3. If a todo of a 'regular' type (mention) was later superseded by an 'important' type (build failed, assigned, etc.). This means that we could allow sorting todos on `updated_at`, but we'd also show the todo if a filter on type matched _any_ of the types in the sub-todo / todo events table. I think we could use some gitlab-ce~2024184 here, but I understand how the backend would work, at least :slight_smile: @pedroms and @dbalexandre, what do you think? This replaces https://gitlab.com/gitlab-org/gitlab-ce/issues/23293.