How to get worklistitems for a given process id

Hi,

Using K2MNG you have no reverence from the WorklistItem object to the ProcessInstanceID as you mentioned. Using K2ROM you can work your way back to the ProcessInstanceID however now you are limited to the Worklist you can open, if it is your own Worklist or a user that you manage you are fine. If you can explain your business scenario around this question I might be able to assist you with some workable solution.

I need to be able to tell if a given user has a active worklistitem (he is the destination of it right) for a given process instance.

input: user name, process id

output: true/false

I can also run this method (connet to K2 server) as AD administrator but as I can see I can't get the worklistitems for all users even as a administrator.

K2.net ignores the fact that a Domain Admin is a Domain Admin, do you need to get this result for the current logged on user or is it just some random user?

Since I run this thing on the K2Server machine it can se set as any user that could have the permission to see all work items for all users.

No such user exist that can be used with K2ROM, I understand that you want to do this test however share the business scenario around this so that I can get a better understanding of the Why

Here's the why - users's can go to sharepoint library asociated with a workflow instance and they'll be able to check out documents - we want to make sure that only the current user that has an open task for that workflow instance can actually do it.

You could query the K2 database directly...

... and void any and all support - Not recommended. I would suggest getting in contact with your local K2.net Services office for some consultation around your specific needs.

Regards,
Ockert

query the K2 database is defiantly a BIG NO-GO area

We already have their support but to this issues we could not find any solution.

This is not a support issue - it has got nothing to do with a defect/issue in the K2.net product. This is exactly why I suggested to contact your local K2.net Services office - this is consulting.

Best regards,
Ockert

I mean technical support and guidance in how to resolve and develop a solution - isn't after all this part of consulting practices?!
And the reason I came to this forum is that we can not find an elegant solution to our scenario. The only one suggested seems the some database access which I understand will not be supported by K2.

Secondly in terms of a workflow product I strongly believe this would one of a many simple functionalities to be able to tell what process instance a worktask belongs to!!!

Sure, point taken - we're always striving to enhance/improve our product. Thank you for the feedback.

I just thought a dedicated K2.net consultant could assist you better.

Regards,
Ockert

Ockert:

... and void any and all support - Not recommended. I would suggest getting in contact with your local K2.net Services office for some consultation around your specific needs.

Regards,
Ockert

Could you expand upon this, please? My understanding is the following:

1. The K2 database schema is subject to change without notice
2. The K2Log database schema is more static, as it is used for reporting
3. Querying K2Log is acceptable; querying K2 is not recommended (for performance reasons as well as changes)
4. Any custom development we do, be it .NET calls to the K2ROM or SQL queries against K2Log, is not supported - that's consulting, as you mentioned

Are you saying in addition that issuing a SELECT, even a SELECT WITH (NOLOCK), against K2 (or K2Log?) voids our support contract completely (not just with regard to that particular code)? If that's the case, it's something we need to know about.

I hope you realize that there are some reports that cannot be obtained through K2Mng, K2ROM, etc.

As you've mentioned, the K2Log db is there specifically for reporting needs and can be queried to your heart's content - No problem there. This is also the reason we make available the K2Log database schema. This should be able to cater for any and all reporting needs.

Queries against the K2 transaction database - even a SELECT WITH (NOLOCK) - are an entirely different matter.

Read this carefully...

If the query (on K2 db) was not approved for use by the development team prior to implementation, any/all support CAN be voided.

I use CAN in italics because obviously, we will do whatever we can to assist but we will not be held responsible for data loss/corruption etc.

Hope this answers the question.

Regards,
Ockert

Ockert:

Hope this answers the question.

Regards,
Ockert

Yes; thank you.

You wrote:

Here's the why - users's can go to sharepoint library asociated with a workflow instance and they'll be able to check out documents - we want to make sure that only the current user that has an open task for that workflow instance can actually do it.
If you want it so that the only forms available are those that a user should be working on...
(forgive me if I am misinterpretting)

You can create a view that filters on the logged in user.
Then set that as the default view.

This is a bit tricky and I have some great instructions on how to do it. If you are interested I can share