The most easiest way to store the start of a process is extending the JBPM4_EXECUTION, we could add a starter column, or something like this.
Also, we should consider the authentication requirments for the starter of process. Who could be allowed to start this process definition, maybe we should use PARTICIPANTS to make a relationship between ProcessDefinition and Identity.
yes, you are right. My intention was to provide a simple yet quite usable way of getting hold of user information while starting/signaling process instance.
What you described is much wider in scope and touches authorization. I meant just to give a possibility to process designers to decide if they are interested in having user information not storing it automatically, at least not at this point.
In addition, any other request information could be provided together with user info, such as additional request parameters, remote host information, headers, etc.
The most easiest way to store the start of a process is extending the JBPM4_EXECUTION, we could add a starter column, or something like this.[...]
I read the related forum posts and the JIRA about this, maybe i still miss the point here, but extending the JBPM4_EXECUTION table for this seems wrong to me. A much better approach imho would be to keep that information in a swimlane like it is done in JBPM3 ( see: http://docs.jboss.org/jbpm/v3/userguide/taskmanagement.html section 11.7)
...and thanks for your great work on jBPM4
I think you are right. The swimlane is much better than just add a assign column in process instance. Thank you for your link. I will read it carefully.
As HuiSheng Xu ask me, I send you my point of view about that subject...
AFAIK, there are serveral needs linked to put user information in a process.
- find some process by userid (by adding userid in process instance info),
- enforce the usage of identity, user who start the process could be the default assignee (with a particular EL for exemple),
- Check if the user could start an instance of a particular process (need some adds in jpdl to descripe that !)
- capturing the initiator shouldn´t be linked in any way with tasks. We have processes withtout tasks, but we still need the information who started this process
- we use a swimlane for the initiator. The swimlane evaluates a variables we pass in on process start. In the process we use this swimlane to reference to the initiator.
- after a process has finished the initiator information shoudn´t be lost. We need to be able to find process instances (running and finished) "per initiator". Therefore, we additionally create a history variables to persist this information.
Currently, we provide the initiator information on process start to let the swimlane know the value. And then, we create a history variable for it, which is (programatically) only possible after the process has been started. A bit of the same work twice, but it works and happens automatically in our system. We did´t want to the user to specifiy history variables it in the process definition for the initiator, as it´s a requirement that must always be met.