Jump to content
Stuart Torres-Catmur

Time on emails showing as GMT not BST

Recommended Posts

Hi folks

When requests are logged via hornbill's "I want to book a minute taker" the time selected is not being reflected in the automated emails, appearing to not have taken daylight saving time into consideration, as it is always an hour before.

Just to confirm it is just the emails being effected, the actual request details show the right time

Basically we have date conversion nodes in the Minute Taking BPM and it seems to be taking an hour off. 

Is this a system setting / wokflow config we've missed or is it a bug?  Please help

Share this post


Link to post
Share on other sites

Hi @Stuart Torres-Catmur

When you say it is only the email date value that is an hour off, but the request date value is correct could you clarify the following:

On the request if the customer has input a date / time in a Progressive Capture field then the value should be visible in the Questions section on the request.

If you have then used the Integration Call Node (iBridge > Utility > Date Formatter) to convert this value, are you then writing this value to a Request Custom Field in the request details section of the request?

If so could you compare the value in the questions section on the request and the value in the custom field in the request details section (or forward a screen shot) as typically it will be a value in a custom field which will then he added as a variable in the email template which is sent out.

Finally could you also share a screen shot of your Integration Call (iBridge > Utility > Date Formatter) node configuration to see if we can spot anything

Thanks

Steve

Share this post


Link to post
Share on other sites

Hi @Stuart Torres-Catmur having looked at this i can replicate the issue you are experiencing.

There is a workaround option you could try.

1. In your progressive capture form where you have the date / time field if you Map this question to one of the new datetime specific custom fields - h_custom_21 being one of them

image.png

2. You can remove the date formatter node 

3. On the request the value in the Questions section should be displayed correctly

image.png

4. The value in the h_custom_21 field will still display incorrectly in the UI (offset by one hour)

5. If you include the h_custom_21 field in your email template this will display the correct value to your end user

image.png

We are looking into the behaviour but this workaround should allow your correct date / time value to be displayed in the questions section on the request and in the email which goes out to the customer. The only minor additional consideration is that the date / time output will include the seconds value.

Steve

 

Share this post


Link to post
Share on other sites
Guest jpopoff

Hello,

I suppose this is similar to the issue reported last week since the change of time.

We are also affected in our change process, and the incorrect timing is currently showing on email, task generated by the tool which are being assigned to our senior management for approval.

Jmarc

 

Share this post


Link to post
Share on other sites
On ‎29‎/‎03‎/‎2018 at 8:01 AM, Steven Boardman said:

We are looking into the behaviour

Hi @Steven Boardman, any news on this?  The workaround does work but I have instances where I have more than 5 date/time fields in a progressive capture so as there are only 5 new date/time custom fields available I'm having to still use custom fields A-T for some of them and therefore have the issue with the date/time displaying on auto-emails, 1 hour before what is entered in the custom field on the PC.  Help!

Sam 

Share this post


Link to post
Share on other sites

@SJEaton sorry for the delayed response i have taken a look and i believe the fix for the original issue will be available in the next Service Manager update which should be available early this week. 

Steve

Share this post


Link to post
Share on other sites

Hi @Victor, can't see content you've posted, it says I don't have permission to see it?

Share this post


Link to post
Share on other sites

Hi @Victor, we are now at Build 1221 but still have the issue with the date/time showing different to what was entered in the PC.  The error only occurs when the custom field is A-T and not if we use one of the new date/time format one's (21-25).

Attached is an email extract showing the issue.  The first five dates shown use custom fields 21-25 so are correct but as there are only 5 date/time custom fields I used custom L for the sixth entry which is displayed incorrectly (see highlighted).  This should show 06/05/2018 00:00 but shows 30-04-2018 23:00.  This isn't even one hour before anymore so not sure what's going on?

The service request is SR00034560 in case you need it.

Thanks

Sam

Capture.PNG

Share this post


Link to post
Share on other sites
9 minutes ago, SJEaton said:

I used custom L for the sixth entry which is displayed incorrectly (see highlighted)

It is actually displayed correctly. Custom L is not a date/time field is a varchar field, which means any value stored in this field will be a string and not be converted.

 

