of the
Spring ’14/SP1 release has introduced a number of very exciting features to the customer service functionality of Dynamics CRM including Service Level Agrements and Entitlements. The decision also has been made to introduce Spießrutenlaufen, previously reserved for developers, to the customer service officers. Yes, I’m talking about timer control
Xrm.Page
.getControl('foobar')
.getControlType() == 'timercontrol';
The other good news is that this control can be dropped on any entity’s form that has a date/time field (well, there is always createdon and modifiedon) and an optionset.
Tired of long meetings running over time? Drop timer control on the appointment form:
and keep the form open during the meeting, control will turn change color (pantone code “nasty red”) once you’re over the line:
And meeting is a success only when it’s over:
Great tip, but I keep getting “NANh NaNm NaNs” instead of a counter. Sounds very much like a JS thing, but haven’t yet narrowed it down more. Changing date formats (US, UK, NO, DK) did not affect it.
That does, indeed, sound like a script problem. Do you have any custom scripts on that form that perhaps introduced a namespace conflict with jQuery? Try disabling and see if problem goes away.
No scripts. This was a totally blank CRM 2013 SP1UR1 on-premise install as of this morning.
I’ve narrowed it down to this line:
var $v_1 = $v_0.toUTCString(), $v_2 = Math.floor((Date.parse(this.$e_0.get_failureDateTimeUtcString()) - Date.parse($v_1)) / 1e3) + this.$e_0.get_timeDifferenceInSeconds();and to the method call
Date.parse(this.$e_0.get_failureDateTimeUtcString())which returns NaN.this.$e_0.get_failureDateTimeUtcString()returns dates like “06.10.2014 13:25:00” no matter what format I set the system or my user locale to be in CRM, so possibly this is connected to SQL or Windows locale settings.I will continue to dig into this.
Does look like a bug related to specific Windows locale… Now I’m curious…
Sorry for “spamming” the comment field here, but just wanted to say that I have reported this as a bug to MS today. It is becoming clear that switching between IE and Chrome, switching locale settings, locations etc. changes the outcome, and the code behind as well as the JavaScript is not behaving in a deterministic fashion. In my mind, using “Date.parse” with an input that can vary a lot with different server and client settings is just simply bad coding, and also documented as risky (for example https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse).
Hope this get confirmed quickly, but generally disappointing that this was not a test case. Anything regarding date and date calculations is risky and needs extra testing.