Info 14 - Tokenize Scheduler TimezoneID - Bug workaround

Good morning all,

Logi has acknowledged an issue in the new Scheduler TimezoneID feature that occurs if you try to use a Token (or pass a hard-coded value) for the TimezoneID. I have a workaround in case anyone runs into this issue.

Scenario - We are running Engine 14.0 SP3 and have started using the Scheduler feature. Our parent application DB has a UserTZ value for each user, representing the user's Timezone like "Eastern Standard Time", "Mountain Standard Time", "Pacific Standard Time", etc. We set the UserTZ as a Session Token in our Info application so that we can use AT TIME ZONE in our SQL queries, among other things.

One of these 'other things' was to pass the Session.UserTZ token into the Scheduler Element's TimezoneID to automatically apply the user's TimeZone to their Scheduled Task. However, the TimezoneID doesn't appear to be setting correctly in Info. The effect of passing a Token into the TimezoneID value is that the drop-down for TimeZone shows the correct value (e.g. Eastern Standard Time), but the internal TimezoneID isn't set until the user changes something else in the Scheduler Element (you can see this behavior quickly by setting ShowScheduleXml="True" and passing a hard-coded "Eastern Standard Time" as the TimezoneID in the Link Parameter for ScheduleXml like <Schedule Type="Daily" StartDate="@Date.Today~" FirstRunTime="21:00" TimezoneID="Eastern Standard Time" />). The drop-down for Time Zone will act like the TimezoneID is set, but the Show Schedule Xml will not get the TimezoneID value until you change a Schedule element.

Logi Support has indicated that this will be resolved in a future release, but the simple workaround is to force the application to behave as if the user has made a change to the Schedule. In my scenario, I have the Schedule Element in a Popup Panel/DIV that I show using an Action.Refresh from a UI element. The solution is to add the action that would be taken by a user changing something in the Schedule Element as a Post Refresh Javascript attribute, effectively simulating the user's change after the Action.Refresh is run. 

For example, my Schedule Element is named TaskSchedule and the 'native' code applied when changing the Interval (found in rdTemplate\rdSchedule\rdScheduleTemplate.lgx line 25 and lifted from the DevTools in my browser) is:

javascript:NavigateLink2('javascript:rdSchUpdateControls(\x27TaskSchedule\x27);','','false','','',['','',''],true)

I added this, verbatim, into my Action.Refresh's Post Refresh Javascript attribute. Alternatively, you could run/apply the change using jQuery or JS code to take action on the Schedule Element after it is shown. In either case, this effectively applies your passed TimezoneID value to the Schedule. We hide the Timezone picker using our TMF so our users don't have to see it or think about it.