Question

I've just upgraded from FB 7.1.13 to 8.0.32 (for Windows).

In importing our legacy defect tracking system, I created a large number of "transiently-active" users to preserve the history of who initially reported the defect. Once we went "live," I noticed that these users showed up as e.g. "User 133" instead of "Brad Majors" for accounts of users lacking administrative privileges. I determined at that time this problem could be resolved by temporarily activating the account, providing the account with write permission for the group associated with the case projects, and then deactivating the user again. I eventually got the nerve to run the following SQL:

INSERT INTO acl (sSectionName, ixSection, ixPerson, iPermission)
SELECT 'Group', '1', person.ixPerson, '1'
FROM person
WHERE person.fDeleted=1;

I am aware of this question about user name visibility, which has helped me understand the reason for the problem.

After upgrading, however, I have encountered the same problem again. I can use the same procedure I used before of activating the user, granting group membership, and the deactivating the user, but it is slightly more troublesome now, as all our licences are now in use, and I don't understand the new permission model and the schema well enough to risk modifying the database directly.

This seems to me a (slight) flaw in the otherwise seamless upgrade process.

Can anyone suggest a shortcut I could take to remedy this?

Answer 1

Have you tried creating a new user group which just includes everyone, including disabled user accounts? That should allow everyone to see every name.

Answer 2

I think I have figured out how to fix this. I can do it by modifying the permissiongroupmember table directly, but... it is necessary to click OK on the User page for some user (not necessarily one of the ones which was added) before the new information is "committed" and becomes visible in a case view.

So what I've been doing (manually, as I try to figuere this out) is effectively:

1. Modify the database directly by adding an entry to permissiongroupmember for each user who shows up wrong (this requires knowing which group you want to add the person to, but in my case, there is only one choice)

   INSERT INTO permissiongroupmember (ixPermissionGroup,ixPerson) VALUES(1,133);

2. After adding all users, log on as administrator, go to the User page, click the edit icon for any user, and then click OK.

Presumably clicking OK on a user page kicks FogBugz somehow.