14 minutes ago, SJEaton said:

This should show 06/05/2018 00:00 but shows 30-04-2018 23:00

Can you explain a bit why it should display that value?

Share this post


Link to post
Share on other sites

I ran out of date/time custom fields to use so had to use another custom field (I don't now what varchar means??)

The PC is an overtime claim form and therefore 06/05/2018 00:00 was selected from the date/time picker as a claim date/time (custom field L).  I then have h_custom_l as the variable in the email but it has displayed as 30-04-2018 23:00.  It must be something to do with me using custom L but can you advise what we could use instead if we run out of date/time fields?

Sam

Share this post


Link to post
Share on other sites
Just now, SJEaton said:

(I don't know what varchar means??)

It basically means the values stored in this field will be a simple text (string) and will not be converted as Hornbill does not know if the value stored there is just a text or it means something else (like a date) that could be possibly converted.

 

2 minutes ago, SJEaton said:

The PC is an overtime claim form and therefore 06/05/2018 00:00 was selected from the date/time picker as a claim date/time (custom field L).  I then have h_custom_l as the variable in the email but it has displayed as 30-04-2018 23:00.

I'll have a look at the request example you mentioned and get back to you.

Share this post


Link to post
Share on other sites

Hi @Victor, a gentle nudge re this issue.  Any ideas on what I can use for the 6th date/time field so that it pulls through the date correctly?

Thanks

Sam

Share this post


Link to post
Share on other sites

@SJEaton I have to admit and apologise, I forgot about this thread... I really need to manage these better ... *sigh ... :(

I'll put it on my (top of the) list...

Share this post


Link to post
Share on other sites

@SJEaton still looking into this... I have no answer yet why 2nd May was stored as 30th April in the database... I'll keep looking...

Share this post


Link to post
Share on other sites

@SJEaton can you please run another test? I looked at SR00034560 but I can't see what went wrong.. maybe another test will give me some more clues...

Share this post


Link to post
Share on other sites

Hi @Victor, the new test is SR00038346.  The same issue occurred i.e. 06/05/2018 00:00 displayed on the auto email as 30-04-2018 23:00

Sam

Share this post


Link to post
Share on other sites

Hi @Victor, any luck with this issue. It's holding up a go live of an overtime form we want to launch but obviously can't until the date/time display issue has been rectified.  Thanks

Sam

Share this post


Link to post
Share on other sites

@SJEaton ok, I think I finally found out what is happening here... on both SR00034560 and SR00038346 there is no issue actually but there might be some misunderstandings: You said that you capture the sixth entry for date/time in Custom L. That is correct, according to "WF Services Overtime Form" PCF definition. However, in your process ("WF Services Overtime Claim"),  you are overwriting the value in this field. This happens in the first "Convert Date" node and the following "Update Custom Fields" node. In the "Convert Date" node you convert this variable: &[global["flowcode"]["answer4"]]. This variable represents the fourth answer from the "wfsovertimeclaim" custom form of the PCF (based on the "previous Get wfsovertimeclaim form" process node). Answer 4 on this form is not the sixth date/time entry, is actually the first date/time entry (Claim 1). This has the value of "01/05/2018 00:00:00". Because of BST conversion in the UI, this date/time value becomes "30/04/2018 23:00:00" and this is how you end up with this value in Custom L field.

Suggestions: If you indeed want to pick up the sixth entry from progressive capture "overtime claim" form then in the "Convert Date" node you need the &[global["flowcode"]["answer24"]] variable (so is 24 not 4)

Screenshots:

image.png 

image.png

 

 

Share this post


Link to post
Share on other sites

Hi Victor

Ah ok!  Thanks, I will have a look at this today and confirm it it solves the issue 

Sam

 

Share this post


Link to post
Share on other sites

Hi @Victor, it won't let me enter answer 24, it only goes up to 10 in the variable picker??

Capture.PNG

Share this post


Link to post
Share on other sites

@SJEaton well this is interesting :D ...  right, try and type in the variable then directly then (forget about the picker) for now ... so instead of &[global["flowcode"]["answer4"]] type in &[global["flowcode"]["answer24"]] ... see how this works :) 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...