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

Turning off job owners ability to do things

Hazzie

I have noticed that a job owner can progress tasks that have been assigned to other people. Is there a way to make sure that only the task owner can progress his own task (master/admins of course need the ability to progress as well).

Hazzie

Find more posts tagged with

Comments

Adam Stoller

When you write the WFT - explicitly set the job owner/creator to someone who either will not, or cannot login to TeamSite (because of no known password - like a generic "iwmaster" account)

I believe this still works (it did back in the 4.x days - haven't tried in 5.5.2)

--fish
(Interwoven Senior Technical Consultant)

Hazzie

ok so as i read it, you change the owner of the job to some other value, there by blocking that users ability to do anything to the job. Ok i can see how that works however, does anyone else find it a little unsettling that a person can progress a task that does not belong to them? To me this seems like a huge audit problem, not the fact that it can be tracked (i am sure that iwgetwfobj would track it - not tried it though) but the fact that they can do it seems wrong. A task to me should only be able top be progressed by the task owner (masters/admins excepting). If the task owner cannot progress it for what ever reason (not in work that day etc) then thats when you reassign the task to someone else. Just a thought from someone who will have his audit dept down on him faster than it will take to read this email if i left it with that functionalty.

Hazzie

Adam Stoller

I don't entirely disagree with you, and as such I suggest you open a case with Interwoven Support to request a change in this behavior.

FYI - Workflow does not currently track changes to attribute values such as task/job ownership - it only tracks additions such as accumulated transition comments.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

One reason that you might want this ability is that a task may be waiting for someone who is unavailable (on holiday, out sick, traveling, terminated, etc.) Since these are "normal" occurrences in any business, you should not need to involve your IT staff to address jobs that have become "stuck" as a result.

As Fish correctly pointed out, the owner of a job does not have to be the same as the creator of a job. You could make the owner a manager or someone of authority. Of course you could always kill a job and restart it with new users, but that may also violate your established process.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

I think the argument is that in case of emergency (the task owner gets hit by a bus), there should be a TeamSite master out there who can push the task along. The owner of the job isn't, and arguably shouldn't, be that person who pushes things along. I think it's silly that you'd have to make the job owner some phantom person just to avoid that person being able to push tasks through. There should at least be a configuration switch, perhaps in iw.cfg, to turn off job owners from being able to push tasks owned by someone else.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Hazzie

I suppose i am guilty of not thinking in a more 'global' way instead of looking at my own individual workflow needs. However we have thought about the need for not getting IT staff invloved by providing a cusom menu option that provides a list of administration 'things' that a Job owner can do. These include such items as Remove Job (so it kicks off an audit.ipl rather than the remove job built in function which we will remove) and more importantly in this case, Task re-assignment for a specified Job just in case someone is unavailable.
In fact it was during this process of creating the task reassignment that we discovered this <i>problem/additional functionality</i>.
As to the Job owner and Job creator being different (a non logged in teamsite user or phantom user) that rather does cut down the ability to monitor whats going on ona job in the to-do list.

Hazzie

Migrateduser

How do you disable the Job Options->Remove Job function? Is it possible to add a custom menu option to the Job Options pulldown?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Bryan_K

Just as a side note, Tech note 2459 addresses this issue.

http://devnet.interwoven.com/site.fcgi/techlib/002459

Bryan

Migrateduser

Which is pretty much the answer that Brinko gave. Unfortunately, that's a silly workaround. There should be a better way.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

Well, if you were the owner of, let's say, a "project", and you determined or decided that some assigned task for that project was either not being done according to the way your wanted it, or not in a timely fashion - don't you think you'd want the ability to push it along without telling your boss that you can't manage your own project?

Along the above lines - having the workflow owner be able to manipulate the job makes perfect sense.

However, since workflows can be started by various different people, in various different roles of responsibility, it is possible for an "underling" to use these same abilities that normally should be reserved for someone with more authority. In this case - being able to deny the "owner" of the job this authority makes sense.

Since we know there is a work-around (call it a hack if you'd like, but it does deliver the functionality - or lack thereof - that is desired) - perhaps we can combine it with other "standard" practices.

For instance - rather than assigning the job owner to some non-entity - why not determine the workarea owner (who should be an Editor or above) and assign them the title of workflow owner? Thus in an Author submit workflow - the Author would not have the ability to circumvent some aspects of the process - but the area owner, who presumably is a person of some authority over the goings-on within that workarea - would have that ability.

Does this perhaps sound like a reasonable way of phrasing the feature request?

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Perhaps I was a little harsh in my last statement. Here's why I think it's silly to have to use a phantom user to prevent a job owner from being able to act on another user's task. Let's say you have a fairly complex workflow with different groups of people affecting the job at various stages. If I'm one of the down-the-road approvers and a task is assigned to me, I may very well want to know who owns the job - the real owner - the person who created the job in case I have questions or whatever. If this is set to a phantom, it's of no use to me.

I think, based on your examples, that it is resonable to ask for a config switch, maybe even in the workflow itself (a new <workflow> attribute perhaps?) that can be set or cleared depending on whether you want the owner to be able to act on tasks not owned by him/her. That would allow it to be set at the job level (a TAG_info input).

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Hazzie

Dave,
Its not a configuration option but if you go to
$iwhome/httpd/iw-bin/todolist.itml
and change
<option name="opt:@h Smiley Tongue

rojectID@" value="deleteproject">Remove Job</option>
to
<!-- <option name="opt:@h Smiley Tongue

rojectID@" value="deleteproject">Remove Job</option> -->
(HTML comment out)
That will remove it from the drop down list on a global basis.
as to the custom menu option, not sure as the procedure that the select box calls will not know what to do with that drop down value. You might be able to create another drop down box in another <tr> undeneath say Description and have it do something but i have not tried it and cannot say what it will do.

I am using TS 5.5.2 on a NT platform.

Hazzie

Adam Stoller

[Standard Caveat]
As always, please note that making changes like this is completely unsupported - if it does what you want, great - document the heck out of it - for when you next upgrade. If it doesn't work, or it breaks something else - Interwoven Support will not be able to help you.

--fish
(Interwoven Senior Technical Consultant)

Hazzie

Yeah, i realise that if we upgrade then that particular file will (probably) be overwritten and therefore we will need to make a lot of notes on what to do on an upgrade.
Cheers.

Hazzie

Migrateduser

I guess I'm feeling a little nostalgic. This little bug has come back to bite us in the ****. For who knows how long, our users have been "approving" changes for usertasks owned by someone else because they happened to be the owners of their jobs. I have re-read this thread from a very long time ago and am still steamed that nothing has been done to remedy this situation other than a crappy hack workaround.

Our users had us feeling like idiots as they showed us how they could easily approve changes to go to production without any problem whatsoever. And the best part is that when they did it, it showed in the Job Details log that it was the person who owned the usertask that approved it! Talk about a foolproof way to CYA!!

One question, when a user selects View->My Jobs, is he getting back all the jobs where he is listed as the owner or those where he is listed as the creator?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

JonathonG

All jobs where he is listed as owner.

Jonathon
Independent Interwoven Contractor

Migrateduser

So Tech Note 2459, which provides the hack workaround will also take away the View->My Jobs ability from all my users if I were to change the owner of all our jobs to some phantom user. That's unacceptable. This is a huge security hole in the workflow process. No one other than the people I specifically set up as approvers should be able to approve work. If I'm stupid enough to set up my workflows in such a way that they get stuck if anyone is on vacation or sick, that's my problem. I have master users set up who can take care of things in case of emergency. Allowing the job owner to act on someone else's task is wrong, wrong, wrong.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

JonathonG

I would disagree. There is a need for someone to be able to handle situations where the workflow gets hung up waiting for a person who is not around. In large organizations, it may not be acceptable to give out master access to all those who need the ability to resolve these situations. At my current client, we have all workflows owned by the local IT group (who are only admins in TS, the central IT owner of TS are the masters). That way, if their users end up getting a workflow "stuck", they can call their local IT.

Now, I would agree that the workflow logs should report the *actual* user who transitioned a task. The fact that it reports it as the user who owned the task is, IMHO, a bug.

What are you trying to accomplish by making the end users owners of the job? Do you just want them to be able to view the current state of the job? (If this is discussed earlier in the thread, I'm sorry for re-hashing, I didn't go back and read all the context). There may be alternative solutions depending on why you want the end user as owner.

Jonathon
Independent Interwoven Contractor

Migrateduser

They use View->My Jobs. And I disagree that anyone other than the person or people specifically owning a particular task should be allowed to act on that task. That defeats the whole purpose of the concept of a task owner! If I want to allow for anyone else to act on an approval, I can set up a grouptask concurrently with the other usertasks to allow for other people to approve. But if only the people I deem to be approvers can approve, I should be able to count on that without worrying about who I set up as the owner of the job. It just makes no sense to have a security hole like this. There is enough available to me to prevent the scenario you mentioned without using the owner of the job as the super user of the whole job. That's the wrong implementation.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

Smitty, I have been trying to reproduce this in our environment and have not been able to. I think I may have another idea for you.

I have a test account, andy, author & few perms.

Our approvals are all group approver, assigned 95 % of the time to a specific reviewer but also has a group that can override the approval.

My test user cannot take ownership of the group task, even though andy is the owner of the job.

Check it out in your environment, see if that might be a good work around.

Makes sense why you have had such a high approval rate.

Kind of like when I accidently left the timeout to 5 minutes (used during testing).

HTH

Andy

Migrateduser

grouptasks may work but I don't want to use a grouptask. Have you tried this with a usertask? It's a security hole and should be fixed. The argument that it's a nice feature for the unlikely even that someone leaves the company in the middle of a job and the job gets stuck is BS. There's got to be a Master user around somewhere to resolve that issue.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

JonathonG

But why do they use View->My Jobs?

We could continue to argue about whether or not this job owner privilege is a feature or a design flaw, but, at the moment, the job owner does have those privileges.

There may be other ways of accomplishing what the users need to do. I can think of the following reasons that a user would want to view the jobs they own:
1) To check the status of the job
2) To transition tasks that are "hung"
3) To remove workflows that they've changed their mind about.


