[JBoss JIRA] Created: (JBPM-2805) Add access to event type in EventListener interface
by Mike Martin (JIRA)
Add access to event type in EventListener interface
---------------------------------------------------
Key: JBPM-2805
URL: https://jira.jboss.org/jira/browse/JBPM-2805
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.x
Reporter: Mike Martin
Add the ability to determine the event type ("start" or "end") from within an EventListener implementation. There should also be the ability to easily determine the name of the process definition step where the event occurred.
This makes it possible to write a single event listener that handles many different kinds of events. As far as design, it seems odd that the notify() method has a *Execution parameter, rather than an "event" parameter that contains all information about the event that occurred; the latter would be more in line with the way event listener interfaces are usually designed in Java.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBPM-2773) TaskService: allow search for assigned candidate tasks
by Kai Weingärtner (JIRA)
TaskService: allow search for assigned candidate tasks
------------------------------------------------------
Key: JBPM-2773
URL: https://jira.jboss.org/jira/browse/JBPM-2773
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3
Environment: any
Reporter: Kai Weingärtner
Fix For: jBPM 4.x
I would like to be able to find all tasks a user is a candidate for, regardless of the task being assigned or not. Currently the TaskQuery.candidate - filter also sets the unassigned filter. Thus, already assigned candidate tasks can never be found.
Possible use cases:
- a task needs to be reassigned due to sickness of the assignee
- user A needs to take user B's task, when a customer approaches user A about a task concerning him
Solution:
- don't add the unassigned filter in the candidate filter of TaskQuery but make them separate. To achieve the current result, one could set both filters explicitly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBPM-2753) Simplify map specification in jPDL for simple case
by M M (JIRA)
Simplify map specification in jPDL for simple case
--------------------------------------------------
Key: JBPM-2753
URL: https://jira.jboss.org/jira/browse/JBPM-2753
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.2
Reporter: M M
Allow simpler specification of maps in the case where both the key and value are strings, by allowing key and value to be specified as attributes of the <entry> element, instead of as child elements. This will greatly reduce the verbosity of the XML for this common case.
The following
<custom class="com.company.CustomActivity" name="some_step">
<property name="inputs">
<map>
<entry>
<key>
<string value="input_file_a" />
</key>
<value><string value="some_filename" /></value>
</entry>
<entry>
<key>
<string value="another_input" />
</key>
<value><string value="1234" /></value>
</entry>
</map>
</property>
<transition to="next_thing"/>
</custom>
would become simpler, as
<custom class="com.company.CustomActivity" name="some_step">
<property name="inputs">
<map>
<entry key="input_file_a" value="some_filename" />
<entry key="another_input" value="1234" />
</map>
</property>
<transition to="next_thing"/>
</custom>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBPM-2792) Data manipulation with HQL / SQL nodes
by Peter Horvath (JIRA)
Data manipulation with HQL / SQL nodes
--------------------------------------
Key: JBPM-2792
URL: https://jira.jboss.org/jira/browse/JBPM-2792
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.x
Reporter: Peter Horvath
Currently HQL / SQL nodes only allow you to run queries. It would be great if it was possible to run data manipulation operations (INSERT / UPDATE / DELETE) as well.
It should be quite easy to implement this by adding a new possible flag to the hql / sql node and calling org.hibernate.Query.executeUpdate() from org.jbpm.jpdl.internal.activity.HqlActivity.perform(OpenExecution) method:
if(isUpdate) { // isUpdate: this a new flag that indicates that this is a data manipulation operation
// execute update and store the number of entities / rows affected (inserted, updated or deleted) by this operation into the result variable
result = q.executeUpdate();
} else { if (isResultUnique) {
result = q.uniqueResult();
} else {
result = q.list();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months