Hi,

We were wondering if it’s possible to create a custom inbox not only associated to one task, but many tasks of the same process that share a common document.

And if it’s possible, how do we do it?

Hi,

I added the following lines in the getTaskSearchProvider method before the
resolveDataBinding:

taskSearchProvider.getSearchQuery().getTaskTypeID().setOperator(“in”);
taskSearchProvider.getSearchQuery().getTaskTypeID().setValue(TASK_TYPE_ID_ARRAY);

TASK_TYPE_ID_ARRAY ( was defined as a string array containing the task type ids of the tasks that you whant to see in the inbox.

I’m looking to do a similar thing to this, so I thought it’d be best to hijack this thread to flesh out some of the options available here.

My requirement is to (as much as possible) create a universal inbox that will only show people what they have access to, giving different permissions to different users for tasks (so some can be administrators of tasks that others are only users of, if possible mixed together into one view, so the inbox will let me be an admin for some tasks but not for others).

Step one: make a task inbox that can see all tasks I have access to.
Assumption (someone confirm this, please!) is that with any inbox, I can only see the tasks I have some sort of access to.
I’ve added the following code to the Inbox Results view, based on the previous post. What do you guys think about the logic and performance characteristics involved:

taskSearchProvider.getSearchQuery().getTaskTypeID().setOperator("<>");
taskSearchProvider.getSearchQuery().getTaskTypeID().setValue("-1");

Step two: create a custom business document that all processes will use, that will convey task-level information e.g. permissions if necessary
Work in progress. Will update here.

Step three: allow inbox to control permissions on a per-task basis based on user role and roles configured within the task.
Work in progress. How can I access this stuff programmatically?

Step four: allow inbox to control delegations based on task’s roles (so a task can only be delegated within a team as defined by a role, for example)
???

Any suggestions/other considerations at this stage? What do you guys think?

Update!

Sorry, never knew this before, but instead of the Step 1 code for the search, I can go to Task Overview → User Interfaces → InboxResults → select Default, click Update, select Modify task client options for selected task UI page → Next → select Search all task types when searching for task type inbox results → Finish.

Also, for Step 3, I can get the Task Type ID on the screen in the task list table by binding to this value:

#{activePageBean.taskDisplayProvider.taskInfo.taskTypeID}

Question is, how do I now get a list of roles from MWS that are allowed to access that task in some way, and their permissions?

Hi,

maybe this will be helpful How to check permissions in MWS programmatically - webMethods - Software AG Tech Community & Forums - this post contains snippet that demonstrates how to check access in MWS for page/thing.

RGDS,

Thanks, although it’s pretty difficult to work out what’s going on with the API at that level!

Here are two options:

accessPolicy.getAclView(context, ThingID) isn’t bad, but I’m struggling to parse what’s coming back. The IListView interface seems to block off all the functionality in the (pretty much undocumented) implementation.

accessPolicy.getAccessEx(context, ThingID, PrincipalURI) looks good, but at the moment returns a list of numbers from 1 to 255 or so, and the documentation on what they mean is nonexistent. If I inspect the IAccessRight.class file I get some meaning out of that, but it doesn’t cover every number, and half of it’s deprecated.

P.s. Also, why does the accessPolicy class have “Aces” instead of “Access” for its setters, and with so little documentation? Any MWS devs able to shed some light?

Hi,

as far as I understand documentation [http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite7/My_webMethods/7-2_CAF_and_MWS_Java_API_Reference/com/webmethods/portal/bizPolicy/biz/access/IAccessPolicy.html#getAclView(com.webMethods.portal.bizPolicy.IContext, com.webMethods.portal.service.meta2.thing.IThingID)] method getAclView should return list view of com.webMethods.portal.service.meta2.access.IAceView objects. So you should be able to iterate through this list:

IListView listView = accessPolicy.getAclView(context,itemID);
Iterator listViewIter = listView.iterator();
while ( listViewIter.hasNext() ) {
IAceView aceView = (IAceView) listViewIter.next();
}

IAceView has methods like: getGranted(); getDenied(); - those methods returns collections. Maybe during debuging session you will be able to see what those collections contains ? (It’s not specified in documentation).

RGDS,

Yes, so far I’ve tried the Granted one, and it’s empty! I’ll check the other two when I get to the office.

I haven’t tried this, but if you already know the names of the roles you want to check for, then the IAccessPolicy#getAccessEx would probably give you the most complete results since it would take both the entries in the ACL and the SecurityRealm information into consideration to give you the ‘effective’ rights for the user or role.

[url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_sp2/My_webMethods/8-2-SP1_CAF_and_MWS_Java_API_Reference/com/webmethods/portal/bizPolicy/biz/access/IAccessPolicy.html#getAccessEx(com.webmethods.portal.bizPolicy.IContext,%20com.webmethods.portal.service.meta2.thing.IThingID,%20com.webmethods.portal.system.IURI)[/url]

For example, you can take the collection returned and check against the IAccessRight.*_RIGHT constants:

IContext userContext = [TODO: get one of these]
IThingID thingId = [TODO: get the thingID to check rights on]
IURI roleURI = [TODO: lookup the URI for the user or role]

Collection grantedRights = accessPolicy.getAccessEx(context, thingId, roleURI);
if (grantedRights.contains(com.webmethods.portal.service.meta2.access.IAccessRight.READ_RIGHT)) {
//TODO: read rights were granted, so do something here...
}

Hi Eric

Thanks for this; I’ll have a play around with it today again.

I think really what I’d like is a way to pull out the roles that can work on each task. Then I can build delegation logic into the inbox that restricts the delegation of each task to those roles, and if the user select multiple roles I can build logic that only lets them delegate to roles that are the intersection of all the roles that can work on the selected tasks.

If this is the way to do that then I’ll go for it, but just to clarify in case there’s another way to do this!

Cheers

Rob

In fact, I’m pretty sure that won’t work; I don’t particularly want my access rights, I want the roles that can use the task in some way. I wonder if that’s even possible, given how the API seems to be structured?