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

Jobs with deleted user

Pawan

I was searching for the answer but couldn't find it. What happens to the job/task which has owner/assigned to a user who has been deleted from TeamSite?
I am looking for some generic answer and not to any specific version of TS though, I am working on TS671 SP1, i tried to test this and found the jobs are still active and showing the job/task details. I guess this behaviour is due to the job specification file is already created and no other validation is being performed except job/task active state.

Find more posts tagged with

Comments

ISCBorisB

What happens to the job/task which has owner/assigned to a user who has been deleted from TeamSite?

Nothing happens to Jobs/Tasks, just like nothing happens to the Files this person owns. Why should it?

Providing you have sufficient privileges you can force orphaned User Task transition using CLT 'iwtaskselect' Command or with
'TeamSite::WFtask: Smiley Frustrated

electTransition' method from some Perl Script or you can perhaps terminate the Job. What's your issue?

Adam Stoller

Nothing happens to Jobs/Tasks, just like nothing happens to the Files this person owns. Why should it?

Providing you have sufficient privileges you can force orphaned User Task transition using CLT 'iwtaskselect' Command or with
'TeamSite::WFtask:electTransition' method from some Perl Script or you can perhaps terminate the Job. What's your issue?

You could also change the owner of the job or task through the details screen (if you have permissions to do so) or via CLTs like iwsettaskownerandarea.

Pawan

Nothing happens to Jobs/Tasks, just like nothing happens to the Files this person owns. Why should it?

Providing you have sufficient privileges you can force orphaned User Task transition using CLT 'iwtaskselect' Command or with
'TeamSite::WFtask:electTransition' method from some Perl Script or you can perhaps terminate the Job. What's your issue?

Sorry for the late reply.
I do not have any major problem as such with deleted users as of now. When a user is deleted the files are shown with the SID in the TS filesystem, same thing should be with the jobs/tasks with the user id.
I tried on our dev box, I deleted a user and ran the iwuser -d CLT for that user and ran an existing cgi task, it ran fine with a deleted user id. Is this the expected behaviour?

Pawan

You could also change the owner of the job or task through the details screen (if you have permissions to do so) or via CLTs like iwsettaskownerandarea.

This is certainly a good idea, but I am just curious, for a deleted user footprint doesn't break anything.
Has anybody encountered any issues with deleted user id?

Adam Stoller

This is certainly a good idea, but I am just curious, for a deleted user footprint doesn't break anything.
Has anybody encountered any issues with deleted user id?

Why would it break something?
If the workflow is already running, it's still running, it just means that there's nobody registered to be the owner of the task and that it requires some administrative action to correct it (along with what's been mentioned, iwidmap can also work here)
If a file is owned by someone who has been deleted from the system, then it becomes owned by the SID (as you indicated) - The next time someone modifies it, it will be owned by that person.
If a file is locked by someone who has been deleted, you'll probably need administrative action to remove the lock (if you don't remap the SID to another existing user)

What were you expecting would happen / break?

kaalraa

This is certainly a good idea, but I am just curious, for a deleted user footprint doesn't break anything.
Has anybody encountered any issues with deleted user id?

If it would break anything, then definitely Iwov Engg department should be on their toes. I am sure they had thought over those conditions much before it comes to your mind.

Pawan

...What were you expecting would happen / break?

When a file is modified, the SID is replaced by the modified user, however, if the branch/workarea owner is SID, then it remains as is unless we map the SID with any other user. We faced some permission issues in some workareas whose owner were SIDs, not sure it was the problem or something else.
The iwmetadata.cgi throws an error when a file is tagged which has the owner/modified by value as SID. We faced the error in the metadatatask in the workflow.

Pawan

If it would break anything, then definitely Iwov Engg department should be on their toes. I am sure they had thought over those conditions much before it comes to your mind.

Even if it breaks anything, it may not be iwov on toes and there are always list of known issues and bugs which shows there is a possibility that you can think something better before iwov does.

Adam Stoller

When a file is modified, the SID is replaced by the modified user, however, if the branch/workarea owner is SID, then it remains as is unless we map the SID with any other user. We faced some permission issues in some workareas whose owner were SIDs, not sure it was the problem or something else.
The iwmetadata.cgi throws an error when a file is tagged which has the owner/modified by value as SID. We faced the error in the metadatatask in the workflow.

If you know these issues - have you filed them with IWOV Support - or are you just sitting on them and grousing about the behavior without making the small amount of effort necessary to try to get them fixed in a future release?

All that being said, I still believe the workflow will function properly - unless (now that I think about it) the deleted user owns an automated task (externaltask, submittask, etc) that attempts to perform its operation as the task owner (as opposed to the TS server process owner)