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

Restriction on User task

rajivgupta

Hi All,

I am facing an issue while trying to restrict access on User Task using WFM.

Scenario is like :

1) Content Author submits a file using a particular workflow (User A).
2) Workflow send a notification to reviewer group .
3) One of the user from the reviewer group take control of the task (Group task)(User B and C is part of this group) .
4) Rejects the content .
5) Task come Back to author which is a User Task .

In this user task any other user(say User D) which is not related to this workflow is able to execute this task (ex . Rework task contains a button to say that rework is done and it goes back again to the reviewer group with mail notification )

Am I missing anything ?

I have attached the screenshot of the property window from the modeler .

Modeler Version : 1.0.1.1
Build : 69983a

Find more posts tagged with

Comments

Adam Stoller

Are you sure that userD is neither the job owner or job initiator (either or both of these values can be hard-coded or derived automatically when the workflow is instantiated)?

I ask, because historically the job owner (or initiator - I forget which) has the ability to usurp user-restrictions on tasks to move things along.

Also - are you sure that userD is not a Master user - as Masters tend to have the ability to usurp user-restrictions also.

If you are sure that neither of the above situations apply, and yet the behavior you are describing is repeatable - I would suggest opening a case with Support.

rajivgupta

Thanks for the reply Ghoti .

User D is neither the job owner nor the initiator .
User D is not the master user and I am able to replicate scenario everytime.

Are you sure that userD is neither the job owner or job initiator (either or both of these values can be hard-coded or derived automatically when the workflow is instantiated)?

I ask, because historically the job owner (or initiator - I forget which) has the ability to usurp user-restrictions on tasks to move things along.

Also - are you sure that userD is not a Master user - as Masters tend to have the ability to usurp user-restrictions also.

If you are sure that neither of the above situations apply, and yet the behavior you are describing is repeatable - I would suggest opening a case with Support.

Firenze

What role does User D have?
What are the role entitlements for Workflow set as?

Migrateduser

What role does User D have?
What are the role entitlements for Workflow set as?

That should be irrelevant unless the user is a Master.

nipper

That should be irrelevant unless the user is a Master.

Except Bjorn is posting the same issue, passing the URL to the review task and anyone can approve. I do not know if this is the same issue or a different one. They certainly *sound* the same.

Migrateduser

Except Bjorn is posting the same issue, passing the URL to the review task and anyone can approve. I do not know if this is the same issue or a different one. They certainly *sound* the same.

Yes it does sound eerily similar, but I am not convinced that both these scenarios aren't just something silly either. I sort of doubt something like this has slipped through the cracks. Even for Interwoven that would be unusual...this is basic workflow behavior. But I have been wrong before. Once or twice.

Firenze

Why is the Role question irrelevant?

There is a setting for each role:
Permission Overrides
Allow users to:
Modify tasks and jobs that they do not own.
View and modify files in workareas where they are not a member of the group for sharing.

If an Author role has "Allow users to:Modify tasks and jobs that they do not own" On and "View All Jobs" entitlement then, they will be able to do what "rajivgupta"

Migrateduser

Why is the Role question irrelevant?

There is a setting for each role:
Permission Overrides
Allow users to:
Modify tasks and jobs that they do not own.
View and modify files in workareas where they are not a member of the group for sharing.

If an Author role has "Allow users to:Modify tasks and jobs that they do not own" On and "View All Jobs" entitlement then, they will be able to do what "rajivgupta"

Point taken. I will go eat my crow now....

Bjorn

Except Bjorn is posting the same issue, passing the URL to the review task and anyone can approve. I do not know if this is the same issue or a different one. They certainly *sound* the same.

Yes indeedy. They sure do sound the same. Hopefully I'll hear from support sooner than later and we'll see where this bad boy goes.

Bjorn

Yes it does sound eerily similar, but I am not convinced that both these scenarios aren't just something silly either. I sort of doubt something like this has slipped through the cracks. Even for Interwoven that would be unusual...this is basic workflow behavior. But I have been wrong before. Once or twice.

