timeline should show my own tickets in bold

[rodolfo.borges@…]

Everyday when I start working, I check the Timeline to see what's up. Someone may have changed or commented on a ticket I'm working on. So, the Timeline should display my own tickets in bold (or other visual clue).

btw, thanks for the great product. we started using it in october, and all the team is pleased.

[anonymous]

Also, there could be an option to show only the items relative the the tickets assigned to me.

[Christian Boos]

Milestone 1.0 deleted

[Mikael Relbe]

I think this is interesting, and I could have a go on this since it sounds… "bitesized" (I think this is the term used by the Trac team for small things for newbies like myself :)

Requirement:

Tickets that are owned by the currently logged in user are optionally presented in bold. The user shall be able to control this feature.

I think it should be an option, default "off".

This means that ticket presentation will be controlled by a third option (compared to 0.12). Perhaps a hierarchical rearrangement is in order, analogous to the multirepo-feature introduced in 0.12?

• Tickets
  • Opened and Closed
  • Updated
  • Bold mine

If we allow this sub-section to expand further, we can also solve #9098 while we're at it:

• Tickets
  • Opened
  • Closed
  • Updated
  • Bold mine

Thoughts?

[Remy Blank]

The functionality sounds useful. Maybe we can improve the timeline provider interface to allow for hierarchical filters (without resorting to a hack as for the repositories)?

[Remy Blank]

Maybe this could even be combined with #9282, and use a margin marker instead of bold text?

[Christian Boos]

I'm not convinced this feature is still that useful. Now that we have the timeline filter, it's very easy to add your name there to only see your events (and then add a '-' in front to see others' events).

Maybe doing it always (no additional selector for this) but in a more subtle way than make everything bold would be an acceptable middle ground (e.g. put the author in bold, or adding (you) after it).

Now for the idea of grouped filters:

• All Ticket Events
  • Opened
  • Closed
  • Updated

I'm all for it, and if we can improve the filtering interface, why not. The idea (not sure if I already documented it somewhere) was to distinguish between selection of event providers (what's misleadingly named filters currently) and actual filters that can further restrict the kind of events provided either by a specific filter (like the repository list, filtering by paths) or global filters (like the time span or the user).

[Remy Blank]

Replying to cboos:

I'm not convinced this feature is still that useful. Now that we have the timeline filter, it's very easy to add your name there to only see your events (and then add a '-' in front to see others' events).

That's not quite the same: the filter shows only entries from one or more users, whereas the request in this ticket is to see changes on tickets for which you are the owner.

[Christian Boos]

Replying to rblank:

Replying to cboos:

I'm not convinced this feature is still that useful. Now that we have the timeline filter, it's very easy to add your name there to only see your events (and then add a '-' in front to see others' events).

That's not quite the same: the filter shows only entries from one or more users, whereas the request in this ticket is to see changes on tickets for which you are the owner.

Gasp, I misread ;-) So, +1.

[Ryan Ollos <ryano@…>]

I really like the idea of hierarchical filters, particularly if they are collapsable, and collapsed by default.

[Mikael Relbe]

See comment:37:ticket:6492 for a proposal, combined with other features.

[anonymous]

Replying to mrelbe:

See comment:37:ticket:6492 for a proposal, combined with other features.

looks good to me :)