RFC: Omit specific ticket events from the default timeline view
(1.2) By george on 2022-12-10 21:05:26 edited from 1.1 [link] [source]
I'd like to treat some ticket modifications as supplementary - such that convey information which is usually uninteresting on its own. For better neatness/usability I'd like to hide these ticket events from the default timeline view.
I suggest to add the "Visibility" option to the /tktsetup_timeline page.
This option would hold SQL expression that may use columns of the TICKET table
(and also TICKETCHNG table if implementing it is viable).
A particular ticket event is listed within the default timeline only if
that expression evaluates to TRUE (or any positive integer).
If that option is unset or "Unhide" checkbox in the submenu is checked
then this visibility filtering is not applied.
IMO, this feature may open the way for the use of ticketing subsystem as a more general-purpose distributed key-value store which is usable from within a browser (think of distributed polls, artifacts signing and so on).
ADDENDUM:
Perhaps there is an alternative mechanism: apply "hidden" tag to specific tickets and decide presentation based on that. Not sure if that way is easier to implement or more future-proof.
(2) By Warren Young (wyoung) on 2022-12-10 23:57:00 in reply to 1.2 [link] [source]
This seems to have a strange resonance with the private branch mechanism, which we've now reused as part of the forum moderation feature.
Maybe your addition can share the same basic mechanisms, where marking a ticket change as "visible" does the same thing as a moderator approving a post.
Until then, it doesn't sync, and unprivileged users can't see it.
(3) By george on 2023-01-22 19:35:09 in reply to 1.2 [link] [source]
The implementation is relatively simple and straightforward.
It is in tkt-hidden-expr branch.
Unlike private branches or moderation (which control the flow of artifacts)
it amends only the appearance of the /timeline
and may be independently configured for different replicas.
I would like to merge it into trunk. Are there any objections?
(4) By Warren Young (wyoung) on 2023-01-22 21:21:13 in reply to 3 [link] [source]
For me, it depends primarily on how trustworthy that %z is at making arbitrary SQL safe.
I expanded the context in the diff up several times in timeline.c and I don't see any DB locking going on. Can this SQL affect any table or just a selected subset?
(5) By Stephan Beal (stephan) on 2023-01-22 22:20:15 in reply to 3 [source]
I would like to merge it into trunk. Are there any objections?
i find myself asking a question Richard has often asked over the years: what problem does this solve? Why/how is it useful to filter a very specific set of tickets from the timeline view? The timeline is there to keep people aware of what's going on, and hiding information from it reduces that capability. As the saying goes: "out of sight, out of mind." (For the record: i have always objected to features which hide timeline entries from view. It has always seemed like an unnecessary capability to me.)
From the original post:
IMO, this feature may open the way for the use of ticketing subsystem as a more general-purpose distributed key-value store which is usable from within a browser (think of distributed polls, artifacts signing and so on).
That the filter is SQL makes me nervous. Security concerns aside, a single SQL expression is not enough to sanely capture arbitrary complexity for arbitrary artifact types, and adding such an expression setting for each desired type would eventually get somewhat messy. Making the ticket system an arbitrary key/value store sounds like something which should be expanded into a new artifact type, rather than recycling tickets for features which are unrelated to tickets. (That said: the pieces used for constructing ticket artifacts seem to be well-suited for such things.)
A "hidden" tag, as mentioned earlier, would eliminate any risks associated with client-provided SQL and could be applied to arbitrary artifact types, including any hypothetical new ones.
(6) By mark on 2023-01-23 07:22:25 in reply to 5 [link] [source]
i find myself asking a question Richard has often asked over the years: what problem does this solve?
And I always appreciate when drh raises it! Often you discover there's already a way to handle the supposed problem, or you find the added complexity isn't worth the cost.
In this case, I'm in agreement with sgb and wyoung wrt security concerns, and am partial to the alternative hidden tag mechanism proposed.