nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

User task permissions

msr

Hi,

Iam developing a deployment workflow.I am creating user task.Eventhough the owner of the user task is content approver, Workflow initiator also able to take the ownership of the user task.

Example:
A -> Workflow Initiator
B -> Approver.

Please find the attached user task text file

In the User task, both initiator and approver are able to take the ownership of the task.

But according to requirement, only approver has to take the ownership of the task.

Could you suggest any reference/pointer to fix the issue.

TS V6.5
Unix.

Thanks in advance
MSR.

Find more posts tagged with

Comments

curiousmaverick

taking ownership? I guess we are talking GroupTask here?

Adam Stoller

Hi,

Iam developing a deployment workflow.I am creating user task.Eventhough the owner of the user task is content approver, Workflow initiator also able to take the ownership of the user task.

Example:
A -> Workflow Initiator
B -> Approver.

Please find the attached user task text file

In the User task, both initiator and approver are able to take the ownership of the task.

But according to requirement, only approver has to take the ownership of the task.

Could you suggest any reference/pointer to fix the issue.

TS V6.5
Unix.

Thanks in advance
MSR.

A usertask is owned by a single user and, generally speaking, should only be able to be acted upon by that user (job owner and Master users often are exceptions to this rule)

A grouptask is set to be owned by a single member (at any one time) of a group of users (OS group, TS group, ad-hoc list of users, or combinations thereof). Depending on how configured, and whether or not the workflow process loops - subsequent re-activation of the grouptask may retain ownership of the task being associated with the original user who took ownership, or may open up ownership for any member of that group who wishes to take it.

What is unclear from your question is whether you are looking to have multiple people have ownership of this task, or looking not to have multiple people have ownership of this task. And there might be an additional question after that, but it isn't clear (to me).

msr

Thanks for your reply,

Looking for not to have multiple people have ownership of the user task. But my 'user task' is allowing to take the ownership for initiator and approver.

If I keep debug mode true ,then Iam able to see approver as the owner of the user task, but it is allowing to take the ownership for initiator and approver. What could be the reason for this?

If I want to keep only approver can take ownership of the user task, what I need to do?

Is there any criteria for job owner (WF Initiator) should have permission to take ownership of any user task in the workflow.

Thanks
MSR.

Migrateduser

Thanks for your reply,

Looking for not to have multiple people have ownership of the user task. But my 'user task' is allowing to take the ownership for initiator and approver.

If I keep debug mode true ,then Iam able to see approver as the owner of the user task, but it is allowing to take the ownership for initiator and approver. What could be the reason for this?

If I want to keep only approver can take ownership of the user task, what I need to do?

Is there any criteria for job owner (WF Initiator) should have permission to take ownership of any user task in the workflow.

Thanks
MSR.

Your semantics are creating confusion. There is only one owner of a usertask. What you are saying is that more than one person can act on the successor options for that usertask, and that other person would be the job owner.

You can hardcode the job owner to a generic user account that no one has access to in order to accomplish what you want to accomplish. This can have other, possibly undesirable effects, but it will solve your immediate problem.

CRB

Your semantics are creating confusion. There is only one owner of a usertask. What you are saying is that more than one person can act on the successor options for that usertask, and that other person would be the job owner.

You can hardcode the job owner to a generic user account that no one has access to in order to accomplish what you want to accomplish. This can have other, possibly undesirable effects, but it will solve your immediate problem.

i had similar situation, and as you suggested, the only way to get around it was to set root as the job owner by default... but it made all the jobs look the same and it was hard for the approver to know who invoked what. so I modified job properties to say something like "invoked by $IW_USER", that will show who invoked the job n root is still the owner.

i wonder if this is working as intended , if something is missing in the WFM design, or if we are missing something. content contributors are able to approve their own workflows because they own the job...

libs.zip

Migrateduser

i wonder if this is working as intended , if something is missing in the WFM design, or if we are missing something. content contributors are able to approve their own workflows because they own the job...

My own personal opinion is this is crappy design on the part of IW. If the job owner is intended to be an approver, it can easily be set up as such. It should not be implied.