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; } } }

Task Non-owner Approving/Rejecting Review Task

Bjorn

I have a pretty standard workflow with a review task. Nothing earth shattering. The review task sends an email to the assigned reviewer, which includes a link to "Finish the Task". (approve/reject the task).

The problem is that if that reviewer forwards the mail it to another user (with access to TeamSite), that user can act on that task, even though they are not the owner/assignee and may not even have access to that file at all.

What determines whether or not a user can act on a task? Because I don't want anyone but the assignee or a master to be able to "override" it.

Also, the role that the user has does not have "allow modify others' tasks" set to true. Any tips?

Find more posts tagged with

Comments

nipper

I assume the task is readonly, you can change that.

That will error out if someone without write access to the task tries to act on it.

Now if a task is asssigned to Bjorn and Joe clicks on the URL, when TS opens, who is the recognized user ?

Bjorn

I assume the task is readonly, you can change that.

That will error out if someone without write access to the task tries to act on it.

Now if a task is asssigned to Bjorn and Joe clicks on the URL, when TS opens, who is the recognized user ?

Thanks Andy.

If I understood you correctly, by changing the value for the readonly property for the task, it should error out if someone without access tries to act on it. I changed that value and then reran the workflow and a user without access was still able to accept the review task.

It's like the URL Command "transitiontask" doesn't check if the user using it actually has access to mess with the task -- or -- I just don't understand the proper place to set that access. I was operating under the (pretty reasonable?) assumption that if a task is assigned to Jim Bob, for example, then Michelle shouldn't be able to jack around with it unless she were a master.

