cancel
Showing results for 
Search instead for 
Did you mean: 

Initiator is a test ID

former_member852447
Active Participant
0 Kudos

Hello experts,

My workflow requires that the initiator is a security test ID (the user uses this to login so sy-user I believe becomes the test ID) which is required for security reasons to limit approvals of the objects for which the workflow is designed. The workflow design also requires that a confirmation is sent back to the initiator. Since the initator is a test ID the workflow will not be able to find an actual user. I thought of creating a custom table where the test ID is linked to an actual user and then inserting code in a method attached to a standard task and change wf_initiator........please advise if this is the recommended way to do it and how or are there other ways?

Thank you.

regards

David Dittmer

Accepted Solutions (1)

Accepted Solutions (1)

former_member185167
Active Contributor
0 Kudos

Hi David,

You can't change WF Initiator - that is and remains the username used to start the workflow.

You could make a method to convert the test user id to the real username, and use that for sending emails.

I don't understand why you need this "security test ID". Is there one for every user?

If no, how can you know who the real user is?

If yes, then why not use the actual username?

regards

Rick Bakker

former_member852447
Active Participant
0 Kudos

Rick,

The test ID contains certain securities which are required to perform approvals and rejections of the project. Correct, each user would have a separate test ID. The user would login in with the test ID whcih would enable that user to perform certain permissions. My problem is to get the workflow to determine the real user behind the test ID. You say that you can use a method to determine the real user but how would you do this.....would it be in the workflow or outside the workflow. Could this be better be done in security and then the workflow could access a table to determine the real user ID?

Thank you.

Regards

David Dittmer

paul_bakker2
Active Contributor
0 Kudos

David,

Sorry, but it sounds to me like the whole design of this process needs a rethink!

Users should not be logging in as 'test users' (in Production?) to perform specific tasks. Apart from everything else, it usually makes them very upset .

The whole idea of an approval workflow is that you let the users do 'something' (eg create a purchase order) and then have their actions subjected to checks and approval.

Or have I misunderstood?

cheers

Paul

former_member852447
Active Participant
0 Kudos

Hello Rick,

The test ID is only for testing so that I can perform system testing on the workflow. I have to have multiple securities to create the object, change the object and then approve the object. In production the test ID will  NOT be used as the users will have their own securities. I thought that giving myself a test ID would solve the issue but it creates a problem with identifying an initiator but maybe that test I cannot perform.

Thank you

David

anjan_paul
Active Contributor
0 Kudos

Hi,

  Most of the time we determine the agent through Table in TASK agent determination rule. And the assigned the rule to workflow task

former_member852447
Active Participant
0 Kudos

Hello Anjan,

Please clarify. My issue is that I would need to change the initiator.....has this got anything to do with the agent?

Thank you.

regards

David Dittmer

former_member185167
Active Contributor
0 Kudos

Hello,

I'm still not sure I understand what you're doing but it's a relief to hear that this is not for Production.

In most sites the Test system is a copy of Production (which is very useful) so you can just use the userids that you would use in Production. You just have to maintain a messy spreadsheet of passwords and authorizations.

I would not go and create special methods just for testing.

But anyway - if you did want a method to translate user X to user Y then you would make that a method of a class or a BOR object. The workflow would call this; there is no actual programming within a workflow unless you could loops and conditions.

To reiterate: I don't see why you need to do what you're suggesting. Have basis copy the org structure from Production and use that instead. Sorry if I've misunderstood.

regards

Rick Bakker

Answers (0)