Stuart Torres-Catmur Posted March 28, 2018 Share Posted March 28, 2018 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 Link to comment Share on other sites More sharing options...
Steven Boardman Posted March 28, 2018 Share Posted March 28, 2018 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 Link to comment Share on other sites More sharing options...
Steven Boardman Posted March 29, 2018 Share Posted March 29, 2018 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 2. You can remove the date formatter node 3. On the request the value in the Questions section should be displayed correctly 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 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 Link to comment Share on other sites More sharing options...
Guest jpopoff Posted April 4, 2018 Share Posted April 4, 2018 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 Link to comment Share on other sites More sharing options...
Foley Coker Posted April 6, 2018 Share Posted April 6, 2018 @Steven Boardman thank you, the instructions from above worked for us in our BPM and the emails are now displayijgn the correct time. Thank you @Stuart Torres-Catmur for raising Link to comment Share on other sites More sharing options...
SJEaton Posted April 20, 2018 Share Posted April 20, 2018 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 Link to comment Share on other sites More sharing options...
Steven Boardman Posted April 23, 2018 Share Posted April 23, 2018 @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 Link to comment Share on other sites More sharing options...
Victor Posted April 24, 2018 Share Posted April 24, 2018 @SJEaton @Stuart Torres-Catmur @Foley Coker Link to comment Share on other sites More sharing options...
SJEaton Posted April 24, 2018 Share Posted April 24, 2018 Hi @Victor, can't see content you've posted, it says I don't have permission to see it? Link to comment Share on other sites More sharing options...
Victor Posted April 24, 2018 Share Posted April 24, 2018 @SJEaton apologies, I have posted the wrong link . I have corrected this now. Link to comment Share on other sites More sharing options...
SJEaton Posted May 1, 2018 Share Posted May 1, 2018 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 Link to comment Share on other sites More sharing options...
Victor Posted May 1, 2018 Share Posted May 1, 2018 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? Link to comment Share on other sites More sharing options...
SJEaton Posted May 1, 2018 Share Posted May 1, 2018 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 Link to comment Share on other sites More sharing options...
Victor Posted May 1, 2018 Share Posted May 1, 2018 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. Link to comment Share on other sites More sharing options...
SJEaton Posted May 17, 2018 Share Posted May 17, 2018 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 Link to comment Share on other sites More sharing options...
Victor Posted May 17, 2018 Share Posted May 17, 2018 @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... Link to comment Share on other sites More sharing options...
Victor Posted May 21, 2018 Share Posted May 21, 2018 @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... Link to comment Share on other sites More sharing options...
Victor Posted May 21, 2018 Share Posted May 21, 2018 @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... Link to comment Share on other sites More sharing options...
SJEaton Posted May 21, 2018 Share Posted May 21, 2018 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 Link to comment Share on other sites More sharing options...
Victor Posted May 21, 2018 Share Posted May 21, 2018 @SJEaton ok, thank you, I'll have a look Link to comment Share on other sites More sharing options...
SJEaton Posted May 29, 2018 Share Posted May 29, 2018 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 Link to comment Share on other sites More sharing options...
Victor Posted June 5, 2018 Share Posted June 5, 2018 @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: Link to comment Share on other sites More sharing options...
SJEaton Posted June 5, 2018 Share Posted June 5, 2018 Hi Victor Ah ok! Thanks, I will have a look at this today and confirm it it solves the issue Sam Link to comment Share on other sites More sharing options...
SJEaton Posted June 6, 2018 Share Posted June 6, 2018 Hi @Victor, it won't let me enter answer 24, it only goes up to 10 in the variable picker?? Link to comment Share on other sites More sharing options...
Victor Posted June 6, 2018 Share Posted June 6, 2018 @SJEaton well this is interesting ... 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 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now