Show Other User's Inbox not working as expected in Workflow after upgrade

[Erica_Rocks]

Hello,

My organization just upgraded from OnBase 15 to OnBase 18. In Workflow, we use Load Balancing quite a bit. As the workflow administrators, it is helpful when troubleshooting with a user to see exactly what documents they are seeing in a queue. So in the past with V15, we used the "See Other User's Documents" option quite often by right-clicking on a queue...you'd get the pop-up with <ALL>, <Unassigned>, and then all the users' names who have access to the queue.

After the upgrade, that pop-up box only populates with <ALL> and <Unassigned> (no user names) for my team, and we do have the Workflow Administrative Processing privilege set on our group. Now, if a member of the SuperAdministrator group logs in on my machine, they do get all the user names populated for that queue, and then when I log back in with my ID, I now see all those names (but only for that one queue that the SuperAdmin pulled up). I see this is happening in both Thick Client and Unity Client.

This doesn't appear to be a rights or privilege issue to me. Anyone else see this happen, or know how to fix it?

Thank you!

Erica

[Erica_Rocks]

Hello again...I am taking back my statement above about this not being a rights or privilege issue after playing around with my workflows. I think this is a configuration setting on the User Group. Does V18 handle rights/privileges differently than V15, when a user is in multiple groups and there are different rights/privilege settings for each group?

[Greg_Burck]

We're having the same issue but, for us, it appears to only be a problem within Unity Workflow (not classic) and we're currently 15.

[Erica_Rocks]

Hi Greg, my First Line of Support has my open case on this with a status of "pending development". It seems to be an issue with how the core-based clients query the database and retrieve the results when the queue is load balanced at the group level instead of individual user level. When we were on V15, we were not set as core-based so that is why we weren't seeing the error on that version--on V15 Classic Workflow, the results were returned correctly.