What about the data in app_user table ?

[Ekaterina Bushkina]

What is the use of app_user table? Please, provide the link for the documentation (if exists).

I faced a problem with desync between app_user and cwd_user tables after user's surname was changed. 

[Dave Norton]

Hello!

The app_user table stores the username of a user when they first log into jira. That username is then used all through Jira's database.

For example, if I log in to Jira with the username dave, there will be an entry for dave in the app_user table - and if I create an issue, I'll see that issue created by dave in the database.

The tricky part is when my username changes. Let's say my username becomes 123456. Once Jira finds out my user has been renamed (either because it's a local user, or a directory was synchronised) the row in app_user will now reflect my new username. But the user_key column will still be dave.

This app_user table allows us to rename users without updating all the tables in Jira's database - we only need to use one.

If your user's username has been changed, you should see their old username under user_key, and then the new username under the lower_user_key column - that's expected. If that user creates a new issue, the value of user_key will be stored in the database for that issue; and Jira will link it to the user under lower_user_key :)

There's a couple things that could have gone wrong - can you tell us a bit more about what you're seeing in those tables, and what problems you're experiencing?

Cheers,
Dave

[Ekaterina Bushkina]

Dear Dave,

Thank you very much for the explanation.

Now I understand the connections between these two tables and see, that user primary key is user_key column. There was created a view for external issues monitoring and users were identified by username column in cwd_user, that's why we faced some problems. Now we changed the view and identify users by lower_user_key in cwd_users and user_key in app_user.

Now it's clear.

[Dave]

Hi Ekaterina,

The app_user table is a mapping table that holds a unique key for a user, it holds userkey (never changes) and lower_user_name (can change due to username changes). 

So if you change a user's username this will change their username in cwd_user table which will propagate through to app_user's lower_user_name column, this way the user retains their issue history i.e issues are bound to the user_key column of the app_user table.

This was introduced in Jira 6.0 - Jira-6-0-release-notes and additional reading renamable-users-in-jira-6-0

Our kb article regarding fixing common issues when you encounter some sort of desync or missing unique mapping for a user - jira-login-fails-with-user-exists-but-has-no-unique-key-mapping 

Hope this helps.

[Ekaterina Bushkina]

Thank you for good explanation and the links!

[Michael Kornatzki]

Thanks for the detailed explanation.

There is only one (or more) problem:

If i will create a new issue by my own plugin and get the assigneeId from an issue like 

issueInputParameters.setAssigneeId(parentIssue.getAssigneeId());

...
CreateValidationResult createValidationResult = issueService.validateSubTaskCreate(applicationUser,
parentIssueId, issueInputParameters);

...
IssueService.IssueResult createResult = issueService.create(applicationUser, createValidationResult);

Then jira told me that the assignee didn't exist.

I have to use parentIssue.getAssignee().getDirectoryUser().getName(); as issigneeID to add a new subissue.

This is really weird :(

Kind regards,
michael

[Petr Vaníček]

Hi,

try to use ".getReporterUser().getUsername()" instead of "

.getAssigneeId()"