Date/Datetime CFs not populating on ticket modify

RT Users
1

Hi there,

We recently upgraded our RT installation to v4.2.0 from v4.0.9 and have
noticed an interesting issue with custom fields since the upgrade. We have
numerous date & datetime custom fields across our queues and several of
these are marked as Mandatory. Since upgrading, when a user modifies a
Ticket with one or more of these Mandatory date/datetime fields, the ticket
does not populate the date/datetime fields with the existing values. The
net result is that either they have to re-enter the values before
submitting the update or they get a validation error of the form “:
Input must match [Mandatory]”.

I’m advised this didn’t used to be the case where if a Mandatory
date/datetime field wasn’t modified during a Ticket modification it would
simply re-use the existing value. We’ve only noticed this issue on these
specific custom field types; other field types behave as expected.

I’ve taken a look around the RT configuration but haven’t made much
progress in determining the cause. Any advice would be greatly appreciated.
Is it possible this is a bug/regression in RT v4.2.0 or have I just
overlooked or misunderstood something?

Thanks,
Samuel Leslie

2

[snip] Is it possible this is a bug/regression in RT v4.2.0 or have I
just overlooked or misunderstood something?

Unfortunately, absolutely a regression. Please give
https://github.com/bestpractical/rt/commit/28a7109e4cdfbe439f9562b7d58430f626e17a87.patch a test to see if it resolves your issue.

  • Alex
3

[snip] Is it possible this is a bug/regression in RT v4.2.0 or have I
just overlooked or misunderstood something?

Unfortunately, absolutely a regression. Please give

https://github.com/bestpractical/rt/commit/28a7109e4cdfbe439f9562b7d58430f626e17a87.patcha test to see if it resolves your issue.

  • Alex

Have installed the patch and can confirm it does indeed fix the issue.
Thanks very much for the prompt response and fix!
-SDL

4

Have installed the patch and can confirm it does indeed fix the issue.
Thanks very much for the prompt response and fix!

For reference, this didn’t make it into 4.2.1, but will most probably be
in 4.2.2. You may also be interested in the other two commits on that
branch, which deal with Mandatory validation.

https://github.com/bestpractical/rt/compare/4.2/date-cf-validation

  • Alex
5

Hi

Unfortunately, we still need/use Internet Explorer 8 in our company (compatibility issue with other apps).

I found a few issues (#22770, #16629, #19547) listed on the issues.bestpractical.com site regarding IE8 and custom fields, each of these describes exactly what I’m seeing here on 4.2.0 – Specifically, editing a “child” or secondary custom field does not work/display properly.

In addition, the recent issue (introduced in 4.2.0 I think) regarding not being able to edit dashboards (and other edit screens too) in IE is now fixed for me in IE10, but is still broken in IE8.

I was wondering if maybe ie8 just wasn’t supported in RT anymore?

Thanks!
Brent

6

More notes on this issue:

I was monkeying around in the IE Console, looking to see if perhaps there were some javascript errors getting popped or something (there are not).
While in there and refreshing the page a lot (on a VERY slow machine, by the way), I see that the custom field value IS shown in IE, but only for a second. Then it reverts back to the (no value) option.

More detail:
I have a custom (select one) field called “application”.
Depending on what you select for application, the “version” (select one) custom field can be selected.
i.e. if I choose “Request Tracker” for my application, then I can select version “4.2.0” from the Version Custom field.

In IE8, I can set the application, the version, and save it.
It displays correctly on the display tab.
When I click on “Basics” or “Jumbo” to edit the ticket, the Application field remains on ‘Request Tracker’ like it should.
For a split second (not even seen on reasonably fast machines), the sub-field of Version shows “4.2.0”, but then reverts to “(no value)” before the page finishes loading.
If I just click save, the ticket changes to “No value” for the Version field. :frowning:

So in IE8, I have to memorize each of the multi-level custom field values before going to the edit page, and then I have to set them all back to what they were before saving changes to the ticket.

Also, I went back to an old 4.0.12 version of RT and see the same behavior there.

Interestingly, 4.0.12 DOES work for the dashboard issue in IE8, so apparently that is a completely different problem.

Any thoughts on this?

Thanks!
Brent-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Parish, Brent
Sent: Tuesday, November 19, 2013 11:30 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] IE8 issues - Custom Fields and edit screens

Hi

Unfortunately, we still need/use Internet Explorer 8 in our company (compatibility issue with other apps).

