I’m not quite sure what the “add” does - I saw this on another post but there doesn’t seem to be much different here.
Can I assume that with just the ‘saveTask’ I can use this for assigning tasks to various individuals - but they are totally outside of the case instances that they might be involved in?
The easiest way how to create a case task is to define sentry in the cmmn model which will be used to enter the task. In that case the task is created in the case context with all scopeIds set.
As an cmmn example see
and test
To add “adhoc” tasks to the case you have to set scope Ids properly.
Thanks for this - I was actually after the ad-hoc side of things. Thanks for the pointer in terms of scope IDs. I’ve tried a few things this morning but I’m hitting a SQL syntax error - so presumably some field I’m not setting that then gets caught in the prepared statement?
//scope id is the case instance id
//subscope id ? stage? it’s the id of the plan instance (from runtime service) - but can’t be set it through the builder for some reason?
TaskBuilder taskBuilder = cmmnTaskService.createTaskBuilder();
TaskBuilder tb = taskBuilder.name(“Some name to the task.”).scopeId(caseInstance.getId()).id(“myid”).scopeType(ScopeTypes.CMMN);
Task task1 = tb.create();
cmmnTaskService.saveTask(task1);
I’m doing something very similar while creating a Task, however my question is regarding PlanItemInstances, as each Task has a corresponding PlanItemInstance, from which it is possible for us to retrieve the StageInstanceId to attach a Task to a Stage.
Tasks created through the XML are instantiated with the SubScopeId = The Id of the PlanItemInstance of a HUMAN_TASK, and this PlanItemInstance has a corresponding StageInstanceId of the Stage it is in.
Is it possible to create this PlanItemInstance in any way programmatically, or alternatively, would it make sense to set the SubScopeId of the newly created Task to be the StageInstanceId?
subScopeIds are used internaly to recognize into which plan item instance task belongs to. You can use it in your solution for any purpose, but I would not use them to store something else.
To recognize stage into which tasks belongs to you can retrieve parent task -> parent planItemInstance.
Thanks for your help so far on this - are we basically staying that “create custom/dynamic tasks” (after the case has started) in a particular stage of the case is not supported? I’m a bit surprised about this as this seems a fairly common scenario?
Similarly, I assume that creating tasks dynamically that “when they are all done” fire another task (e.g. tasks linked to sentries) would also be unsupported?
Thanks - will try this out - do you have an idea when the next formal release is so that we can baseline to versioned artefacts if we choose to go that way - looks from release note timings that it could be soon?