roles who can start a certain task

, ,
1

Hi,

does anyone knows how to get the list of roles with permissions to start a new task instance for a given task type?
There’s a portlet named “Permissions Management” which comes with MWS that enables us to configure the permissions of a certain task. How does it gets the list of roles?

thanks,
Bruno

2

It is managed by the privilege Queue New Task. In Designer, open up your Task Application’s privileges.xml and look for <basic name=“Queue New Task” …

You’ll find an alias that looks like: 4884EF06-2D2E-A3E3-BECE-3C65B6242FFE.privilege.queuetask

You can see what runtime permissions have been granted by looking up the permissions for that object. You can browse directly with http:///4884EF06-2D2E-A3E3-BECE-3C65B6242FFE.privilege.queuetask and then select Permissions from the menu (as sysadmin)

3

I’d also recommend reading reviewing “Working with Task Privileges” in the Designer On-line Help.

4

How can I get the tasks a user can queue programmatically?

5

This looked promising, but did not work:

TaskContentProviderExtended tcpe = new TaskContentProviderExtended();
tcpe.setTaskTypeID(item);
tcpe.getCanUserQueueNewTask();
return hasAccess;

My requirement is to build a dynamic menu with links to create the tasks the user can currently queue, and separately links to inboxes of tasks the user can complete.

Thanks for any assistance.
Theo

6

That code looks promising. What isn’t working.

7

Hi Mark. It does not return “true” for task types that my roles have full access to.

Here is what I have so far:

I can get a list of dynamic roles my user is currently a member of.

I can get a list of all task types.

What I need to do is filter the list of links to available inboxes to only display task types for which I have permissions to accept, and filter a list of links that launch a new process in a similar manner by the permissions to queue a new task.

It seems the APIs used internally by the task engine and MWS are not documented, or maybe I just haven’t found the right combination. This feature is critical to my customer as a business requirement and is holding up our production pilot roll-out.

Any help would be greatly appreciated.

Thanks,
Theo

8

I’ve attached a project that demonstrates the API. One thing that is important to note, is that when checking for permissions for whether a user can accept a task, that API needs to know the task instance. (unless you are in an Admin role in which case the logic is bypassed and true is always returned).

To use:

  • Import this project into Designer and publish
  • Go to the Task Start for one of the tasks and queue a new task
  • Go to permissions management and grant a user access to the task type for one of the tasks you queued
  • Go the to TaskPermissionsChecker portlet as the user and see how the permissions evaluate

Hope this helps.
–mark
TaskPermissionsProject.zip (81.1 KB)

9

Thanks for this Mark. Unfortunately, the individual task instances don’t help me. What I need is the task type, such as what back the attached screen shot.

In MWS we can set the task type permissions using the UI at webm.apps.tasks.admin.system-wide.permissions.

Is there no programmatic way to get to those permissions?

mws task ui.jpg
mws task ui.jpg497×541 74.2 KB

10

Now that I have looked at your sample, I see it assumes if I have permissions on one task, that be default I will have permissions on all tasks of this type. Rather inelegant, but I guess it will work.

Thanks,
Theo

11

One problem - what if there are no tasks in the inbox?

12

You’ll see that there are a variety of individual getXXX permissions on the TaskContentProvider. The sample project only uses one of those apis, there are many others.

There is no data level security with task instances, so most of the permissions either apply to the taskType (such as canQueueTask), or based on the state of a single task (canAccept).

You won’t be able to check permissions on the apis that require a specific task.

13

Using the task queries gave us unacceptable performance. However, canUserQueueNewTask() did the trick.

Thanks!
Theo