1 of 1 people found this helpful
it depends on how do you start your process.
I assume that you use jbpm console at the moment?! If so by default console will not save name of the user who starts the process.
What I could suggest to try is to use form for starting and try to capture user name from request object as principal. Have not tried it my self but could be a one way to do it.
1 of 1 people found this helpful
The easiest way is use process variable to store the starter of a process instance, Then you could use a event-listener to send a mail. It is strange that jBPM didn't store the starter of a process instance. so if you want to know the starter's process instances, you have to create a new table and do some extension.
Thanks a lot for your answers guys!
But the question is... Can I do it without java code? only with forms (.flt) and processdefinition (jpdl.xml)?
My idea is in the starter form put any variable seems:
<input type="hidden" name="startUser" text=$getCurrentUser />
$getCurrentUser -> is the function/expresion that I'm searching.
And in the process definiton notification task put:
<mail g="166,258,115,45" language="juel" name="Mail">
<text>The task that you start are finished!</text>
It is Science fiction? or you think that i can do anything?
Thanks for advance for your help!!
AFAIK it's not possible to do it the way you want it do because the console has no way to pass the authenciated user in the console to the engine. This was on the roadmap to be addressed in the future but development is a bit stuck right now. I know this for sure for jBPM 4.x. I am not sure about jBPM 3.2 I have to say.
I have created jira issue for BPMC project (just to have it in the right place).
I did already implementation for that so user name is stored as process variable automatically and transparently (so to say to the initiator of the process).
Please vote for it, this could help to prioritize it and hopefully will be included in the next release of the console.
It's more an issue of jBPM than of the console. But you're right the console would need a change, too. However jBPM's API is even already prepared if you take a look at the javadocs.
Take a look at the method called setAuthenticatedUserId(java.lang.String authenticatedUserId
1. the console has knowledge of the authenciated user (he had to authenciate to access the console)
2. the console needs to call this method each time the user invokes a method on the API (like starting a process) to pass on the information
3. jBPM needs to store the information somewhere (maybe in a process variable but rather not) to expose it to the process and user
IMHO it should be stored in the history data together with the information about the start event and it should be queryable via the API.
It could be exposed via the execution context to the process.
The issue is more or less an issue bothering people who use the included console. People using their own GUIs just store the name of the process starter in a process variable and use this variable later on - for example to do calucations, assign a task to him or just refer to him. Setting the starter via the API would be cleaner.
The issue (https://jira.jboss.org/jira/browse/JBPM-2482) mentions the place in the source code which is affected. Whenever a new process instance is created the supplied user needs to be stored somewhere. Right now the code is not dealing with the supplied user name.
This issue is related or almost the same. I think it refers to the part of the API which I mentioned:
Because of this issue https://jira.jboss.org/jira/browse/JBPM-2416 using a process variable is not a good either. This issue deals with audit capabilities regarding method invokations on the API. Sometimes not only the data coming from tasks in the process is interesting but also who has started, stopped or affected a process in some way.
you're right. I took the simplest path of solving it but obviously not the best one.
I have some ideas and questions so perhaps we could move to development forum and discuss it further and as an outcome update both jira issues with final ideas. What do you think?!