Here's what I would propose as a workaround for each of these instead of making them the job owner:
1) 2 alternatives:
     a) Create a task that is always assigned to them.  Then, from their To-Do list, they will be able at
        any point to view the job history and see the status.
     b) Create a custom menu item that lists all of that user's jobs. (quite a bit of work, would only use 
        this approach if the users hated approach a)
2) You don't really want this, so I won't provide a workaround.  If you did want this, the job owner
   thing is your best bet.
3) See the alternatives under 1, with the following additions:
     a) Add a transition to the endtask to the task that is always assigned to the user.
     b) Add a button for removing the job to your custom menu item.  This would end up calling iwrmjob.

Does any of this help?

Jonathon
Independent Interwoven Contractor

Migrateduser

But why do they use View->My Jobs?

Because they want to see their active jobs and what state they're in. Isn't that what the thing is there for? Viewing All Jobs is not useful because there are so many jobs active at any given time.

There may be other ways of accomplishing what the users need to do. I can think of the following reasons that a user would want to view the jobs they own:
1) To check the status of the job
2) To transition tasks that are "hung"
3) To remove workflows that they've changed their mind about.

Here's what I would propose as a workaround for each of these instead of making them the job owner:
1) 2 alternatives:
a) Create a task that is always assigned to them. Then, from their To-Do list, they will be able at any point to view the job history and see the status.

You're kidding, right? The View->My Jobs function performs exactly the function they need it to perform. Why should I go out of my way for a workaround I shouldn't need?

b) Create a custom menu item that lists all of that user's jobs. (quite a bit of work, would only use this approach if the users hated approach a)

This is not a viable option. Like I said, View->All Jobs does exactly what it should do.

2) You don't really want this, so I won't provide a workaround. If you did want this, the job owner thing is your best bet.

3) See the alternatives under 1, with the following additions:
a) Add a transition to the endtask to the task that is always assigned to the user.
b) Add a button for removing the job to your custom menu item. This would end up calling iwrmjob.

This isn't really a problem. The issue is only really that they use View->My Jobs and the fact that the expected usage of assigning an owner to a task is broken by allowing the job owner to override that assignment. I've filed a bug with support.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

>grouptasks may work but I don't want to use a grouptask. Have you tried this with a usertask?
>It's a security hole and should be fixed.

You mis-understand, file a bug, I will put my company on it as well. It is a hole and should be fixed.

But since the odds of getting something out of IW engineering other than a bug/RFE ID, are slim and none, you do have a possible workaround with the grouptask. I understand that is not what you want, but it is better than the owners approving their own changes.

Andy