Project and Portfolio Management Practitioners Forum
cancel

Import User Report Bugs...need workarounds

SOLVED
Go to solution
Highlighted
JHarris941
Super Contributor.

Import User Report Bugs...need workarounds

Hello All,

 

We are in the process of creating and updating users in PPM automagically from LDAP. We are using the Import Users report and we found two glaring issues with it. Any workaround ideas would be most appreciated:

 

1. When the report end dates a user, it updates all end dated users with the current end date. ex: John Smith was end dated Jan.1, 2010 and Jon Doe was end dated Aug.6 2013. The report updates John Smith's end date to Aug.6, 2013

 

2. When you update the "Default Password" field on the report, when the report runs, it updates All Users with the default password including existing active users.

 

Any advice on how to resolve these issues? I've heard of people pointing these issues out, but HP has yet to fix this.

 

Thanks,

Jajcen

11 REPLIES
randull
Acclaimed Contributor.
Solution

Re: Import User Report Bugs...need workarounds

Hi,

 

This is the workaround we use:


If the user are re-imported over and over again, then all fields, including password, will be overwritten.

However, you can customize Import Users report as follows:

Copy existing Report Type to "Custom Import Users". All further customizations will be done on this copy.


Add new command after "Encrypt Password" command. The condition for this command should be the same as for "Encrypt Password" command - "'[P.P_PASSWORD]' IS NOT NULL". The command itself should be
ksc_run_plsql_procedure adjust_passwords
p_group_id.INTEGER.IN=[TEMP_GROUP_ID]
ksc_end_plsql_parameters
Create stored procedure like this:
CREATE OR REPLACE
PROCEDURE adjust_passwords
(P_GROUP_ID IN NUMBER) IS
BEGIN
update knta_users_int set password = (select password from knta_users a where a.username = dest_username)
where exists (select 1 from knta_users a where a.username = dest_username);
END adjust_passwords;

 

Best regards,
Randall

-- Remember to give Kudos to answers! (click the KUDOS star)
"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
randull
Acclaimed Contributor.

Re: Import User Report Bugs...need workarounds

Related to the password there is an Enhancement request for it, you can find the information here,

 

http://support.openview.hp.com/selfsolve/document/FID/DOCUMENTUM_QCCR1L37750

 

Best regards,
Randall

-- Remember to give Kudos to answers! (click the KUDOS star)
"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
randull
Acclaimed Contributor.

Re: Import User Report Bugs...need workarounds

Here is the defect related to the end date issue,

 

http://support.openview.hp.com/selfsolve/document/LID/QCCR1L23976

 

Do you know if the import is only changing the end date for the disabled users?

 

 

Best regards,
Randall

-- Remember to give Kudos to answers! (click the KUDOS star)
"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
JHarris941
Super Contributor.

Re: Import User Report Bugs...need workarounds

Thank  Randall for your input!

 

Yes the end date is being updated for all the endated users. The reason this is an issue is due to resource planning being skewed.  My previous ex:

 

John Smith was end dated Jan.1, 2010 and Jon Doe was end dated Aug.6 2013. The report updates John Smith's end date to Aug.6, 2013 

 

So it looks like John had resource availability up to only a few days ago rather than 7 months.

 

We talked to HP and they told us not to expect this to be resolved anytime soon. It seems that only a handful of users are behind this request, and its been like this since 7.5. So its up to us to figure this out. 

 

Thanks Randall and I hope you have to some time to help us resolve this. Any ideas off of the top of your head?

 

Thanks,

Jajcen

Jim Esler
Acclaimed Contributor.

Re: Import User Report Bugs...need workarounds

I think this has always been the way the product worked. We first saw it in 6.0. The change recommended by Mercury (the vendor at that time) was the one recommended in a previous response for retaining the password. I would suggest using the same process to capture and restore the original end date in your version of the report.

JHarris941
Super Contributor.

Re: Import User Report Bugs...need workarounds

Thanks Jim,

 

I see your point. I think that would be the best solution. As an alternative, could I use this in a script rather than a procedure? There may be some push back about creating procedures on the database. 

 

Thanks,

Jajcen

randull
Acclaimed Contributor.

Re: Import User Report Bugs...need workarounds

Hi Jajcen,

 

I posted a workaround before on this thread, please review it and see if it can help you out.

 

Best regards,
Randall

-- Remember to give Kudos to answers! (click the KUDOS star)
"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
JHarris941
Super Contributor.

Re: Import User Report Bugs...need workarounds

Hello Randull,

 

Yes thank you for you help in this matter! I'm getting some push back about creating a custom stored procedure on the database, so i'm now attempting to create a script instead. Thanks again for you help.

 

Jajcen

randull
Acclaimed Contributor.

Re: Import User Report Bugs...need workarounds

Hi Jajcen,

 

No Problem! You are welcome!

 

Best regards,
Randall

-- Remember to give Kudos to answers! (click the KUDOS star)
"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
JHarris941
Super Contributor.

Re: Import User Report Bugs...need workarounds

Hello Randull,

 

We attempted to use the same workaround to store the end date for users. It doesnt seem to be working. Here is the SQL we are using to update it:

 

update knta_users_int kui
set kui.end_date = (select ku.end_date from knta_users ku
where ku.username = kui.username)
where exists (select 1 from knta_users ku where ku.username = kui.username and ku.end_date is not null);
exit;

 

We are putting this after "Save Password" procedure. Do we need to place this somwhere else in the report commands or are we missing something?

 

 

Thanks!,

Jajcen

Jim Esler
Acclaimed Contributor.

Re: Import User Report Bugs...need workarounds

If this workaround does not work you could try something else: If a user is already disabled, you don't want anything in the user's registration to be changed. This could possibly be accomplished by deleting or marking complete (process_phase=5, process_status=7) those entries in knta_users_int. Disclaimer: I have not tried this.