Absent Member.. 5keeve Absent Member..
Absent Member..
728 views

Bug in KNTA_USERS_INT import

I think I found a quite annoying bug in the KNTA_USERS_INT import mechanism. I'm using PPM 9.2.

 

The documentation clearly states about the password column

 

Specifies the password for the
user.
If left blank, the value is set to the
password of the user currently
running the report.

 

1. It's NOT the password of the "user currently running the report" but the password the user specified on the import form.

2. It's even set to the specified password when NOT left blank.

 

This renders modifying users (adding scurity groups for example) useless, as

 

1. all the users will lose their password

2. all the passwords will be the same

 

Tags (1)
0 Likes
1 Reply
Absent Member.. Jim Esler Absent Member..
Absent Member..

Re: Bug in KNTA_USERS_INT import

We ran into this several years ago and Mercury support gave us directions for a workaround. Basically, we made a copy of the standard report and added commands to capture the user's current password before the changes are applied and restoring it after the changes are complete. Maybe HP support can provide similar directions for the product today.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.