Custom Query (332 matches)
Results (193 - 195 of 332)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#195 | fixed | Enhancement for ticket prefixes | bas | Konstantin Ryabitsev <icon@…> |
Description |
Some of the requests we receive need to be created with a closed status. It's kind of silly, but we need a record of the request for reference, but we don't want the ticket to be open because it's not an actionable item. This is easy to accomplish using projects and ticket prefixes, but the following patch was necessary to be able to set status and resolution. There's really no reason why resolution should be excluded from the list of fields -- it just limits someone's options. :) Same goes for status. |
|||
#214 | fixed | Permission to update the ticket, but not set properties | bas | Konstantin Ryabitsev <icon@…> |
Description |
Hello, me again: I like the new permissions system, but I would like to see it more fine-grained. I would like anyone to be able to update the ticket comments, but restrict setting properties (via subject line or inline properties) only to people who have permission to update the ticket. What do you think? |
|||
#216 | fixed | disallow multiple assignment of the same inline property | bas | Konstantin Ryabitsev <icon@…> |
Description |
(contd from #214) Attached patch will only allow one assignment of the same inline property -- the first one. For example, take the following email using "outlook-style" quoting and top-posting: I fixed your problem. @status: closed @resolution: fixed ---- From: Client To: Developer Sent: ... Subject: Re: Please fix my problem I will be fixing your problem shortly. @status: accepted Without the patch, the status will be set to "accepted" even though it's not the developer's intent. With this patch, the top-most assignment wins, and all further assignments are ignored. |