User "workable" tasks

[Gromofiz]

Hi Ralph

I've noted that the method

WorkflowService#getWorkListByWriteAcces

does not return any items when the principal has the MANAGER role only, and no writeaccess.
Looking at the "Access Level Matrix", here https://www.imixs.org/doc/engine/acl.html,
I was supposing that items should have been returned, ignoring ACL.

Do I miss something?

In another way the question is: how can I get the list of workitems a user can work on
considering both ACL (for example $writeaccess) and imixs' roles (AUTHOR, EDITOR AND MANAGER)?

Enzo

[rsoika]

HI @Gromofiz

good point!
Yes you are right. In your scenario the method getWorkListByWriteAcces returns no results.
The MANAGER role has unrestricted access. So she can read and edit any workitem in your workflow-instance and you don't need an explicit read or write access in the ACL.

But now as a result, you can not make use of the getWorkListByWriteAcces method, because this method tests if the user is listed explicit with its name in the item $writeaccess. And this is not the case in your scenario.

From the modelling perspective, it is totally fine if you grant also a user with MANAGER access a write access in the ACL, even if they don't need it. And then, the method call getWorkListByWriteAcces would resolve a result.

If you can't change your model, you can solve this problem in you backend method call if you test the users Role first:

if (workflowSerivce.isUserInRole("org.imixs.ACCESSLEVEL.MANAGERACCESS")) {
 // return all data
 return workflowSerivce.getDocumentService().getDocumentsByType("workitem",....);
} else {
 // return by explicit write access
 return workflowSerivce.getWorkListByWriteAcces(....);
}

But this is a very special use case in my eyes.

Let me know if this solves your problem.

[Gromofiz]

Hi Ralph

First, you shouldn't answer emails at night time! ;-)
Second ...
if I change the model, modifing the task's ACL adding the user admin, the task is returned as you told.
The drowback is that if I change the list of administrators, that is the users having the MANAGER role, I have to change the ACL of the task too and then update/deploy the model again.

Then .. I had a look at the code of getWorkListByWriteAcces and there is:

        String accessRoles = documentService.getAccessRoles();
        String roleList = "org.imixs.ACCESSLEVEL.READERACCESS,org.imixs.ACCESSLEVEL.AUTHORACCESS,org.imixs.ACCESSLEVEL.EDITORACCESS,"
                + accessRoles;
        // add each role the user is in to the name list
        StringTokenizer roleListTokens = new StringTokenizer(roleList, ",");
        while (roleListTokens.hasMoreTokens()) {
            String testRole = roleListTokens.nextToken().trim();
            if (!"".equals(testRole) && ctx.isCallerInRole(testRole))
                nameListBuffer.append(" OR $writeaccess:\"" + testRole + "\"");
        }
        nameListBuffer.append(")");

So I tryed to:

1. add org.imixs.ACCESSLEVEL.MANAGERACCESS in ejb-jar.xml so documentService.getAccessRoles() returns "org.imixs.ACCESSLEVEL.MANAGERACCESS"
2. update the model adding "org.imixs.ACCESSLEVEL.MANAGERACCESS" in "readaccess" ACL of the task

When "admin" calls getWorkListByWriteAcces the search term is:
( type:"workitem" AND ($writeaccess:"admin" OR $writeaccess:"org.imixs.ACCESSLEVEL.MANAGERACCESS") $writeaccess:"admin" )

and even if a workitem in the db has:
$writeaccess=[org.imixs.ACCESSLEVEL.MANAGERACCESS, gloria]
no task is returned and .. this is a mistery to me! :-)

Using your example I ended up with

 /**
    * Returns a paged list of tasks viewable to the connected user.
    *
    * @param start start index
    * @param limit item page size
    * @return a list of task
    */
   public ItemsList<Task> listAll(int start, int limit, HttpServletRequest servletRequest) throws QueryException {

       if (workflowService.isUserInRole("org.imixs.ACCESSLEVEL.MANAGERACCESS")) {
           // return all data
           String query = "SELECT document FROM Document AS document ";
           query += " WHERE document.type = '" + Constant.TYPE_TASK + "'";
           query += " ORDER BY document.created DESC";
           List<ItemCollection> workitems = workflowService.getDocumentService().getDocumentsByQuery(query, start, limit);
           List<Task> tasks = toTaskList(workitems);
           int totalCount = workflowService.getDocumentService().count(" type:\"" + Constant.TYPE_TASK + "\"");
           return new ItemsList<Task>(tasks, totalCount, start, limit);
       } else {
           // return by explicit write access
           List<ItemCollection> workitems = workflowService.getWorkListByWriteAccess(Constant.TYPE_TASK, limit, start, null, false);
           List<Task> tasks = toTaskList(workitems);
           int totalCount = countWorkListByWriteAccess(Constant.TYPE_TASK, servletRequest);
           return new ItemsList<Task>(tasks, totalCount, start, limit);
       }
   }

that seems to work. I have to better check it!
Is it good to you!?

[rsoika]

HI Enzo,
yes I've also been thinking about expanding the method getWorkListByWriteAccess with the role org.imixs.ACCESSLEVEL.AUTHORACCESS. There's seems to be no reason not to it to keep the implementation consistent.

you say it did not work for you - but you wrote

update the model adding "org.imixs.ACCESSLEVEL.MANAGERACCESS" in "readaccess" ACL of the task

it should be the ACL writeaccess and not the readaccess

You implementation of the listAll method is fine. I just recommend to use the method find istead of getDocumentsByQuery

List<ItemCollection> workitems = workflowService.getDocumentService().find("type:"+Constant.TYPE_TASK, limit, start); // pageSize, pageIndex

you lost the paging logic if you switch to the getDocumentsByQuery...

[Gromofiz]

I mistyped, I wrote readaccess instead of writeaccess .
Anyway I updated the model and created a task whose workitem had the right property
$writeaccess=[org.imixs.ACCESSLEVEL.MANAGERACCESS, gloria]
I deserialized its data property of document table.

[rsoika]

I added a feature request: #826