Condition on Date attribute does not work after change of time

[Martin Snizek]

Hello,

 

we have got a problem with start condition of process, we have got two date attributes shown as Date and Time. We need the process to start on update of one of these two fields (both as well). It works fine (=process starts), when we change the day (for example from 26 January to 27 January), but when I change only the time part of the attribute value, the process does not start.

 

Have you ever encountered this problem?

 

Does anybody know how to solve it please?

 

Regards,

Martin

[Nick Darlington]

Could you please share your full start conditions and give an example of initial attribute value and what you changed it to when expecting the process to start?

 

Please also include your full version of Clarity (including any patch level applied).  Thanks.

[Martin Snizek]

Hello,

 

this is my start condition:

( ( Meeting Meeting date - from != Meeting Meeting date - from [Previous Value] ) or ( Meeting Meeting date - to != Meeting Meeting date - to [Previous Value] ) )

 

Clarity version: 13.2.0.472 06 14

 

Regards,

Martin

[navzjoshi00]

Guess, the below is somewhat related -

 

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec525516.aspx

 

"A previous value comparison condition should only be used in a start condition with one exception. You may use a previous value comparison of an attribute in a pre- or post-condition to check if the attribute value has been modified in the same step. It cannot be used to check if the attribute has been modified at other times."

 

NJ

[Martin Snizek]

Hello,

 

thank you for your post, but these KB article talks about conditions between steps of process, I'm talking about start condition of process. And it's also described in the solution:

 

A previous value comparison condition should only be used in a start condition with one exception. You may use a previous value comparison of an attribute in a pre- or post-condition to check if the attribute value has been modified in the same step. It cannot be used to check if the attribute has been modified at other times.

 

Regards,

Martin

[Nick Darlington]

You're correct, they are different issues.

 

The cause in this case appears to be that the event message fired from the app service when the field is changed has 'truncated' the time portion of the date/time field, so even though the time may initially be :30 for example and changed to :45, both the current value and previous value in the event message show a timestamp of : 00 instead.

 

As such, the event handler receiving this message does not perceive an actual change, until the date portion of the field has changed.

 

You can see/confirm this by reviewing the new records added to the NMS_MESSAGES table (the 'persistent store' for event messages) when you make updates to the record with changes to this field.

 

I cannot be certain if this will be accepted as a defect or a limitation, however I don't see that it has been reported before - just probably due to the lower number of real use cases of this being performed as a start condition check condition - and am in the process of reporting it for you.  Once I've done this, I'll reply to the thread with reported details (CLRT etc.) and then suggest you raise an issue to reference it so you can follow its progress and conclusion.

 

I'm also checking if this appears to have been affected in later versions (even if there was no prior CLRT, sometimes parts of the application undergo a change or redesign that can fix things) and will report back if there's news from that too.

[Nick Darlington]

I checked in the latest version and the behaviour is still currently the same there.  I have reported the defect but there are no customer records currently linked to it for now, so please raise an issue with Support referencing this record and that you are encountering it so that they can be linked together.

 

CLRT-77110 Process events on date and time fields do not reflect changes to the time portion resulting in no process starting

 

Steps to Reproduce

1. Create a new attribute on an event-enabled object (e.g. project), type: date 

2. Place the attribute on the Layout: Edit view in the General section. 

3. Change the Fields link for the view and this specific attribute, to set the Display Type from just Date to the setting Date and Time.

4. Create a new process based on the event-enabled object as its Primary object, with auto-start on Update. You can uncheck the box that says 'Do not start a process if one is already running'

5. Create a start condition for the process that is based on the object attribute current value != object attribute previous value.

6. Link the Start step to the Finish step and then on the Validation tab, select Validate All and Activate.

7. On the Access to this Resource tab, in Resources, give your user the Start permission for the process.

8. Go to your event-enabled object in the application (e.g. for Project, go to the main Project List view) and select a record to get to the properties screen.

9. Find the attribute on the page, change the setting and click Save.

 

Note: At this time, because the value was previously 'null', whether or not you set a time or left it to default to 00:00:00 then the process should start and immediately finish. This is expected, but if you didn't set/leave the time to 00:00:00 and chose something else, then the record in the NMS_MESSAGES table after this update is not expected as it will show the new value for the attribute is 00:00:00.

 

10. Modify just the time portion of the attribute value to something else, such as 17:45 and click Save again.

 

Expected Result:

The NMS_MESSAGES record should indicate the change in the time portion of the attribute and a new process instance should start

 

Actual Result:

The NMS_MESSAGES record shows that both the previous and current values for the attribute in the event are 00:00:00 and no process starts.

 

I didn't identify any simple workarounds.  A complex one around keeping track of the previous value with another attribute and doing some comparison of them in a process isn't perfect (the attribute value could be changed again before the process was able to compare, which could result in various inconsistencies in behaviour), so I think this limitation would need to be addressed through code changes really.

[navzjoshi00]

Thanks for the useful info provided, Nick

NJ

[Martin Snizek]

Thank you Nick, I'll raise an issue with Support.

 

Regards,

Martin