It would be handy if node schedule form would default to current schedule values if node has been scheduled already. Changing these values (aka. re-scheduling) would update original.

Comments

Anonymous’s picture

Category: feature » bug

Actually it should be already doing this. It fails at workflow.pages.inc, row 199:
if (!empty($node->workflow_scheduled_timestamp) && !empty($node->workflow_scheduled_sid))
Those properties are not set. workflow.node.inc implements hook_node_load which sets those - is workflow.pages.inc missing that?

We are currently using workflow form on it's own tab only - not in any of node forms.

johnv’s picture

There has been some reshuffling of code into the new file workflow.node.inc (in the current dev-version).
Can you check if the error exists already in version 7.x-1.2 ?

Anonymous’s picture

Yes, exists in 7.x-1.2 also. Managed to fix it (temporarily :) by adding
workflow_node_load(array($node->nid => $node), array($node->type)); as first line in workflow_tab_page() in workflow.pages.inc.

johnv’s picture

Why is your change temporarily? Don't you think is a good approach?

Anonymous’s picture

I didn't have time to test it properly but so far it seems to work just perfect.

johnv’s picture

Title: Workflow Tab Form does not show current scheduling information, when Entity Cache is enabled » Workflow Tab Form does not show current scheduling information , see workflow_tab_page()
Status: Active » Needs review

Is this a more precise description?
Setting to 'needs review', as #1 and #3 contain a kind-of-patch.

johnv’s picture

Title: Show current schedule on schedule for if exists » Workflow Tab Form does not show current scheduling information , see workflow_tab_page()
Status: Active » Needs review

@pikku-h, I have tested this now (with 1.x-dev), and my system works as expected. There must be something else.
- create a node,
- go to node/%/workflow, change status, with time in future.
- go to node/%/workflow, time form is expanded with correct data.

Anonymous’s picture

Seems that this is because Entity cache. With it enabled, the forms shows correct info after clearing cache. With it disabled, everything works as expected.

johnv’s picture

Title: Workflow Tab Form does not show current scheduling information , see workflow_tab_page() » Workflow Tab Form does not show current scheduling information, when Entity Cache is enabled
Status: Needs review » Active

Better title.
When a transition is scheduled, the current node is not updated. Therefor, Entity Cache contains old info.
Alternatives:
- do save the unchanged node, which would refresh EntityCache.
- explicitly empty the EntityCache cache (but perhaps more caches are invalid)
- do not do hook_node_load, but load the scheduled data only on the Workflow Form. (this might break API with submodules and contrib/custom modules)
- use the new Workflow Field, that loads the scheduled data only on the Workflow Form.

johnv’s picture

Title: Workflow Tab Form does not show current scheduling information , see workflow_tab_page() » Workflow Tab Form does not show current scheduling information, when Entity Cache is enabled
Status: Needs review » Active

The function workflow_cron contains a statement "cache_clear_all();"
Although a more restricted cache clear is more appropriate, it could solve your use case.

johnv’s picture

From this blog post
"There is one catch to using Entity Cache, it requires that you always update your entity tables using the save/delete API calls in order to ensure Entity cache knows when to invalidate the cache. But you are doing that already, right?

We should look into the way we are saving a node state change on the several forms (View, edit, workflow tab, comment).

johnv’s picture

Version: 7.x-1.x-dev » 7.x-1.2
Issue summary: View changes
Status: Active » Fixed

This is fixed in 7.x-2.x. The Scheduled Transition is loaded every time again on the Workflow Form.
This may result in a small performance drawback. Some caching might be reintroduced some time.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.