Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Technician's Last Name Has Changed and Older Open Subtasks Still Need To Be Worked Under Her Old Name

Created: 11 Jan 2013 | 6 comments

Hello,

We have a technician who was recently married.  She now has a new last name.  The Active Directory Sync has automatically added her new AD account to ServiceDesk and we have set all her permissions accordingly.  She is now able to work with her new account name.  New tasks and subtasks are not a problem.

The problem we encountered is that she has about 150 different older subtasks for various tickets throughout the system in her old name that still need to be worked.  She is having to manually login under her old name to work these subtasks.  It would be too time consuming for her to open each incident and reassign any subtasks that belong to her from her old name to her new name.   Is there any other option to quickly get all subtasks in her old name reassigned to her new name in 1 shot?

Thanks for any help.  Version: SD 7.1 SP2

Comments 6 CommentsJump to latest comment

reecardo's picture

Quick question... what does the PM side of things look like for her. Are there 2 users for her in the DB (one with old name, one with new name) or just 1?

If there are 2 users for her, that would seem to explain things. Her UserIDs would be different across the task assignments (they'd use old user for old tasks, and new user for new). You COULD manually update the database to reflect her new user in this case.

WK01's picture

Hello,

There are 2 users for her in the DB (one with the old name and one with the new name).   Primary and subtasks before the change are linked to her old account.  Primary and subtasks after the change are linked to her new account. If it would not break or orphan the tasks under her old name, we would like to change it to reflect her new name.  This would make things so much better for her.  She has well over 150 subtasks for various incidents under her old name.

Would that be difficult or risky?  Is it just one field in one table or are there multiple places this would need to change?

reecardo's picture

I don't think it would be that risky, it would just be a matter of a few UPDATE statements.

You can always back up the database and do this in the off-hours to test for correctness.

Unfortunately I can't remember the tables you have to update... TaskAssignment's referenceID is a definite. Unsure what other SD tables may have to be upodated, though.

WK01's picture

I looked up the UserIDs for both her old and new name in the Users table. 

If I take her old UserID and use that value to filter the ReferenceID of the TaskAssignments table as well as filter the IsCompleted field of the Tasks table for tasks not complete, I see that the numbers match up with what she sees on the console for open tasks.   ((Joining Tasks and TaskAssignments allows me to narrow down only open tasks under her old name.  Without the join I get everysingle task assignment regardless of it being opened or closed.  I am only interested in fixing her open tasks.))

I am thinking if I update the ReferenceID field from her old UserID to her new UserID in the TasksAssignments table, that should allow the task to display for her new name.

My only concern now, however, is that even though she can see those old tasks under her new name .... permissions may still be a problem.

  1. Do you think permissions would an issue?
  2. Do you think there are any other tables I may need to update?

I may just manually update a few of her tasks and have her test it out.

reecardo's picture

Permissions shouldn't be an issue as long as the UserPermission entries for both UserIDs appear the same (same permissions)

The TaskAssignment table is really the only table I can thing of right now for all the incomplete tasks, as far as Workflow goes. Again, SD might be storing this reference in some of their other tables (ServiceDesk*)

WK01's picture

Thanks for the information.  We talked about it and decided not to risk breaking/orphaning these tasks.  We can't risk losing visibility to the customers request.