I need a reference to the instantiator in a Decision Task. I need assign a decision task to the instantiator only allow them to transition. I can override the CanTransition method, but how do I compare the current user with the Instantiator value? I've tried inheriting from IRunnableTask, but that just puts me in a loop since I don't transition the task, just get the workflow.Instansitor value.
Task object doesn't have a handle on the parent workflow; I've checked.
I came up with another solution. I'm launching a dialog with the manual instantianion page that comes with the package, so users can start the workflow with a comment from the start. I disabled all events on the Instantiator record and launch the dialog on the "BeforeSendToPublish" event. (set in a startup handler)
Solves my problem.
I'm looking into building a workflow/bpm package for Umbraco 7. I like the ideas in your package, but it doesn't work well in a team/source control environment.
If I push the .bin files to source control, I have to also copy the database tables/records with the correct ids because the .bin file names try to match with the ids.
If I modify the code for a custom task after I've created the workflow, the .bin will not open and I get "key does'nt exist", or something to that effect; and I have to recreate the workflow from scratch.
I've done this several times and it sporadically fails to load the designer if there are changes after it is created.
It would be ideal if the workflow config files where json, xml files, or stored entirely in the db, instead of binary files, and there was a Courier provider for workflow.
I understand the challenge of moving workflow instances and config through environments, but we never needed to do that really.
Tasks are serialized as binary because we have to be able to serialise custom tasks, which just isn't very easy to do when you don't know which properties the custom tasks will have.
Mind you - I wrote this about 5 years ago now so I'd expect one could use JSON.NET or similar to do the serialisation with some work.
As you'll see in the code *everything* is an interface so replacing the component that deals with persistence should be pretty straight forward.
How to get the Instantiator in a Decision Task
I need a reference to the instantiator in a Decision Task. I need assign a decision task to the instantiator only allow them to transition. I can override the CanTransition method, but how do I compare the current user with the Instantiator value? I've tried inheriting from IRunnableTask, but that just puts me in a loop since I don't transition the task, just get the workflow.Instansitor value.
Please assist asap!
Hi Daniel,
If I'm honest I haven't used my own product for a while, so I'm unsure!
A task object should give you a reference to the owning workflow object, which I assume would have the Id of the Instantiator?
Or not :)
Let me know if not, and I'll take a look!
Task object doesn't have a handle on the parent workflow; I've checked.
I came up with another solution. I'm launching a dialog with the manual instantianion page that comes with the package, so users can start the workflow with a comment from the start.
I disabled all events on the Instantiator record and launch the dialog on the "BeforeSendToPublish" event. (set in a startup handler)
Solves my problem.
I'm looking into building a workflow/bpm package for Umbraco 7. I like the ideas in your package, but it doesn't work well in a team/source control environment.
Would you care to elaborate on "doesn't work well in a team/source control environment"
I'm not sure what you mean by that?
Thanks.
If I push the .bin files to source control, I have to also copy the database tables/records with the correct ids because the .bin file names try to match with the ids.
If I modify the code for a custom task after I've created the workflow, the .bin will not open and I get "key does'nt exist", or something to that effect; and I have to recreate the workflow from scratch.
I've done this several times and it sporadically fails to load the designer if there are changes after it is created.
It would be ideal if the workflow config files where json, xml files, or stored entirely in the db, instead of binary files, and there was a Courier provider for workflow.
Hi Daniel,
I understand the challenge of moving workflow instances and config through environments, but we never needed to do that really.
Tasks are serialized as binary because we have to be able to serialise custom tasks, which just isn't very easy to do when you don't know which properties the custom tasks will have.
Mind you - I wrote this about 5 years ago now so I'd expect one could use JSON.NET or similar to do the serialisation with some work.
As you'll see in the code *everything* is an interface so replacing the component that deals with persistence should be pretty straight forward.
If you need any input let me know.
is working on a reply...