On 18 October 2013 03:06, Branko Čibej <[email protected]> wrote: > On 17.10.2013 23:42, Joe Dreimann wrote: > > > >> On 17 Oct 2013, at 23:14, Olemis Lang <[email protected]> wrote: > >> > >> I'm forwarding this message on behalf of a user (after translating the > >> original text in Spanish, adding a bit of slang-ish terms and > >> inserting my own comments ;) . I mostly agree in some points that's > >> why I'm forwarding it to the ML, especially to request for keeping QCT > >> ticket notification visible long after creation, figure out how/where > >> to include it and file a new ticket @ i.a.o/bh . > >> > >> <msg> > >> > >> When QCT form is submitted there's no confirmation indicating that > >> ticket was actually created except for the small window that pops up > >> after a while (<= due to limited bandwith it takes a while to be > >> shown) and that , at least in my case , captures whole attention > >> because > >> > >> 1. it remains open for about 2 or 3 seconds > >> 2. if using a laptop mouse pad then it ends up to be extremely > >> complicated to follow ticket link (<= obviously not a Mac user) > >> 3. if the popup is missed for any reason then finding the ticket > >> is a time consuming task, at least more time-consuming than > >> it should be due to the fact that: > >> * ticket URL has to be guessed > >> * ticket does not show up in dashboard (<= owner and component > >> not in QCT) > >> * therefore a custom query is required > >> 4. the default configuration is sub-optimal since it's always > necessary to > >> surf to ticket page in order to fill remaining fields > >> (<= component , priority , custom fields , ... which otoh are > >> configurable). > >> > >> Summarizing , the confirmation of the most recent ticket must remain > >> in the page just in case it's not possible to capture QCT notification > >> and browsing to ticket page is still needed. > >> > >> </msg> > >> > > These tickets should be easy to find by the Reporter field using Custom > Query and sorting by descending ticket ID. The first ticket is the one last > raised by that user. That's the best way to keep track of tickets raised > throughout the day too. > > Isn't an activity stream the normal way of handling this? If you have an > activity stream on the dashboard, and an easy (one-click) way to have it > show only your own changes, it should be trivial to find such tickets. > Certainly easier than running a custom query. > > -- Brane >
Sure, but you may not be on the dashboard. If you raise a ticket while viewing a ticket, milestone, version etc the activity stream in that context most likely won't show this. Navigating away you would lose context. I do think that we should have the ability to query the activity stream, but I see that in the context of the Custom Query interface: output is either a list of tickets (current), or an activity stream (optionally in future). The activity stream everywhere could contain a link to that preformed query (only 'my actions'). That's a pattern we already have for the queries shown on the dashboard for example. Cheers, Joe > > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. [email protected] >
