Skip to main content

In case anyone is not aware….

Planview has an OOB stored procedure called ip.psp_user_del_settings.  This stored procedure is called/ran when: In configure users, if you click on "remove" instead of "deactivate" then psp_user_delete will be called, which, in turn, calls psp_user_del_settings for the user to be removed. It will not be called if they merely "deactivate" the user, which is the recommended action when a user leaves the company.

Note: As this stored procedure is currently written it will delete all tile reports that were last updated by the person who may be getting deleted.  If this is a PV Admin who has published or updated a tile report then that means if they leave the company and either the Admin removing them chooses remove vs deactivate, or if your company uses web services and calls this stored procedure for any recurring clean-up, then you could lose a lot of tile reports. 

Planview is aware of the concern of this process as we have a currently active case with them. 

To help others not be shocked by the removal of tile reports, I thought I would share what I have learned. 

Suggestions:

  1. If a PV Admin, or someone responsible for updating tile reports, leaves your company do not choose the Remove option, and instead choose Deactivate
  2. If your company utilizes web services and calls this stored procedure you may want to pause that action. 

This is by no means meant to overly alarm others, or put negative blame/focus on Planview. This is just to inform others from the potential of losing tile reports. 

 

Thanks

Pam Sargent

Thanks pamela for the shared experience. We’ve been thinking recently about deleting long time gone users just for the sake of cleaning our users database, but it’s good to know the implications, and also good to remind of the official practice which is to only deactivate users, leaving they grants untouched or not.


Reply