Just for the mailing list records, a fix for this regression has been
merged to 4.2-trunk and will be in 4.2.6
-kevin
pgpghlyiQvevP.pgp
Description: PGP signature
--
RT Training - Boston, September 9-10
http://bestpractical.com/training
Given no answers yet, it seems that either no one can replicate this (in
which case a works for me would prompt me to debug further) or no one has
attempted to remove due dates from tickets in v4.2.5.
I'll assume the latter and file a bug report.
On 24 June 2014 21:40, Alex Peters
Am 30.06.2014 08:04, schrieb Alex Peters:
Given no answers yet, it seems that either no one can replicate this (in
which case a works for me would prompt me to debug further) or no one
has attempted to remove due dates from tickets in v4.2.5.
I'll assume the latter and file a bug report.
Thank you, but entering 0 does not work for me.
On 30/06/2014 5:30 pm, Christian Loos cl...@netcologne.de wrote:
Am 30.06.2014 08:04, schrieb Alex Peters:
Given no answers yet, it seems that either no one can replicate this (in
which case a works for me would prompt me to debug further) or
I just couldn't believe that something like this could be broken but
indeed this works in 4.2.4 and is broken in 4.2.5.
I think this is related to this commit:
https://github.com/bestpractical/rt/commit/c4f7c8f
Especially the change to RT::Date-Unix as I see this the logs if I enter 0:
Passed a
I agree that the misbehaviour is caused by the commit you reference here.
I believe however that the problem is caused by the change to the
ProcessTicketDates method in RT::Interface::Web.
The method now erroneously skips adjusting the date if the date is not
set—even if explicitly not set by
