Opened on 05/18/2017 at 02:27:27 PM
Closed on 08/29/2019 at 05:43:52 PM
#5259 closed change (rejected)
[emscripten] Implement hit counts functionality
Reported by: | trev | Assignee: | |
---|---|---|---|
Priority: | P5 | Milestone: | |
Module: | Core | Keywords: | closed-in-favor-of-gitlab |
Cc: | Blocked By: | #5137, #5258 | |
Blocking: | #4122 | Platform: | Unknown / Cross platform |
Ready: | no | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description
Background
In #5137 we only implemented the basics of the current FilterStorage API, with hit count logic being left out. However, we want to improve the API rather than merely reimplement it.
What to change
- Make ActiveFilter.hitCount and ActiveFilter.lastHit read-only properties. The setters should be replaced by ActiveFilter.increaseHitCount() and ActiveFilter.resetHitCount() methods. As ActiveFilter.lastHit can no longer be updated separately from ActiveFilter.hitCount, the filter.lastHit notification should be removed.
- The ActiveFilter.increaseHitCount() method replaces current FilterStorage.increaseHitCount() method and needs to respect savestats preference. For that, expose a FilterStorage.statsEnabled property that will be synced with the preference by the JavaScript code - if this property is set to false calls to FilterStorage.increaseHitCount() shouldn't have any effect.
- The FilterStorage.resetHitCounts() method should no longer take a parameter, it is only to be used when hit counts for all filters need to be reset.
Attachments (0)
Change History (4)
comment:1 Changed on 10/12/2017 at 10:21:51 AM by trev
- Blocked By 5258 added
comment:2 Changed on 10/13/2017 at 10:42:23 AM by trev
- Priority changed from P2 to P5
- Ready unset
comment:3 Changed on 12/21/2017 at 10:58:29 AM by trev
- Owner trev deleted
comment:4 Changed on 08/29/2019 at 05:43:52 PM by sebastian
- Keywords closed-in-favor-of-gitlab added
- Resolution set to rejected
- Status changed from new to closed
Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.
Note: See
TracTickets for help on using
tickets.
Actually, we no longer have any consumers for that part of the API. While there are plans for a new issue reporter, it only needs a hit notification and no statistics. And there is currently no UI design that would involve hit counts. So this feature is probably better off delayed until a time when we actually want to use it.