If a task is assigned to Bjorn and Joe clicks on the URL for the URL command (like http://SERVERNAME/iw-cc/transitiontask?taskid=1), it shouldn't matter because the authentication doesn't require anything in that link. When TS opens, the recognized user is whoever the logged-in user is. If an authorization cookie exists, maybe no login is required. If not, then the login screen for ContentCenter will pop and make somebody login before they can act.

But once they're logged in, it doesn't make sense to me that they can approve a review task that is not assigned to them.

nipper

OK, this is certainly sounds like a bug. You should call support.

One thing to try, can you have the non-owner of a task try to view that task in CC_Pro and click approve ?

nipper

BTW, is this the same issue as Restriction on User task ? They certainly sound the same.

ISCBorisB

if a task is assigned to Jim Bob [...] Michelle shouldn't be able to jack around with it unless she were a master

Just to make sure - have you tried it without using mails, CC URL Commands and all this nice Jazz? Is manifestation the same?
What happens when Michelle simply logs in and tries to "jack around" with Jim/Bob Task?

nipper

Also, the role that the user has does not have "allow modify others' tasks" set to true.

Your wording is confusing. The role of Michelle (say editor) does not have allow modify others' tasks set. It does not matter what Jim Bob's settings are.

Bjorn

Just to make sure - have you tried it without using mails, CC URL Commands and all this nice Jazz? Is manifestation the same?
What happens when Michelle simply logs in and tries to "jack around" with Jim/Bob Task?

There's no need to put quotes around the term jack around. It's industry standard nomenclature.

When done only through CC without any of "that jazz", nice or not, it all works as expected because the roles for these users are configured to not allow them to see other people's tasks, so they can't even get to the point where they could take action on anyone else's task. It is indeed only with the URL Commands apparently.

Bjorn

Your wording is confusing. The role of Michelle (say editor) does not have allow modify others' tasks set. It does not matter what Jim Bob's settings are.

This is going to sound confrontational even though I don't intend it to be so, but what's your point? Meaning - if there is anything else I can clarify, I would like to do so, but am not sure what specific clarifications would be the most helpful.

Adam Stoller

When done only through CC without any of "that jazz", nice or not, it all works as expected because the roles for these users are configured to not allow them to see other people's tasks, so they can't even get to the point where they could take action on anyone else's task. It is indeed only with the URL Commands apparently.

Is this a Windows or Unix implementation?
Can you verify who owns the URL command process?

My thinking is: (on Unix) if the URL process is somehow owned by root, and root is a defacto Master, then even though someone other-than-the-task-owner executed the URL process, it would be seen as being executed by root / Master, and allow it to go through.

The above is just a guess, but it would seem to fit the symptoms...

Bjorn

The above is just a guess, but it would seem to fit the symptoms...

Thanks for your response. This is on Windows. I hadn't thought of what you're saying, and that would make sense given what is occurring, and some things I've seen when working with the CSSDK and other workflows. But two things might lead me to think otherwise:

1 - If I look at the history of the tasks for the job, it does show the real user (not an IW or system-type user) as having acted on it.

2 - URL commands still require login. When a user enters a URL command into a browser or via clicking a link in an email, they still need to authenticate. The user customization guide indicates:
"Some URL Commands access functionality which is not accessible to all TeamSite users based on the role they are currently logged in. URL Commands respect the same role restrictions as described in the TeamSite Administration Guide for specific TeamSite functionality."

This seems obvious at first, but then the two sentences sort of seem to contradict each other.

Migrateduser

Have you contacted Support on this issue? It would be interesting to see if this is an anomoly or something they have seen before.

ISCBorisB

There's no need to put quotes around the term jack around. It's industry standard nomenclature.

When done only through CC without any of "that jazz", nice or not, it all works as expected because the roles for these users are configured to not allow them to see other people's tasks, so they can't even get to the point where they could take action on anyone else's task. It is indeed only with the URL Commands apparently.

There's no need to put quotes around the term that jazz. It's standard American metaphor.

Bjorn

There's no need to put quotes around the term that jazz. It's standard American metaphor.

Ha ha! Touché, my friend! Touché!

nipper

This is going to sound confrontational even though I don't intend it to be so, but what's your point? Meaning - if there is anything else I can clarify, I would like to do so, but am not sure what specific clarifications would be the most helpful.

Check the role of the person who clicked the URL and make certain that the ability to approve other persons task is not checked for that role. The way you worded it seemed to imply it was not set for the desired approver not the intercepting approver.

Bjorn

Check the role of the person who clicked the URL and make certain that the ability to approve other persons task is not checked for that role. The way you worded it seemed to imply it was not set for the desired approver not the intercepting approver.

Gotcha. But that's another thing. Which value would actually control whether or not someone could approve someone else's tasks? Is it just the value under "Permission Overrides" that says "Modify tasks and jobs that they do not own." This is unchecked.

Or is there another value under the Workflow section? When I looked at these values when I first noticed the issue at hand, I couldn't find a description of what each does. Some of them are named intuitively, others not. But there's nothing in the docs that directly lists these values and what each one means.

Add Task Comment
Read Job Properties
Assign
Read Task Properties
Attach To Task
Retry Task
Change Task Owner
Return Group Task
Configure Workflow Models
Take Back Task
Detach From Task
Take Group Task
End Job
View All Jobs
Manage Workflow Models
View All Tasks
Modify Job Properties
View Job Details
Modify Task Properties
View My Jobs
New Job
View My Tasks
Publish Workflow Models
Webview Workflow Models

nipper

Workflow section, More Detail,

Permissions Overrides

Allow users to:

Modify tasks and jobs that they do not own

Bjorn

Workflow section, More Detail,

Permissions Overrides

Allow users to:

Modify tasks and jobs that they do not own

Ok. I've confirmed that this is UNchecked.

nipper

Ok. I've confirmed that this is UNchecked.

OK, talk to support, this sounds like a bug.

Bjorn

Have you contacted Support on this issue? It would be interesting to see if this is an anomoly or something they have seen before.

Remember - contacting support and getting support are two different things.

Migrateduser

Remember - contacting support and getting support are two different things.

But if you don't contact support you will never get support. How profound is that?

Support is better than you think, in general. If you press them and escalate your issues, as appropriate, you will get decent help. It also helps if you know which support engineers are the good ones and make sure they take your case. But that only comes after years of pain...

Bjorn

But if you don't contact support you will never get support. How profound is that?

Support is better than you think, in general. If you press them and escalate your issues, as appropriate, you will get decent help. It also helps if you know which support engineers are the good ones and make sure they take your case. But that only comes after years of pain...

[rant]

Support isn't a free set of forums like devnet or other places where kissing a little rear and being a good, persistent soldier generally tends to work to your favor. Support is something we pay for. If you pay for your cheeseburger at McDonald's, you don't expect to wait 20 minutes to get it, nor do you expect to have to keep climbing over the counter and going in back and asking the guy frying it up why it's taking so long or why he won't put cheese on it even though you asked for cheese. Your payment was a contract, even if it is just a burger, and a small one at that.

Am I being, as Marv Levy said, an orificious jerk? Yeah. Probably. But I see the itemization of what my company drops on "maintenance" and I can't help but think that someone should be going out of their way to make my job easier -- not the other way around.

[/rant]

Sorry. I feel a bit better now.

Adam Stoller

[rant]

Support isn't a free set of forums like devnet or other places where kissing a little rear and being a good, persistent soldier generally tends to work to your favor. Support is something we pay for. If you pay for your cheeseburger at McDonald's, you don't expect to wait 20 minutes to get it, nor do you expect to have to keep climbing over the counter and going in back and asking the guy frying it up why it's taking so long or why he won't put cheese on it even though you asked for cheese. Your payment was a contract, even if it is just a burger, and a small one at that.

Am I being, as Marv Levy said, an orificious jerk? Yeah. Probably. But I see the itemization of what my company drops on "maintenance" and I can't help but think that someone should be going out of their way to make my job easier -- not the other way around.

[/rant]

Sorry. I feel a bit better now.

While I understand the rant, the content of the rant leads to the conclusion that if you pay for support, you should use it to try to find an answer to this issue. It doesn't hurt to post questions about it here too - but why close out one avenue of potential help, especially since it's already being paid for?

Bjorn

While I understand the rant, the content of the rant leads to the conclusion that if you pay for support, you should use it to try to find an answer to this issue. It doesn't hurt to post questions about it here too - but why close out one avenue of potential help, especially since it's already being paid for?

Exactly right. Which is why I do have a case open. I never said I didn't open one -- just that in my Bjorn-centric universe, I wish the expediency and means of handling this and other cases was more focused on the customer. Smiley Happy

Bjorn

FYI - Just talked to a support guy and he says it looks like a bug, but he is researching.