I'm definitely not above silliness, but I've been looking at this A LOT. Enough to be relatively sure that it would have to be some pretty silly silliness to just chalk it up to my own abundant supply of ignorance at this point.

Bjorn

Why is the Role question irrelevant?

There is a setting for each role:
Permission Overrides
Allow users to:
Modify tasks and jobs that they do not own.
View and modify files in workareas where they are not a member of the group for sharing.

If an Author role has "Allow users to:Modify tasks and jobs that they do not own" On and "View All Jobs" entitlement then, they will be able to do what "rajivgupta"

I know I'm kinda crossing two threads here (http://devnet.interwoven.com/forums_vb/showthread.php?t=31253&forumid=16), but how about this: based on me seeing the same "issue", I'm proposing that even if the role has both "Modify tasks and jobs..." and "View All Jobs" unchecked it won't make a lick of difference.

As far as I can tell, in short, ANY user will be able to doink around with a task that is assigned to someone else and in a workflow they did not start.

Migrateduser

So have you opened a support case about this?

If so, are they looking at it? Have they responded?

If not, why not?

Bjorn

So have you opened a support case about this?

If so, are they looking at it? Have they responded?

If not, why not?

Yes.

Doubtful. No.

Unsure. See other thread for my feelings on this.

Migrateduser

However you may feel about IW Support, if this is a production issue, they should be giving it some attention and I would assume your company has a service agreement that they will respond in a certain amount of time for production issues. We have received pretty decent feedback from support when we push them hard enough. I open about 1 or 2 new cases per week and although they don't always respond within a day like they are supposed to, when they do respond they seem to stay involved.

You don't seem to be getting anywhere here, so pressing support (with your management's help perhaps) should light a fire under them. Do you work directly for the company you're working with or are you a contractor/consultant?

Bjorn

You don't seem to be getting anywhere here, so pressing support (with your management's help perhaps) should light a fire under them. Do you work directly for the company you're working with or are you a contractor/consultant?

I can't figure out if you're trying to help or being pesky or both.

Anyways, I just talked with support, did a livemeeting and showed him the issue and the guy said it looks like a bug, but he has to research it further. I wish I could take a video of it to display here because it would make a lot more sense than me explaining it, but there's the whole privacy and NDA thing.

Migrateduser

I can't figure out if you're trying to help or being pesky or both.

Both actually. I get the value of DevNet - it has helped me immensely over the years. And I also get that IW can offer weak support at times. But I don't get the dependency on one over the other based on principle. If you have a problem that no one here can solve, I wouldn't need a shove from people I don't know to press for IW support, and hard. I owe that to the company that I work for to use all the resources available. It just seemed like you were giving up on IW Support based on your pribciples and not even pressing them to help you. Maybe that's just the perception I got from the little you shared in this forum, and perhaps you were writing emails and updating your case every day begging for help, unbeknownst to all of us here. I don't really care either way. I'm just a big fan of using all the resources available to me. The company you work for is paying a buttload of money to IW. That gives you leverage. Use it or if you choose not to, don't complain about it.

Bjorn

Use it or if you choose not to, don't complain about it.

Fair enough. But I am in group C: use it and complain about it. As you've said, my company pays a fair amount for support. If you pay for something you expect a certain amount of service, which should come as a result of that payment, not as a result of you making that payment...and then also taking on the role of the case enforcer.

Nobody likes a Donny Downer, but my complaints were and will probably continue to be more of a passive aggressive salve than a life choice to absolutely refuse to work with IW support.

Migrateduser

I'm not complaining about you complaining. I would be quite the hypocrite if I whined about someone complaining. Complaining is what I do best. What bothered me is that you appeared to not use IW Support - or not push them harder at least. I will happily complain about IW but I will also beat on them incessantly to get them to help.

I'm glad you got them to look at your problem. I would be very interested to find out if they indeed declare this as a bug. And that's what it's really all about: how can your problem help me? Smiley Surprised

)