Hi,

We have a business scenario where the users can search for all the tasks in the system.

The users should also see tasks which are assigned to Roles they are not part of.

Unfortunately if in the results list is at least one task for which the user does not have access we get an error message and no result is displayed.

For the search we use an TaskInboxSearchContentProvider.

This is what we have tried:

- create Search-Role on MWS (give functional privilegues to the task type)
- create technical user which belongs to the search role
- on task search in CAF: set

myTaskSearchProvider().getSearchQuery().setPrincipalID(‘myTechnicalSearchUser’)

The above solution does not work.

Do you know how we could run the search with the privileges of a different user than the one that is logged in?

br,
Vlad

I’d like to talk you out of your approach, but if that fails i’ll help you with the apis you need to invoke…

I’m not sure the size of the active tasks, but classically this will be a very slow performing query. I doubt that your users will be happy with the responsiveness.

Assuming you can’t change this requirement, i’d like to explore the exception that you see.

If the exception is during the rendering phase of the table, then maybe you can do a permissions check prior to rendering each row and filter out the rows that the user doesn’t have permissions to see.

After all, if you do impersonate a super-user, what happens when the end user attempts to click on one of those tasks that they don’t have permission to see? They’ll get some sort of Access Denied error and will be frustrated about what tasks they can and can’t click on.

Regards,
–mark

Hi,

This search scenario already exists and it is used by the users.

The problem appears after we have installed MWS_fix6.

The users only need to see the tasks in the list, they can not access the details of the tasks.

Can you please provide a sample for the “impersonate” functionality?

br,
Vlad

If the problem only appears after installing Fix6, then you should probably file a ticket.

To impersonate a user use the following:

IContext context = ContextFactory.acquireContext(true);
IThingID currentUserID = context.getUserID();
boolean currentIsAdmin = context.isAdminSession();
try {
context.impersonate(IThingID userID, boolean isAdmin);
...
} finally {
//restore
context.impersonate(currentUserID, currentIsAdmin );
}

Have a look here: http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8_ga/My_webMethods_and_Task_Engine/8-0-SP1_CAF_and_MWS_Java_API_Reference/index.html for the IContext javadocs.

Regards,
–mark

Hi Mimel,

The problem with the sample is that I do not know how to obtain an instance of

IThingID  

for the user that is not the current user.

context.impersonate(IThingID userID, boolean isAdmin)

br,
Vlad

You’ll have to use our lower level Directory APIs to get this information:

IContext context = ContextFactory.acquireContext(true); 
IBizPolicyManager bpm = (IBizPolicyManager) PortalSystem.getBizPolicyProvider(); 
IDirSystemBizPolicy dirSystemPolicy = (IDirSystemBizPolicy) bpm.getBizPolicy(IBizPolicyNames.DIRECTORY_SYSTEM); 

// lookup user by UID 
IDirUser user = (IDirUser) dirSystemPolicy.lookupPrincipalByID(context, <userID>, IDirSystem.TYPE_USER); 
IThingID userThingID = user.getDirectoryPrincipalID();

Regards,
–mark

Hi,
Thank you Mark. I will let you know if the solution works.

br,
Vlad

Hi,
SAG provided a fix for this problem, it will probably be included in MWS fix 8 or higher.

br,
Vlad