You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Not trying to tell anyone how to develop a database, not trying to be rude here, but inquiring minds need to know.
Jira uses an app_user table that uses usernames as the unique key to associate users to issues instead of using the ID of the user in CWD_User.
This doesn't make sense to me. I would think this would lead to records easily orphaned and such.
Why not link issues using the id field of the cwd_user table?
Can’t help but think it is this way just cause that’s how it was and the effort to change is significant, but the effort increases every version - and with the size of the marketplace that’s a big change management and comparability headache. Personally hoping that when (it has to be when, right?) it’s changed through the suite that it goes to UUIDs and not just ints to support multi-master DB which would be a nice step towards geographically dispersed nodes in data center.
I'm trying to gain access back to my Jira instance and I'm noticing that a lot of varchars are being used as unique id's. For example, groups have unique entries in cwd_group, but those ID's are not used when creating permission schemes, the names of the group.
This may be doing bad things because apparently (unknown to me until today) group names that come in from LDAP, if they happen to be the same name as an internal group, both end up with unique ID's in cwd_group, however, when subsequently used for permission schemes it has not idea if it is using the internal group name or the external group name.
So...makes me wonder if not having USE permission is rooted in this non-unique, unique key thing jira is doing.
Yeah, could be. Yes, UUID's would be awesome...
Thanks for engaging me :)
Add the following:
if you delete the user using UserManagement page, the user will be deleted only from the SWD_USER table, and the APP_USER table will remain unchanged.
Also, while trying to understand the principle.
The way the structure has been implemented in cwd_* tables and user mapping tables have actually led to significant flexibility for us (as with everything, there can be downsides...but).
Hello, I am trying looking at an a issue against which a user logged time but then left the org. I still the user's full name, email etc.. but the cwd_user table does not have any info about this user.
I was able to pull the worklog for this user, the same user_key is available in the app_user table but not the cwd_user table. How can I get full name other details of this user from the data base?
The users name (first/last/display) is only stored in the cwd_user table, and if the entry from cwd_user
This is the query to get the user if they exist - replace JIRAUSER12345 with the user key you have - if there's no first/last/etc returned, the user record has been purged.
SELECT a.user_key, a.lower_user_name, u.lower_email_address, u.lower_user_name,first_name,last_name,display_name FROM app_user AS a LEFT JOIN cwd_user AS u ON u.lower_user_name= a.lower_user_name WHERE a,user_key = 'JIRAUSER12345';
The best you might get is a hint at their first/last name based if your username was an email address/or similar object that uses a users name
Thank you Craig for your response and the query. I replaced the user key in the query and
got the following result. The record is not available in the cwd table.
Strangely, the UI of Jira is showing the full name of this user, any thoughts?