User Activity report: "Tickets Assigned" column filters by ticket creation date, not assignment date #49
Closed
opened 2026-08-31 21:36:17 -04:00 by jared
·
1 comment
No Branch/Tag Specified
main
development
fix/comment-markdown-persist-18
deploy-2026.10.03-279
deploy-2026.10.03-275
deploy-2026.09.26-272
deploy-2026.09.25-268
deploy-2026.09.25-264
deploy-2026.09.24-258
deploy-2026.09.24-254
deploy-2026.09.12-242
deploy-2026.09.12-238
deploy-2026.09.12-234
deploy-2026.09.12-230
deploy-2026.09.12-226
deploy-2026.09.12-222
deploy-2026.09.11-218
deploy-2026.09.11-214
deploy-2026.09.11-210
deploy-2026.09.11-206
deploy-2026.09.11-202
deploy-2026.09.11-198
deploy-2026.09.11-194
deploy-2026.09.11-190
deploy-2026.09.11-186
deploy-2026.09.09-182
deploy-2026.09.09-178
deploy-2026.09.08-172
deploy-2026.09.01-163
deploy-2026.08.08-155
deploy-2026.08.08-151
deploy-2026.08.08-147
deploy-2026.08.08-143
deploy-2026.08.08-139
deploy-2026.07.15-130
deploy-2026.07.15-122
deploy-2026.07.11-107
deploy-2026.06.30-96
deploy-2026.06.30-92
deploy-2026.06.30-88
deploy-2026.06.30-84
deploy-2026.06.30-80
deploy-2026.06.30-76
deploy-2026.06.30-72
deploy-2026.06.30-68
deploy-2026.04.29-49
deploy-2026.04.29-41
deploy-2026.04.18-35
deploy-2026.04.16-31
deploy-2026.04.16-27
deploy-2026.04.16-23
deploy-2026.04.16-11
deploy-2026.04.14-9
Labels
Clear labels
api
bug
concurrency
config
data-integrity
dead-code
documentation
duplicate
enhancement
help wanted
invalid
needs-decision
notifications
performance
priority/docs
priority/high
priority/low
priority/medium
question
rate-limiting
reliability
security
ux
wontfix
workflow
Bearer/internal API surface
Something is not working
Race condition / concurrency bug
Configuration / deployment default
Data correctness / schema / integrity issue
Unused / dead code cleanup
README / docs accuracy
This issue or pull request already exists
New feature
Need some help
Something is wrong
Needs a maintainer decision, not clearly a bug
Matrix / in-app notification bug
Performance or resource-usage concern
Documentation-only gap
High-severity / high-impact issue
Low-severity / cosmetic issue
Medium-severity issue
More information is needed
Rate limiting behavior
Reliability / error-handling gap
Security or access-control impact
User-facing UX/functional bug
This won't be fixed
Ticket status workflow engine
Milestone
No items
No Milestone
Projects
Clear projects
No projects
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: LotusGuild/tinker_tickets#49
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: Medium
index.php(~lines 385-390), thetasubquery for the User Activity report:SELECT assigned_to, COUNT(*) ... FROM tickets WHERE DATE(created_at) BETWEEN ? AND ? GROUP BY assigned_to.Impact: A ticket created outside the selected date range but assigned to a user within it won't count toward "Tickets Assigned"; conversely a ticket created inside the range but assigned/reassigned later still counts as if the assignment happened in-range. The column is filtered by the wrong date field for what it claims to measure, producing a misleading metric on
/admin/user-activity.Fix: If assignment date isn't tracked separately, either add an
assigned_attimestamp column, derive it fromaudit_logassignment events, or relabel the column to clarify it's actually measuring tickets created-and-assigned-to in the range.Fixed in commit
80169de(merged to main in786674a).The 'Tickets Assigned' column filtered by tickets.created_at, so a ticket created outside the selected date range but assigned to a user within it never counted, while one created in-range but assigned/reassigned later counted as if the assignment happened in-range.
tickets has no assigned_at column, so the count is now derived from audit_log's 'assign' events (already logged by both the single-ticket and bulk-assign paths), filtered by the event's own created_at. COUNT(DISTINCT entity_id) so a ticket reassigned more than once to the same user within the range still counts once.
Verified against real MariaDB: seeded one ticket created outside the test range but assigned inside it, and one created inside the range but assigned outside it. The old query counted the wrong one; the new query correctly flips to count the one actually assigned within the range.