In 3.8, the “reminders are tickets” abstraction seems to be leaking a
bit, at least relative to 3.6. Apologies if this has been covered
before (I could not find anything conclusive), or if I’m again patching
around something that’s solved properly differently.
The first thing we’re noticing is that adding a reminder shows a link to
the reminder ticket in the history. In addition to the “Reminder
‘[subject]’ added” transaction, there’s also a “Reference by ticket #NN”
which did not show up in 3.6. It seems extraneous to me and also
exposes a ticket number for a thing that really isn’t a ticket.
The second thing we’re noticing is scrips firing off for the reminder.
Specifically, AdminCc:s on the queue are getting Create messages about
new "tickets’ for every reminder. Unlike the previous problem I
couldn’t track down a specific 3.6->3.8 change which causes this, but
nevertheless it is easy to eliminate. Patch follows.
Both of these sound like valid issues. Can you drop each of em into mail to rt-bugs@bestpractical.com?
Thanks!
JesseOn Wed, Jul 28, 2010 at 12:53:55PM -0700, Ivan Kohler wrote:
In 3.8, the “reminders are tickets” abstraction seems to be leaking a
bit, at least relative to 3.6. Apologies if this has been covered
before (I could not find anything conclusive), or if I’m again patching
around something that’s solved properly differently.
The first thing we’re noticing is that adding a reminder shows a link to
the reminder ticket in the history. In addition to the “Reminder
‘[subject]’ added” transaction, there’s also a “Reference by ticket #NN”
which did not show up in 3.6. It seems extraneous to me and also
exposes a ticket number for a thing that really isn’t a ticket.
The second thing we’re noticing is scrips firing off for the reminder.
Specifically, AdminCc:s on the queue are getting Create messages about
new "tickets’ for every reminder. Unlike the previous problem I
couldn’t track down a specific 3.6->3.8 change which causes this, but
nevertheless it is easy to eliminate. Patch follows.
Once I’m finished, I will send Best Practical patches to
integrate the changes.
I also came up to the scrip problem but didn’t find a reasonable
solution to this until now.
I wouldn’t deactivate scrips for reminders per default.
We use a scrip that resolve all reminders on ticket resolve.
Maybe another one will notify the ticket owner if another user create an
reminder for this ticket.
I think the best solution would be to don’t fire scrips on default scrip
conditions (in the drop down list).
So you have to write a custom condition if you want to fire a scrip on
reminders.
I would appreciate any suggestions and comments on that.
Thanks!
ChrisAm 28.07.2010 22:00, schrieb Jesse Vincent:
Ivan,
Both of these sound like valid issues. Can you drop each of em into mail to rt-bugs@bestpractical.com?
Thanks!
Jesse
On Wed, Jul 28, 2010 at 12:53:55PM -0700, Ivan Kohler wrote:
In 3.8, the “reminders are tickets” abstraction seems to be leaking a
bit, at least relative to 3.6. Apologies if this has been covered
before (I could not find anything conclusive), or if I’m again patching
around something that’s solved properly differently.
The first thing we’re noticing is that adding a reminder shows a link to
the reminder ticket in the history. In addition to the “Reminder
‘[subject]’ added” transaction, there’s also a “Reference by ticket #NN”
which did not show up in 3.6. It seems extraneous to me and also
exposes a ticket number for a thing that really isn’t a ticket.
The second thing we’re noticing is scrips firing off for the reminder.
Specifically, AdminCc:s on the queue are getting Create messages about
new "tickets’ for every reminder. Unlike the previous problem I
couldn’t track down a specific 3.6->3.8 change which causes this, but
nevertheless it is easy to eliminate. Patch follows.