Problem/Motivation
Steps to reproduce:
1. Goto a node add page: /node/add/article
2. Fill in fields and ADD one or more transitions. Say, set one transition "published" at 5 minutes more than the current time.
3. Do not hit save, instead hit Preview.
4. The node is visible in preview mode. Click on back to content. Notice this time, node add/edit page is opened with "UUID" query parameter.
5. Notice the scheduled publication date. This shows 1 Jan 1970.
Observations:
The date passed from drupal in the hidden input has the value = "[{"when":1563292.005,"state":"archived"}]", -> This case is not working
When the date is passed as "[{"state":"archived","when":"2019-07-16T15:46:45+00:00"}]" -> this case is working.
This value is being read by the react app which is unable to find the correct date for "1563292.005" timestamp.
Update: See #2 for latest observations.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3068420-2.patch | 30.03 KB | jaykandari |
Comments
Comment #2
jaykandariUpdate:
Stage 1: Markup set by drupal
When node edit page is loaded, the hidden input var inside
element stores date in ISO 8601 UTC string ('c' date format). This data is read by React app during its initialization & correct date is assumed.
State 2: React app changes.
When Changes are made to transition fields (react app). it updates the old hidden transition data field with new changes. In this case, react stores date as UNIX timestamp so that this value can be processed when the form is submitted.
Cause of this issue:
when the node edit page is viewed, the data is not retrieved directly from the entity, instead, it is retrieved from the saved $form_state 's input variables.
Added solution;
Now, for scheduled_transition_date value, the react app is updating this field dynamically when values are changed in the fields, eg: a new transition is created/removed.
When this same value (which was set by react app) is populated to the initial markup when visiting node edit page. The react app is unable to identify the date, as it is expecting date as an ISO 8601 UTC string, but instead it is passing UNIX integer. Thus patched the react app which looks for a number value if found, it assumes it to be a UNIX timestamp and multiplies it by 1000 so that it can be properly read in Javascript.
Alternative solution:
Also tried modifying the $form_state input variables in Widget (or via hook_form_alter). This is another way of solving this issue, but in this case, the timezone difference is not handled. Because the react app calculates the date based on the browser's date whereas the date we are converting is as per GTM.
Also, when the correctt format is passed, the field throws an error saying the format is invalid, as the validator is expecting UNIX timestamp in this case.
Sample code:
IMO, this is a good topic for discussion as this can be critical in some cases where publication of data is a sensitive issue.
I prefer moving forward with the react approach because it is not throwing any errors and what content managers had added prior to previewing of the node is the same as when visited later.
Added a patch. Kindly Review.
Thanks !!
Comment #3
jaykandariComment #4
dishabhadra commentedI tested this patch. It's working.
Marking this as RTBC.
Comment #5
dishabhadra commentedI was facing the same issue when any validation on node save fails we come back to the same page that time date was changing to 1 Jan 1970. This patch working fine in that scenario as well.
Comment #6
phenaproximaPatch looks good to me, but it needs an automated test. There are existing tests which could be easily extended to exercise this bug fix. :)
Comment #7
abhaysaraf commented#2 extended here https://www.drupal.org/project/lightning_workflow/issues/3102295 may be helpful.
Comment #8
phenaproximaComment #9
kaszarobertThe suggested patch is the same solution that was merged in #3102027: Transition does not happen accurately when lightning_scheduler_cron() runs each minute.
I cannot reproduce the issue anymore, so I'll close this.