Sorry if this has been explained else where, I might have missed it. And I have been reading a lot.
I'm using workflow 7.2.x-dev with workflow_field module to add a workflow to an entity.
I am a bit confused at the moment on the best way to programmatically change a state with the new (for me anyway) OOP way of dealing with workflow.
1. Can somebody please give me an easy example to programmatically change a workflow state. I am also especially interested setting up a new scheduled transition. Basically:
if user change state from A->B, I want to automatically set up a scheduled change to change to C at time x
I know there is Rules module, but I would prefer to use code, as there are some other things I want to do.
2. I take it, to detect a state change, the best is still to use hook_workflow with $op transition_pre? Or is there a better way?
Comments
Comment #1
Max_Headroom CreditAttribution: Max_Headroom commentedDid some more digging around in the code and some things became clearer.
There is a serious lack of examples and documentation regarding entity transitions . But in the spirit of open source, I will make some notes over the next few days as I work on this and publish it.
Comment #2
Max_Headroom CreditAttribution: Max_Headroom commentedPlease contribute to this documentation with your input and code snippets.
Comment #3
VenDG CreditAttribution: VenDG commentedI just so happen to be trying to figure this out also.
I created a content type with a workflow field with radio buttons that toggle between submitted and approved. (the workflow has three states: creation, submitted, approved). Based on looking through the code, I created a module that programmatically changes the value of the workflow field. I can edit a node, leave the radio button on the workflow field unchanged and after saving when I view the node again, the approved radio button is selected, but the workflow history still shows the state as submitted. I am missing something but I am not sure what, to get the field change value reflected in the history.
Here is my code so far. I have devel turned on.
Comment #4
VenDG CreditAttribution: VenDG commentedHook_entity_presave doesn't work, switched to hook_entity_update and the transition appears in the history.
Here is the updated code:
ETA: I am using workflow field (the new way of working with workflow) and not workflow node (the old way of working with workflow).
Comment #5
Max_Headroom CreditAttribution: Max_Headroom commentedThanks for this.
I just have a question for the developer (johnv):
Is the function: workflow_node_current_state() going to be depreciated at some stage, or even going to have a name change to i.e.: workflow_entity_current_state()?
Comment #6
johnv@Max_Headroom, the function workflow_node_current_state() will stay in the D7-version. Probably in D8 the name will change.
It is already widely used in other contrib modules, so I cannot change the interface. It also works for both workflowNode and workflowField.
IMO the current 2.x version is functional complete. So only bug fixes will enter. As feature requests, there are 2 grouped requests (Multi review, planned transitions).
I realize that the last weeks several issues are raised that I could answer or fix, but these weeks are full of holidays and projects.
Comment #7
Max_Headroom CreditAttribution: Max_Headroom commentedGoing back to my original question in #1, I have made this example.
When workflow has a state change, create a scheduled transition to next state.
In my example, say I have content (entity) that have the following states:
(creation)
Preview
Approved
Expired
At creation of the content, the state will automatically change to Preview as per normal workflow operations.
When a person previewed the content, he or she will change the state to Approved by means such as the workflow form of Workflow Field.
How ever, the content must expire after 30 days, so a scheduled transition must be created.
The code:
Initial thought would be to use hook_workflow with 'transition pre' or 'transition post' op. It does not work with 'transition pre' as it seems it cause a loop back which deletes the scheduled transition from the database as soon as it is created. Workflow Field does not call 'transition post' and it is recommended in the API to rather use an entity event. I then decided to use hook_entity_update.
Hope this is of help to somebody.
Comment #8
johnvComment #9
estoyausenteThese examples are so old and now doesn't work.
I'm trying to change the status programmatically for a entity and I don't know exactly the correct way. I have a little snippet like this:
My code doesn't work but I don't find any other example or a correct way to change the Workflow state for a entity. Somebody can help me? I think that it's a useful example for all people. I can create a documentation page to explain some concepts like this.
Comment #10
bogdog400 CreditAttribution: bogdog400 commentedSorry. I don't have an answer, but I'm commenting in the hope that someone will notice. I'm about to try to use the workflow module and it would be much easier if there was a bit more documentation. Like any documentation would be great.
Comment #11
jlscott CreditAttribution: jlscott commentedHere is a code snippet that creates and executes a workflow transition for a D8 site:
Note the need to manually update the workflow value in the field once the transition has executed successfully.
$entity_workflow is the initial value of the workflow state of the $entity (=node), and "fbad_submitted" is the destination state.
Comment #12
estoyausenteThank for the snippet! It works as expected but I have a doubt/appreciation.
I have this snippet in a drush command. The transaction is created correctly and as you say the new status is changed .... sometimes! drush command (by default) is executed as anonymous. Anonymous doesn't have enough permissions to execute the transaction and it throw an error. The transaction is created but the status changed throw an error.
I execute the drush command as a user 1 and it works, but It's a little bit hacky because when the transactions is created I set the 1 as a owner of the transaction. It not be clear for me, but it works; I only want to leave this message to help others (or me in the future :P)
Comment #13
jlscott CreditAttribution: jlscott commentedHi @estoyausente. The transition will execute as the user specified, so instead of loading the account for the "current user" in the first line of the snippet, you can load another user account that doe shave the required permissions.
Comment #14
estoyausentemm... yes, it has sense! Thanks for answering! Really the user 1 is the best user in my case, but is a good idea set it at begin of the snippet in place of executing the command as a user 1.
Comment #15
johnvPlease see also some example code in workfow_devel module.
Comment #16
johnv