[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
15 years, 7 months
[JBoss JIRA] Created: (JBPM-2814) Trouble using a custom BusinessCalendar because of 'new BusinessCalendarImpl' in BusinessDayCalendarBinding
by Per Christian Henden (JIRA)
Trouble using a custom BusinessCalendar because of 'new BusinessCalendarImpl' in BusinessDayCalendarBinding
-----------------------------------------------------------------------------------------------------------
Key: JBPM-2814
URL: https://jira.jboss.org/jira/browse/JBPM-2814
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Per Christian Henden
Fix For: jBPM 4.x
I've followed the howto on the JBPM webpages to replace BusinessCalendarImpl with my own implementation. My custom BusinessCalendar.add is called, that works, but in JBPM's BusinessDayCalendarBinding. java 'new BusinessCalendarImpl' is called and a BusinessCalendarImpl is used throughout the class.
This choice results in a problem when setting the 'days' field based on parsing jbpm.business-calendar.cfg.xml. The field is written to the 'new BusinessCalendarImpl' and not to my custom BusinessCalendar. This means that in my custom BusinessCalendar implementation I have no access to that information ('days' is null).
Other places in the JBPM code a processEngine.get(BusinessCalendar.class) is done to get an instance of the (custom) BusinessCalendar.
--
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
15 years, 7 months
[JBoss JIRA] Created: (JBPM-2813) Do not throw exception from BusinessCalendar when calculated end date ends up in the past
by Per Christian Henden (JIRA)
Do not throw exception from BusinessCalendar when calculated end date ends up in the past
-----------------------------------------------------------------------------------------
Key: JBPM-2813
URL: https://jira.jboss.org/jira/browse/JBPM-2813
Project: jBPM
Issue Type: Patch
Security Level: Public (Everyone can see)
Reporter: Per Christian Henden
Fix For: jBPM 4.x
The case where the subtract method is called with a duedate expression and reference date that resolves to a date in the past is handled by throwing a JbpmException ("duedate <date> ends in the past"). While this may sound like a good decision in theory, it is problematic in practice.
As a user of the API it means I have two choices when calling the subtract method. I must either -resolve the calcuation myself- before calling the method, to avoid the exception, or I must catch the -generic- JbpmException and decide on a duedate myself not knowing what went wrong.
When someone requests a date that is in the past in this way there's basically three options:
1) Let them have it. - This seems like a silly solution to me, duedates in the past doesn't make sense.
2) Throw an error. - In this case a specific exception should be thrown so that the user of the API can know why he got an exception.
An alternative to today's solution is to throw a less generic exception, maybe 'DueDateIsInThePastException' or IllegalArgumentException.
3) Return the current date, i.e. return Clock.getTime(). - Optionally a warning that the date was overriden to not be in the past can be logged, but this seems unecessary to me.
Attached patch implements alternative #3 (against trunk/revision 6208), which I believe is the best choice.
--
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
15 years, 7 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
15 years, 7 months
[JBoss JIRA] Created: (JBPM-2818) Leaving node in super-state throws org.jbpm.JbpmException: cannot leave Node without leaving transition
by Toshiya Kobayashi (JIRA)
Leaving node in super-state throws org.jbpm.JbpmException: cannot leave Node without leaving transition
-------------------------------------------------------------------------------------------------------
Key: JBPM-2818
URL: https://jira.jboss.org/jira/browse/JBPM-2818
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.8
Reporter: Toshiya Kobayashi
Leaving <node> in <super-state> throws
org.jbpm.JbpmException: cannot leave Node(node2) without leaving transition
when I execute process definition like:
================
<process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="id41">
<start-state name="start">
<transition to="super-state1"></transition>
</start-state>
<super-state name="super-state1">
<transition to="end"></transition>
<node name="node1">
<transition to="node2"></transition>
</node>
<node name="node2">
</node>
</super-state>
<end-state name="end">
</end-state>
</process-definition>
=================
Note: <node name="node2"> doesn't have its own transition. but I expect super-state's transition is available then.
The process definition works if you test via ProcessDefinition.parseXmlResource(String xmlResource) without DB/Hibernate (like org.jbpm.graph.exe.SuperStateActionExecutionTest.testNestedSuperStateLeaveViaSuperStateTransition()).
What's the difference?
org.jbpm.graph.def.Node:
=========
public Transition getDefaultLeavingTransition() {
Transition defaultTransition = null;
if (leavingTransitions != null) {
// Select the first unconditional transition
for (Iterator i = leavingTransitions.iterator(); i.hasNext();) {
Transition auxTransition = (Transition) i.next();
if (auxTransition.getCondition() == null) {
defaultTransition = auxTransition;
break;
}
}
}
else if (superState != null) {
defaultTransition = superState.getDefaultLeavingTransition();
}
return defaultTransition;
}
=========
The logic of getDefaultLeavingTransition() depends on whether leavingTransitions is null or not. But in case that hibernate kicks lazy initialization, leavingTransitions will be a zero sized collection, not null.
BTW, I think the concept that super-state's transition can be chosen from nodes inside is better to be documented.
--
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
15 years, 7 months