I found a few issues (#22770, #16629, #19547) listed on the issues.bestpractical.com site regarding IE8 and custom fields, each of these describes exactly what I’m seeing here on 4.2.0 – Specifically, editing a “child” or secondary custom field does not work/display properly.

In addition, the recent issue (introduced in 4.2.0 I think) regarding not being able to edit dashboards (and other edit screens too) in IE is now fixed for me in IE10, but is still broken in IE8.

I was wondering if maybe ie8 just wasn’t supported in RT anymore?

Thanks!
Brent

7

More notes on this issue:

I was monkeying around in the IE Console, looking to see if perhaps
there were some javascript errors getting popped or something (there
are not). While in there and refreshing the page a lot (on a VERY slow
machine, by the way), I see that the custom field value IS shown in IE,
but only for a second. Then it reverts back to the (no value) option.

I believe this to be the same issue as all of #22770, #16629, and
#19547. Unfortunately, the patch on #16629 will need to be reworked due
to recently added support for select-multiple cascades.

Interestingly, 4.0.12 DOES work for the dashboard issue in IE8, so
apparently that is a completely different problem.

Please specify what you mean by “the dashboard issue,” preferably by
giving precise steps to replicate. While 4.2.0 has knows problems in
this area, 4.2.1 with IE 8 does not evidence any in the Dashboard pages
that I can find.

  • Alex
8

Hi Alex.

Thanks for the response!
Sorry for the brevity - it’s always a trade-off: too much information and I fear no one will want to read it all. Too little and it’s difficult to understand the full issue!

    • For the Dashboards:
      I experienced an issue with 4.2.0 working with editing dashboards.
      I could create a new dashboard in IE (Both v. 8 and v. 10) via Home → New Dashboard, enter a Name and hit the Create button.
      I would switch to the “Content” page to edit the dashboard. All good so far.
      But when I clicked on something in the Available list (e.g. QuickCreate) and clicked on the “->” button to add it into the dashboard, the page would refresh and display the “Dashboard Updated” message but that element was not added.
      Then you(?) released a single line patch (in share/static/hs/forms.js) and that fixed IE10 but IE8 still exhibits that same behavior for me.

I was originally reporting that I see this dashboard editing problem in IE8, as well as the Custom Field thing, thinking they were related but as I dug into the Custom Field issue, it appears less and less like they are related.

    • For the Select Custom Fields:
      Now I’m guessing the custom field thing has to do with jQuery and IE8 in general.

For giggles, I copied the html/Elements/EditCustomFieldSelect file from RT 3.8.16, just to see if I could find an older RT version that did work with multi-level/parent/child Select type custom fields. I didn’t really expect it to be a fix and I rather expected big failures mixing versions like that. It still did not display the correct value for the sub/child custom field.
I tried changing both parent and child select custom fields to Render Type: Select Box with the same result.
I changed the parent to Render Type: list and that finally worked (e.g. showed the correct child value) but of course breaks the purpose of the parent child and selecting something new in the parent list did not narrow down the select options in the sub/child field.

Many thanks again,
BrentFrom: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Alex Vandiver
Sent: Tuesday, November 19, 2013 5:48 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] IE8 issues - Custom Fields and edit screens - updated

More notes on this issue:

I was monkeying around in the IE Console, looking to see if perhaps
there were some javascript errors getting popped or something (there
are not). While in there and refreshing the page a lot (on a VERY slow
machine, by the way), I see that the custom field value IS shown in
IE, but only for a second. Then it reverts back to the (no value) option.

I believe this to be the same issue as all of #22770, #16629, and #19547. Unfortunately, the patch on #16629 will need to be reworked due to recently added support for select-multiple cascades.

Interestingly, 4.0.12 DOES work for the dashboard issue in IE8, so
apparently that is a completely different problem.

Please specify what you mean by “the dashboard issue,” preferably by giving precise steps to replicate. While 4.2.0 has knows problems in this area, 4.2.1 with IE 8 does not evidence any in the Dashboard pages that I can find.

  • Alex
9

I edited the EditCustomFieldSelect file and added a simple javascript popup alert() function to freeze loading the page.
e.g. alert(“Pause the page here”);

I kept moving the alert() lower in the jQuery block.
It appears that executing the “basedon.onchange();” line is where the child/sub select CF is wiped out in IE8.
If I alert just prior to this line, I still see the correct value before I dismiss the popup.
If I alert just after this line, the select field is already showing “(no value)” before I dismiss the popup.

If I comment out this “basedon.onchange();” line, everything seems to work in IE8, IE10 and Chrome.

Is that safe to do? Or am I wrecking some functionality here that I am blissfully unaware of?

Thanks!
BrentFrom: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Alex Vandiver
Sent: Tuesday, November 19, 2013 5:48 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] IE8 issues - Custom Fields and edit screens - updated

More notes on this issue:

I was monkeying around in the IE Console, looking to see if perhaps
there were some javascript errors getting popped or something (there
are not). While in there and refreshing the page a lot (on a VERY slow
machine, by the way), I see that the custom field value IS shown in IE,
but only for a second. Then it reverts back to the (no value) option.

I believe this to be the same issue as all of #22770, #16629, and
#19547. Unfortunately, the patch on #16629 will need to be reworked due
to recently added support for select-multiple cascades.

Interestingly, 4.0.12 DOES work for the dashboard issue in IE8, so
apparently that is a completely different problem.

Please specify what you mean by “the dashboard issue,” preferably by
giving precise steps to replicate. While 4.2.0 has knows problems in
this area, 4.2.1 with IE 8 does not evidence any in the Dashboard pages
that I can find.

  • Alex
10

I experienced an issue with 4.2.0 working with editing dashboards.
[snip] Then you(?) released a single line patch (in
share/static/js/forms.js) and that fixed IE10 but IE8 still exhibits
that same behavior for me.

I am unable to replicate the failure on a clean 4.2.1 with IE8. I
suspect IE8 is caching – it has a number of overzealous layers of
caching. Clear your local caches and try again.

Now I’m guessing the custom field thing has to do with jQuery and IE8
in general.

jQuery is not involved, as it happens. The calls use direct DOM
manipulation – shifting to using jQuery might very well resolve the
problem, as jQuery has a number of abstractions which paper over browser
bugs like this.

The specific cause is known – you can read the issues.bestpractical.com
ticket for details if you’re curious, or want to test and propose a
patch.

  • Alex