sevitzdotcom's dashboard

Ok, I'll wait till you have a solution here. I don't want them to be free floating.

Ideally I'd like to close a milestone like I close a ticket. That would make it closed so I can't add any more tickets too it (unless I reopen it), so clearing it out the new ticket drop down. But at least it would keep in tact all the historic data on this. – sevitzdotcom, on August 20, 2009 17:18

I stand corrected, it just seems to have a bit of a delay. Username is @sevitzdotcom

Hi I'm getting this too. Clicking the @spam link doesn't seem to be doing anything any more.

Sure I understand. I also run a small startup (http://vzaar.com) that we're using sifter for, and I understand the need to prioritise. – sevitzdotcom, on July 18, 2009 16:08

Yeah we do that quite a bit too. However not all our developers work on our project full time, so there might be a day or two when the person we have assigned it to is not around.

(I'm not trying to be difficult, I'm just highlighting how things are for us. And creating a ticket, assigning it to person A and emailing the URL to person B is a frustrating and poor work around, but that's what I'm doing a lot lately)

I'm not sure what the exact solution is ... but the fact only 1 person can get notified of a ticket is something that doesn't account for several of our use cases.

I have looked at that, but I think it would result in a lot of confusion for us.

We have 4 devs and a sysop. Most tickets get assigned to one person, and that's fine. But about 30/40% of tickets I'm not sure who best would be for it or who is less busy. So in this situation, I would need to normally assign to 2 (occasionally 3) people out of the 5.

e.g. An ebay project ticket could go to devs 1, 2 or 3.
e.g. An API ticket could go to dev's 2 or 4
e.g. A design support issue could go to devs 3 or 4
e.g. A security issue could go to devs 4 or 5/

Most tickets though I would know who is working on that particularly piece of work and assign it to them

If I turn on the unassigned functionality, all 5 devs would get all emails for tasks, and it would 2 or 3 devs distracted with an issue that really the don't need to look at.

I do use the unassigned issue, but more for management. Myself and the COO are on that, so when anyone who is not a dev creates a tech ticket , it comes to me (mainly) and then I can decide which dev to assign to it. But the same problem still exists if I need two devs to look at it.

Does that help explain the use case a bit more?

I can see how you would want to keep the clean interface you have now.

- Perhaps a system wide setting that allows a person to turn this functionality on.
- When it's on next to the "assignee" drop down would be a "multiple" link/button.
- Clicking this would open a drop down with assignee's names and check boxes. Then I could select which users get the mail.
- Users getting the mail, have a link to claim ticket or just read it online.
- Once claimed it can only be reassigned not claimed further.
--- users trying to claim a claimed ticket would just be informed it's already assigned to XXX. If they have access to ressaign they could reassign as normal

If anyone is interested I got this working by combining scripts from here:
http://www.macosxhints.com/article.ph...

Although it would be much nicer if tweetie did this natively of course

Sure I can see that it's quite personal. Although I am more used to "unsubscribe" being the last rather than the first link on the page for most system emails.

I also understand the need for awareness.

HTML version emails would go a long step to allowing more detailed design and allowing better positioning of links. Beanstalks HTML mails I find are some of the best, if you want a good example to look at. – sevitzdotcom, on June 24, 2009 08:47