ParticipantAdapter - update ACL and owner without an event

[chrisw14]

Hi,
with AccessPlugin and OwnerPlugin it was possible to refresh the ACL and owner without an event like here:

			AbstractPlugin accessPlugin = new AccessPlugin();
			AbstractPlugin ownerPlugin = new OwnerPlugin();
			try {
				accessPlugin.init(getWorkflowService());
				ownerPlugin.init(getWorkflowService());
				workitem = accessPlugin.run(workitem, task);
				workitem = ownerPlugin.run(workitem, task);
			} catch (PluginException e) {
				e.printStackTrace();
			}

Is this also possible with the new ParticipantAdapter? Unfortunately, all public methods of ParticipantAdapter wants to have an event but in my case the $taskid is set and I need the ACL and owners for a new workitem. Doesn't work since the update to 5.0.1 and using the new method ParticipantAdapter.execute(...).

[rsoika]

I am sorry but the version 5.0.1 was released to fast. We found lately some bug forcing us to a lot of refactoring. It is not recommended to use the version 5.0.1
In version 5.0.2 we fixed the issues:

• OwnerPlugin is back as before version 5.0.1
• the ParticipantAdapter was renamed into AccessAdapter
• the new Adapter concept is now split into to types of Adapter classes - SignalAdapter and GenericAcapter

But version 5.0.2 is not yet released because we need to make sure that everything works this time.

In version 5.0.2 the method "execute()" of the AccessAdapter expects either a Task or Event object. Both provide the ACL model settings. So you can call this method. But the Access Control should not be changed outside of the processing life cycle. It is now fully controlled by the WorklfowService and the WorkflowKernel.
Why do you think you need to call the AccessPlugin/adapter before a workitem was processed?

[chrisw14]

Okay, good to know.

Why do you think you need to call the AccessPlugin/adapter before a workitem was processed?

In my application you can create a new workitem. After creating this workitem, it's not saved yet.
You have a button to save the workitem explicitly. But before saving the workitem, the read / write and owner rights should be set because these values are used to show who has read and write access. It's a bit weird if you have to save the workitem first if you want to see these values...

If I remember correctly, your create methods of WorkflowController saves the workitem directly. I don't like this behaviour. And in WorkflowController.create() deprecated fields are used, no rights are set from the model. Is it possible to create a workitem without deprecated fields and with all computed fields (rights, owner, workflowgroup, ...)?

[rsoika]

ok - in our own applications we do not work in this way. A new workitem (not yet saved) is empty and has no ACLl values. This is also a kind of status. Why should the user see the access list?

The create method of the WorkflowController is setting the new fields:

• $workflowgroup
• $workflowstatus
• $taskid

Typical a new workitem is created by calling the method create(model, task, ref)

in JSF:

<h:commandButton actionListener="#{workflowController.create('1.1',1000,'')}"
				action="/pages/workflow/workitem" value="Create New Ticket">
</h:commandButton>

...but you are right, maybe we can improve the create method. As we know modelversion and taskID we can load the task from the model and call

accessAdapter.execute(workitem,task)

This would update the ACL. What do you think?
It's up to the application to save or not to save the workitem. In any case the workflowService updates the ACL immediately before saving...

[chrisw14]

Why should the user see the access list?

If I want to define additional readers or writers of the workitem, I always use the items $readaccess and $writeaccess directly.

I tested the create method yesterday and it didn't set anything. But I have to test why.

accessAdapter.execute(workitem,task)
This would update the ACL. What do you think?

This would be great, thank you!

[chrisw14]

accessAdapter.execute(workitem,task)

Should the method work with 5.0.2 ? For me, it doesn't if I'm usign a task instead of an event as a parameter.

[rsoika]

yes this method can be used in version 5.0.2

[rsoika]

sorry - please try the following method call:

accessAdapter.updateACL(workitem, new ItemCollection(), task);

This should work

[chrisw14]

Great! This works. Thank you

[chrisw14]

Sorry, I have to reopen this issue again.
To update $readAccess and $writeAccess without an event, I can use:
accessAdapter.updateACL(workitem, new ItemCollection(), task);

But how can I update $owners without an event?
The following throws the following exception:

ownerPlugin.init(getWorkflowService());
workitem = ownerPlugin.run(workitem, task);

Exception:
org.imixs.workflow.exceptions.ProcessingErrorException: processing error: $eventID undefined (0)

Thank you.

[rsoika]

Have you tried to give your workitem a dummy $eventid (e.g. 1)

I am still not convinced about the way you are using the workflow engine. Calling the AccessAdapter and OwnerPlugin against an empty (new) workitem is not a way we will active support. So in the future this can always break with new versions.

The OwnerPlugin expects an event object and not a task object.
And the OwnerPlugin calls internal :

this.getWorkflowService().evalNextTask(adocumentContext);

This means the workflowService looks into your BPMN model and computes the target Task your workitem instance will be associated with after the processing live-cycle is completed. This means the method looks for follow-up events and conditional events and so on...

So at least if you really want to go this way

1. your workitem MUST be assigned to a valid task within your model
2. you need to load an existing event object from the your model assigned to the current task. (something like ... myBPMNModel.getEvent(taskID,eventID)
3. you need to call the init method first to ensure that a active instance of the WorkflowService is assigned to the OwnerPlugin.

Maybe it is more save to use the Imixs SimulationService. This will run a complete processing life cycle without saving the woritem. We use this Service in the Imixs Test Environment.

[chrisw14]

With dummy ID:

Caused by: org.imixs.workflow.exceptions.ProcessingErrorException: BPMN Event 1.1 not defined by version 'Mitarbeiter'
	at org.imixs.workflow.WorkflowKernel.loadEvent(WorkflowKernel.java:1085)
	at org.imixs.workflow.WorkflowKernel.eval(WorkflowKernel.java:369)
	at org.imixs.workflow.engine.WorkflowService.evalNextTask(WorkflowService.java:1071)

Hm okay I already wondered about the evalNextTask method why it's necessary.

I already used the SimulationService but it's really "expensive" to compute all tasks.
Now I want to enumerate only about all model tasks and want to have a list of users or roles who will be the owners of the tasks. Would be great if there would be an easier method to archieve this like
ownerPlugin.getOwners(taskId).