-
Suggestion
-
Resolution: Fixed
-
297
-
We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
Hi everyone,
Thanks so much for your votes and comments on this issue.
JIRA 6.0 has been released with the ability to edit usernames and we all hope you take it for a spin! JIRA 6.0 contains lots of other goodness and you can read the full release notes here.
Cheers,
Roy
JIRA Product Management
roy at atlassian dot com
- Edit_Profile_615.png
- 61 kB
- edit_username.png
- 145 kB
- renameuser.sql
- 2 kB
- screenshot-1.jpg
- 21 kB
- Search_list.csv
- 1 kB
- causes
-
JSWSERVER-7269 Update GreenHopper to correctly work with JIRA 6.0 rename feature
- Closed
- is duplicated by
-
JRASERVER-3824 need ability to rename existing user
- Closed
-
JRASERVER-4588 Rename users
- Closed
-
JRASERVER-10797 Global user rename - 1:N users
- Closed
- is incorporated by
-
JRASERVER-8970 Consider adding a SOAP service to get all users
- Closed
-
JRASERVER-13297 SOAP Service Improvements - Especially with user management
- Closed
- is related to
-
JRASERVER-19958 Renaming a version breaks all related filters
-
- Closed
-
-
JRASERVER-10932 publically available usernames are a security risk
-
- Closed
-
-
JRASERVER-11926 New user with same username as deleted user gets falsely attributed with comments and work logs
-
- Closed
-
-
JRASERVER-17668 Having comma in username creates problem when user is added to a watch/group list
-
- Closed
-
-
JRASERVER-11125 JIRA 4.0 Enterprise Requirements
- Closed
-
JRASERVER-32199 Ability to detect a changed username in LDAP
- Closed
-
JRASERVER-32200 Ability to detect a changed username in Crowd or "JIRA User Server"
- Closed
-
JRASERVER-72769 Provide the ability to rename groups after creation
- Gathering Interest
-
JRASERVER-1391 Provide the ability to rename groups after creation
- Under Consideration
-
JRASERVER-3132 Provide ability to transfer reported/assigned issues to another user when deleting users
- Not Being Considered
- relates to
-
JRASERVER-35102 Mentions don't support username change
-
- Closed
-
-
CONFSERVER-2191 Group management improvements
- Closed
-
CONFSERVER-4063 Change usernames
- Closed
-
JRACLOUD-1549 Ability to rename a user
- Closed
-
JRASERVER-1962 Improve the LDAP stack in JIRA
- Closed
- was cloned as
-
JRASERVER-65987 Ability to rename a user
- Closed
- mentioned in
-
Page Loading...
-
Wiki Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Wiki Page Loading...
-
Wiki Page Loading...
-
Wiki Page Loading...
-
Wiki Page Loading...
-
Wiki Page Loading...
-
Wiki Page Loading...
-
Wiki Page Loading...
[JRASERVER-1549] Ability to rename a user
facepalm - this issue can't be open since 2003. Even Microsoft can handle username changes meanwhile.
As usual basic functionality has to be implemented by customers. For PostgreSQL here is a procedure that does the account renaming:
https://gist.github.com/2352960 (patches and beers are welcome).
Hi Atlassian,
Could you please confirm this feature is include in JIRA 5.1 ?
Regards,
Sven.
Thanks Chad, I will definitely check it out. Looks like I might be able to use some of the workflow enhancements as well.
If you install the script runner plugin for JIRA, it provides an inbuilt script to rename users. I've been using it for about a year, and it works really well.
To Atlassian
The fact that one of your customers was so fed up with your poor workmanship that they built a kludge and shared it with all of us does not free you from the obligation of actually fixing your software.
FWIW, I recently undertook a username renaming exercise, choosing the route of backing up to XML, editing the XML, then restoring from the edited XML.
To do the renaming I created a perl script that used regexps on all known expressions where usernames were found to be used as keys. This was to avoid the problem of collateral renaming damage. The list of keywords was derived empirically by analyzing everywhere that a username was found. WARNING: The list is probably not exhaustive, and seems to be based on the extent of activities and workflows you have in your JIRA.
# name="fred" # userName="fred" # username="fred" # lowerUserName="fred" # assignee="fred" # author="fred" # caller="fred" # childName="fred" # lowerChildName="fred" # entityId="fred" # lead="fred" # newvalue="fred" # oldvalue="fred" # reporter="fred" # roletypeparameter="fred" # updateauthor="fred" # # <meta name="jira.update.author.name">fred</meta>
A big caveat you should be aware of concerns the <ExternalEntity> entries. Unknowingly, I had external entity entries with the same name as usernames I was renaming to. This resulted in duplicate (non-unique) external entity names after the perl script had run. Eg:
<ExternalEntity id="10" name="fred" type="com.atlassian.jira.user.OfbizExternalEntityStore"/> [...] <ExternalEntity id="515" name="fred" type="com.atlassian.jira.user.OfbizExternalEntityStore"/>
This caused JIRA to crash. You must ensure that your renaming does not result in duplicate names in the ExternalEntity and User entry lists.
Apart from that, the script worked fine for my installation, but there are no guarantees. USE AT YOUR OWN RISK. Keep a copy of your original unedited backup/export XML and if things go pear-shaped just restore from that.
#!/usr/bin/perl -i~ # # Edits file in-place changing all known JIRA keys that contain # usernames from oldvalue to newvalue. Run it against an XML backup file "entities.xml". # Original file is preserved as "entities.xml~". # # Example: % jira-rename-user.pl fred:fblogs nick:ngianniot entities.xml # # BE CAREFUL: DO NOT CREATE ANY DUPLICATES IN THE <ExternalEntity> section!!!!! use warnings; $USAGE = "usage: $0 from-username:to-username [...] file\n"; while (@ARGV > 1) { $from_to = shift; (($from, $to) = split(/:/, $from_to)) == 2 or die "bad from:to arg [$from_to]\n"; push(@pairs, [$from, lc($to)]); } @pairs > 0 or die $USAGE; foreach $pair (@pairs) { my ($from, $to) = @{$pair}; print "from=[$from] to=[$to]\n"; } print "file=[@ARGV]\n"; @keys = qw( name userName username lowerUserName assignee author caller childName lowerChildName entityId lead newvalue oldvalue reporter roletypeparameter updateauthor ); while (<>) { foreach $pair (@pairs) { my ($from, $to) = @{$pair}; foreach $k (@keys) { s|\b$k="$from"|$k="$to"|g; } s|<meta name="jira.update.author.name">$from</meta>|<meta name="jira.update.author.name">$to</meta>|g; } print; }
We have utilized the SQL scripts across multiple clients several times. You need to be proficient in SQL and have experience working with JIRA. However, if you have at minimum an adequate database person and a solid development environment then there is nothing to fear with this.
I think that it is important to remember: If you have any custom fields or other customisations, then the plugins, scripts and SQL snippets are not going to fix all your problems and you are very likely to sit with a system that needs to be restored from backup. This is not a task that presently can be attempted with a "hope it works" attitude.
Where could we find a list of tables in MSSQL that need updating in order to rename/merge user accounts in Jira 4.4.3?
Don't worry, Atlassian, you don't have to come up with a kludge to fix this because someone else already did!
Everyone, check out the script runner plugin. It has inbuilt scripts, and one of my favorite is "Rename user", which also lets you merge users!
(I love this ecosystem that sprang up around fixing Atlassian's inadequacies. It's like a construction project that frequently leaves holes where windows should be and occasionally just throws up a fireman's pole in lieu of stairs. But you can build steps yourself! So who cares?)
+1 on the above comment. We recently tried to merge users, and it was not a pretty sight. Atlassian, the hole is getting deeper....
Merge users capability
In addition to ability to rename a user we need to be able to merge accounts. This is quite a similar requirement but a little different as two entities get combined. It has become more important with ldap support as new user accounts are created automatically so won't be intercepted in the old process.
When a user name changes in the external directory (typically by marriage) we need to be able to replace the user id in assignee, reporter, watcher, rights, ownerships, filters etc with the new user id. Our user will have probably logged in with the new account and may have even done some work - you never know - so we will need to merge rather simply renaming.
here is the script I used for MSSQL db. One thing to note is to make sure that the new name does not already exist in jiraschema.external_entities. We use LDAP and it had already pulled in the new user name and cause errors since the rename causes an duplicate record. Also jiraschema.userhistoryitem caused some issue, not sure how it got resolved... i messed with it a bit and not sure how that got renamed
update jiraschema.changegroup set AUTHOR='newusername' where CAST(AUTHOR AS nvarchar(max))='oldusername' update jiraschema.changeitem set OLDVALUE='newusername' where CAST(OLDVALUE AS nvarchar(max))='oldusername' update jiraschema.changeitem set NEWVALUE='newusername' where CAST(NEWVALUE AS nvarchar(max))='oldusername' update jiraschema.columnlayout set username='newusername' where CAST(username AS nvarchar(max))='oldusername' update jiraschema.component set LEAD='newusername' where CAST(LEAD AS nvarchar(max))='oldusername' update jiraschema.external_entities set NAME='newusername' where CAST(NAME AS nvarchar(max))='oldusername' update jiraschema.favouriteassociations set USERNAME='newusername' where CAST(USERNAME AS nvarchar(max))='oldusername' update jiraschema.fileattachment set author='newusername' where CAST(author AS nvarchar(max))='oldusername' update jiraschema.filtersubscription set username='newusername' where CAST(username AS nvarchar(max))='oldusername' update jiraschema.jiraaction set AUTHOR='newusername' where CAST(AUTHOR AS nvarchar(max))='oldusername' update jiraschema.jiraaction set UPDATEAUTHOR='newusername' where CAST(UPDATEAUTHOR AS nvarchar(max))='oldusername' update jiraschema.jiraissue set reporter='newusername' where CAST(reporter AS nvarchar(max))='oldusername' update jiraschema.jiraissue set assignee='newusername' where CAST(assignee AS nvarchar(max))='oldusername' update jiraschema.jiraworkflows set creatorname='newusername' where CAST(creatorname AS nvarchar(max))='oldusername' update jiraschema.membershipbase set USER_NAME='newusername' where CAST(USER_NAME AS nvarchar(max))='oldusername' update jiraschema.OS_CURRENTSTEP set owner='newusername' where CAST(owner AS nvarchar(max))='oldusername' update jiraschema.OS_CURRENTSTEP set caller='newusername' where CAST(caller AS nvarchar(max))='oldusername' update jiraschema.OS_HISTORYSTEP set owner='newusername' where CAST(owner AS nvarchar(max))='oldusername' update jiraschema.OS_HISTORYSTEP set caller='newusername' where CAST(caller AS nvarchar(max))='oldusername' update jiraschema.portalpage set username='newusername' where CAST(username AS nvarchar(max))='oldusername' update jiraschema.project set lead='newusername' where CAST(lead AS nvarchar(max))='oldusername' update jiraschema.projectroleactor set roletypeparameter='newusername' where CAST(roletypeparameter AS nvarchar(max))='oldusername' and roletype='atlassian-user-role-actor'; update jiraschema.schemepermissions set perm_parameter='newusername' where CAST(perm_parameter AS nvarchar(max))='oldusername' and perm_type='user'; update jiraschema.searchrequest set authorname='newusername' where CAST(authorname AS nvarchar(max))='oldusername' update jiraschema.searchrequest set username='newusername' where CAST(username AS nvarchar(max))='oldusername' update jiraschema.trustedapp set CREATED_BY='newusername' where CAST(CREATED_BY AS nvarchar(max))='oldusername' update jiraschema.trustedapp set UPDATED_BY='newusername' where CAST(UPDATED_BY AS nvarchar(max))='oldusername' update jiraschema.userassociation set SOURCE_NAME='newusername' where CAST(SOURCE_NAME AS nvarchar(max))='oldusername' update jiraschema.userbase set username='newusername' where CAST(username AS nvarchar(max))='oldusername' update jiraschema.worklog set author='newusername' where CAST(author AS nvarchar(max))='oldusername' update jiraschema.worklog set updateauthor='newusername' where CAST(updateauthor AS nvarchar(max))='oldusername' update jiraschema.customfieldvalue set stringvalue='newusername' where CAST(stringvalue AS nvarchar(max))='oldusername' update jiraschema.userhistoryitem set username='newusername' where CAST(username AS nvarchar(max))='oldusername'
cwd_user was introduced by embedded crowd for user management in Jira 4.3, and isn't in previous installations. AFAIK the problem still exists, cwd_user is just yet another table that has to be updated when you rename a user. I suspect the introduction of crowd into Jira is the first step in properly fixing this problem.
cwd_user is a Crowd table? It's not in my schema.
I'd suggest the "center" of the entire problem is the decision a long time ago to use the username column of the userbase table as a foreign key everywhere that a link to the 'user' is required, combined with the fact that people want to change their usernames.
In none of the work-around scripts presented do I see see mention of cwd_user which, to my knowledge, is at the center of this entire problem. Am I missing something?
So - more than a year has passed since the last statement from Atlassian (Edwin Wong on 14/Mar/10). I just raised the question on the plans to fix this in the related issue for Confluence (CONF-4063) and we got a really annoying message from Atlassian, basically saying that they will not fix this issue in the near future. Both issues together have been voted for by almost 800 users from which I suspect most are paying their yearly maintenance fee to Atlassian. So Atlassian - 800 customers voting and an unknown number just turning away from you and you are not willing to address this issue NOW? Disappointing ...
Some other things to watch out for when using the scripts here:
- GreenHopper preference settings in propertytext.propertyvalue
- jiraworkflows where the username is embedded in the workflow XML
Hi... BTW if anyone has questions or feedback on the plugin probably best to add as a comment here or a bug here.
Matt, I have tested it like that yes, but as I think you said earlier the challenge is to ensure that everywhere a user ID could be is actually exercised.
Frank, the preview shows the number of records of each type updated, rather than the actual values. In the case of the filters though it's more complicated than a simple find and replace in the db, which is one of the advantages of this method.
It's possible of course that something has been missed... I don't use jira in every possible configuration. However if that's the case I can't see that you'd be worse off than having done it through sql, or (worst possible idea), a find and replace in the dumped XML.
cheers, jamie
Jamie, sounds promissing. Just a question, i couldnt find some tables in your picture (e.g. trustedapp, external_entities, etc.) on which script is your code made? (sorry, i currently have only a 3.13 testinstance otherwise i maybe would try it practically ) --Frank (do you think it would be a improvement if you show all updated fields? so we could compare it to SQL Scripts mentioned here)
Jamie,
I'm impressed! Do you test it with a unique userid string, then grep the backup up after the change to make sure you got all instances. The list of tables is tricky to maintain except by inspection of the database schema in two JIRA versions.
~Matt
Renaming a user is now part of the Script Runner plugin (details, installation instructions).
This will make all necessary changes in the database and reindex only those issues that require it. It will also modify any filters that have assignee/reporter/single or multi user custom field parameters that reference the user to be renamed. You do not need to restart or reindex.
This is for 4.2 at the moment only, I'll add support for previous versions if there is demand and no major issues are found.
@Thomas: i dont think a 3.8 script is good for 3.13. I guess for Oracle your best try is to use Srinis Script mentioned here: http://jira.atlassian.com/browse/JRA-1549?focusedCommentId=217005&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-217005
We've moved to Crowd user management through AD usernames. Looking through the XML backup (because I'm no DBA) there's ExternalEntity with IDs. The problem I'm trying to fix is one of mixed case usernames and a lower case usernames (for the same user - e.g. ABrown and abrown).
I'm confident the uppercase versions have been changed to lower case in the XML, the ExtenalEntity lines that would have created the mixed case entries removed, and the row counts have been changed. I still can't import the XML though.
Can anyone think what I may have missed modifying?
I also notice that this is now in the top 5 voted issues.
Does anyone know if Peter's (http://jira.atlassian.com/browse/JRA-1549?focusedCommentId=79599&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-79599) solution works for version 3.13?
Nitish, thanks, I was able to use that statement in a function which uses usermigration to update them all automatically, as the other statements do. I have added those statements to my comment above.
Hi erin,
Adding the below script could further enhance it
Update searchrequest Set REQCONTENT = Replace (REQCONTENT, 'OLDVAL' , 'NEWVAL');
because sometimes there are filters stored in such a fashion as
project=JRA and assignee= OLDVAL
Regards,
Nitish
Here is the PostGreSQL script for JIRA 4:
update changegroup set AUTHOR=newusername from usermigration where AUTHOR=oldusername; update changeitem set OLDVALUE=newusername from usermigration where OLDVALUE=oldusername; update changeitem set NEWVALUE=newusername from usermigration where NEWVALUE=oldusername; update columnlayout set username=newusername from usermigration where username=oldusername; update component set LEAD=newusername from usermigration where LEAD=oldusername; update external_entities set NAME=newusername from usermigration where NAME=oldusername; update favouriteassociations set USERNAME=newusername from usermigration where USERNAME=oldusername; update fileattachment set author=newusername from usermigration where author=oldusername; update filtersubscription set username=newusername from usermigration where username=oldusername; update jiraaction set AUTHOR=newusername from usermigration where AUTHOR=oldusername; update jiraaction set UPDATEAUTHOR=newusername from usermigration where UPDATEAUTHOR=oldusername; update jiraissue set reporter=newusername from usermigration where reporter=oldusername; update jiraissue set assignee=newusername from usermigration where assignee=oldusername; update jiraworkflows set creatorname=newusername from usermigration where creatorname=oldusername; update membershipbase set USER_NAME=newusername from usermigration where USER_NAME=oldusername; update OS_CURRENTSTEP set owner=newusername from usermigration where owner=oldusername; update OS_CURRENTSTEP set caller=newusername from usermigration where caller=oldusername; update OS_HISTORYSTEP set owner=newusername from usermigration where owner=oldusername; update OS_HISTORYSTEP set caller=newusername from usermigration where caller=oldusername; update portalpage set username=newusername from usermigration where username=oldusername; update project set lead=newusername from usermigration where lead=oldusername; update projectroleactor set roletypeparameter=newusername from usermigration where roletypeparameter=oldusername and roletype='atlassian-user-role-actor'; update schemepermissions set perm_parameter=newusername from usermigration where perm_parameter=oldusername and perm_type='user'; update searchrequest set authorname=newusername from usermigration where authorname=oldusername; update searchrequest set username=newusername from usermigration where username=oldusername; update trustedapp set CREATED_BY=newusername from usermigration where CREATED_BY=oldusername; update trustedapp set UPDATED_BY=newusername from usermigration where UPDATED_BY=oldusername; update userassociation set SOURCE_NAME=newusername from usermigration where SOURCE_NAME=oldusername; update userbase set username=newusername from usermigration where username=oldusername; update worklog set author=newusername from usermigration where author=oldusername; update worklog set updateauthor=newusername from usermigration where updateauthor=oldusername; update customfieldvalue set stringvalue=newusername from usermigration where stringvalue=oldusername; update userhistoryitem set username=newusername from usermigration where username=oldusername; -- The following function employs string replacement to update filters and may be damaging if any of the old usernames are also words that exist in the filter definition as a non-username string. Uncomment to use this at your own risk. -- create language plpgsql; -- create or replace function updatejirafilters() returns char as $$ -- declare -- line record; -- begin -- for line in select * from usermigration loop -- update searchrequest set REQCONTENT=replace(REQCONTENT, line.oldusername , line.newusername); -- end loop; -- return 'done'; -- end; -- $$ language plpgsql; -- select updatejirafilters();
username in LDAP is changeable, usually thats the uid. The username is in many companies connected to the name of a user (like mail-address or abbreviations of a users fullname). If that user's name is changed usually the uid will be changed accordingly (at least in our company thats done like that).
You can ship around that obstacle by using a unique identifier which consists of unconnected elements (like a random number/character combination). But its not readable anymore (because l75gd is much less understandable as fst (e.g. in my case)).
The Design Flaw is that you cant change the username while the system is running and/or without having a automated possibility for it (like a trigger in the AD/LDAP which syncs the JIRA instance). I guess if the API would have a ChangeUserName method i wouldnt care if there is that kind of design flaw (of course there must not be a downtime for reindexing, in our jira that would be around 30 to 45min.)
I dont say confluence doesnt have sideeffects on renaming without reindexing, but at least it can still operate
p.s. i have seen usernames which say old account/dont use me i guess thats the thing that wants to be avoided
Hello Tom,
you got it.
That is the whole point of this issue, which is open since such long time.
Atlassian uses as userid the same username which is input by the users at login and needed to do user authentication over LDAP.
Instead, they should use a hidden number / id, as it is in every good database design.
But they don't want to and prefer to stick year after year to their original mistake!
Bettina
Bettina,
Is in LDAP the username changeable ?
In that case there must be an underlying identifier that remains the same.
Hello Tom,
the problem is that in case of external user management - a widely used Jira feature - the username MUST be identical with the username that comes over LDAP.
In my example, I have to keep the Jira username up-to-date with our Active Directory.
Every time a user is renamed in the Active Directory, I also have to change the username in Jira.
You can replace "username" with "userid", the problem stays the same, even if nobody else than me (as Jira Admin) were able to see the username / userid.
So the username / userid is NOT meaningless, since it is exchanged with other systems!
Cheers
Bettina
I don't see why this is such a problem for Atlassian to follow up on.
Basic rule is simple.
Id's should never be visible to users, and be meaningless.
The username becomes userid, and the full name belonging to that user-id gets shown everywhere.
This way the user-id never needs to be changed, only 1 change is needed when the release with this change is done.
I'm afraid that this improvement will never be implemented, but nevertheless I vote for it since it's a MUST HAVE in my opinion.
As a new JIRA customer, I must say... This is an epic/ridiculous fail for Atlassian.
We are in the same situation, we need to merge two JIRA instances where there are cases of a single user having two different userids on those instances. So we need to rename those users on one of the instances, but we can't.
And this is flying around, opened and voted for, since 2003. LOL.
- A solution that depends on a production restart and reindex is not a practical solution to this problem
- The fact that my username seems to be the primary key, littered about throughout the database as the foreign key on however many tables, seems like really smelly development to me.
I used a simpler form
Update searchrequest Set REQCONTENT = Replace (REQCONTENT, 'OLDVAL' , 'NEWVAL');
It worked well!
I'm not going to pretend to be skilled at SQL scripts, but the following seems to work for replacing values in the reqcontent column:
update JIRASchema.searchrequest set reqcontent=replace(Cast(reqcontent AS NVARCHAR(Max)),'oldvalue','newvalue');
I got the idea from here - http://stevenharman.net/blog/archive/2007/12/30/a-better-search-and-replace-for-your-database.aspx
Hi
The script
update xxxx set xxx=yyyy where xxx=zzz
it is working fine.
Just that 1 point is missing.
The search request column has a table "request".
It has filtered stored in the form of SQL search.
eg:
SearchRequest id="10223" name="All Cranial" author="prossj" user="prossj" project="10011" request="reporter = alexp ORDER BY key DESC" favCount="1"/>
I find that the scripts will not correct that "alexp".
Please look into it!
The last mentioned db schema changes have been in 4.0 and 3.12. As 4.0 were merely db type migrations to larger data types i guess you should be save with the 3.13 scripts mentioned here.
Has anyone tried this on 4.2.0 (or, I guess, 4.2.1) yet? Particularly with MySQL? We have some users to rename.
Rain, i guess Srinis Oracle Script is the latest posted here. OracleDB-UserNameUpdate-SQL-Jira3.13.4-Enterprise.txt. From 3.13 to 4.1 there werent any username relevant tablechanges as far as i know. Whoever uses the latest version is welcome to be the pioneer to try it
Our LDAP directory has capital letters in the username (eg. AustinS). If i create similar users in JIRA in lowercase (austins)(JIRA doesnt support uppercase), will the LDAP integration be possible directly.(USING THE DATABSE EDITING WORKAROUND)
Please add this. Our IT person just asked me for help with the typical case (user gets married). She created a new JIRA user with the same groups and was going to just try to reassign and change reporter on all the tickets the old username had (700+). Of course, due to restrictions on editing closed issues, plus various permission schemes we've set up, even I am not able to bulk change the issues. I now have to start combing through our various permissions and project setups just so that I can get bulk change working. I'm sure I'll get it going eventually but it's a hokey workaround.
Thanks,
We are running JIRA for our company using LDAP as well, and every few months it seems we have a request to change user names due to marital status. This feature is very much needed and would save us from so many headaches and hours of explanation to users.
I have successfully (I hope!) renamed a user using Frank Stiller's SQL scripts. Thank you, Frank! I added one table to the script: userhistoryitem, discovered when I grepped the .xml backup for the oldusername after running Frank's script.
update userhistoryitem x inner join usermigration u on x.username = u.oldusername set x.username = u.newusername;
Atlassian, you should officially sanction and support Frank's script at the very least.
Please hurry!
Nancy, I am delighted you are able to keep your sense of humor. :-S
Well, we have been live with Jira for one month and have received our first user rename request. I approach this with serious trepidation and much frustration. This user cannot log in at all now because our IT department has already renamed her username. Atlassian, you have really dropped the ball on this one. I am really embarrassed to explain this to my user community! Please hurry!
I think the best approach to solving this is a plugin that does what all the different versions of the scripts out there do.
1. It can also check the version of the database schema to know what to change
2. It can handle the more complex cases where the username is embedded in a parameter to a scheme, e.g. notification scheme with a Custom User Field parameter
3. It can handle renaming a user and also merging two userids into one.
4. It can check for existing users with the same name
Testing it is likely to be the hardest thing. How do I set up a JIRA instance with a particular userid embedded everywhere it can be?
~Matt
p.s. If I had a DolLorean DMC-12 and the rest, I've got a few other things to fix first before JRA-1549.
I will stress my previous comment once again...
I could care less how this information is stored in the database. All I want is a way to rename a user. It doesn't happen every day, so some supported function in the administration section where I can enter/pick a user and enter their new name which does whatever it needs to do in order to make everything work (update all the username fields like the scripts attached to this post do) would be a perfectly acceptable answer in my opinion. Even just a supported script to download and run that I don't have to dig through an issue to find would be fine. Much better than the string replacement in XML which could replace much more than you really want it to.
Great work Matt Doar,
Now we only need get the hold of George McFly, Dr. Emmett "Doc" Brown, a slightly modified DeLorean DMC-12 and some plutonium to feed the flux capacitor and this thing will be sorted in no time..
Regards
Jonas
I found this on a Confluence documentation page, and it goes some way to explaining the historical decision not to use the userbase id field in JIRA.
"Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key."
Vlastimil,
I've pondered doing this as a plugin too. Let us know how you get on.
~Matt
Now that you've mentioned you are building a plugin, Atlassian is going to stop working on any supported solution - it has happend before with cluster support. However if you can make it work in less than 7 years you'll be ahead of the curve and will make at least 443 people very happy. Thanks for stepping up to the plate.
P.S. As frustrating as some of these road blocks are I still love what Jira can do.
Hi all,
I'm just working on plugin which allows user rename and user merge in jira 4.1.2 directly from admin console. Work is very promising for now.
I've only just read the August update which states that we're going to be waiting another 6 months in all likelihood. Is there any way of codifying the recommended workarounds so that Jira would apply the database changes itself? I really think that, after 7+ years, we could do with a tactical solution rather than waiting for the mythical Crowd integration to happen. What do you reckon Atlassian? Cheers, Mike
good news for me, personally, is that my senior managers haven't complained when I suggested we could save money by not renewing our jira, confluence and greenhopper licences for a while, which expired yesterday, either until there's a compelling new feature we can't live without which includes the authentication model i.e. the ability to rename users.
We would love to have a supported solution for this use case at least for mass mutations such as renaming n user accounts when we link them to LDAP servers. Our current solution which we applied once when migrating our own user database to LDAP authentication and which we will apply again migrating one of our customer which we cater ActiveDirectory services to is dumping to XML JIRA, transforming and reloading. This takes days of quality assurance until we are 100% sure that the result is fully consistent again.
I didn't want to create any different tables, so I just changed them all to a format like
UPDATE [table] SET [column] = [newvalue] WHERE [column] = [oldvalue];
I didn't get any MySQL errors. The only error I did get was an application error when trying to look at the user details page. Since my user had already been in the application using their new username, the external_entities table already had an entry with that new username so when I updated the old one it made a duplicate entry which the application apparently doesn't like, so I had to remove that. So if your user has already been using the application with their new username, I wouldn't bother with the external_entities update, it hasn't seemed to cause any issues for me having both the old and new.
When you say basically, what modifications did you make?
Also, were any MySQL errors observed or Tomcat application errors?
I basically ended up using the one from http://jira.atlassian.com/browse/JRA-1549?focusedCommentId=170640&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-170640
I just used one of the sql scripts and that got the job done for me. Atlassian, please listen to your users here. Our problem is WE NEED TO RENAME USERS, but usually not that often. In my opinion, a supported script is a perfectly acceptable solution.
We urgently need this too. Am not allowed to use the scripts unless they are officially supported by Atlassian. Please deliver officially supported scripts or implement it in JIRA.
7 years...really? Very disappointing Atlassian. I'm sure this would have been a much easier change 7 years ago when there was 7 years less new code depending on the user name as the id field. WAY past time to pay down some technical debt.
Several times I have been tempted to use the scripts fix several of our users, but I always stopped because I don't know if any of the extensions we are using store the information. This is the classic example of not using data that could be changed as a key.
Is this safe to use with the extensions? Is there a good way to tell?
The latest 3.13 scripts should be sufficient as there are no db changes for 4 as i wrote 3 comments ago. What is more relevant is what db engine your are targeting? Thats the best confirmation you get so far. And reindexing is required, restarting maybe recommended.
Thanks, will ensure to restart Jira after the renames. Can someone post the latest version of the script that has been confirmed to work with version 4?
Keep in mind that even updating the database isn't going to be enough. JIRA caches a lot of information that is only read during application start-up, as I learned the hard way, so updating the database will only work for you if you intend to restart JIRA afterwards. (Some changes take effect immediately, but other fields are cached indefinitely.)
brutal.... all we need is a supported SQL script. c'mon atlassian...
same problem here, need a script to run, but there are so many update statements on here I don't know which one is valid for Jira 4 ...
The base thing is. The Scripts mentioned here are running for a specified Database-Engine and a specific JIRA Version. So in your case i guess its: JIRA 4.1.2 and Oracle. So i would try Srini's attached Oracle-Script. In the table usermigration you write oldusername: jdoe newusername janedoe and then you synchronize jdoe.
I guess that should do it, except you need a sql-server script also, but you are not running two different databases, are you?
Here's the jira version upgrade details:
Old | New | |
---|---|---|
Jira version | 3.13 | 4.1.2 |
Database | MS SQL Server 2005 | Oracle 10.2.0.4 |
Apache Tomcat version | 5.5.26 | 6.0.20 |
Java version | 1.6.0_03 | 1.6.0_20 |
Mixed user mode means is that, we are using the same JIRA in company and other persons who are not company employees. We want company employees login with active directory authentication and others login with jira userbase authentication.
Let me try to explain our problem step by step.
- Jane Doe started working in our company. Jira user and active directory "jdoe" is defined for her.
- Jane Doe quited from our company. jdoe deleted from active directory but jira user only disabled.
- John Doe started working in our company. Active directory user "jdoe" is defined but jira user "jdoe" couldn't be defined because "jdoe" was already defined.
- Now we want to change Jane Doe's user "janedoe" and use "jdoe" for John Doe.
Which script/s can we use for this change?
Thanks.
I am still missing which database engine you are running, like MySQL, Oracle or such. And i am interested what you mean by mixed user mode? You mean users which are not in den AD are authenticated locally? I can maybe test the latest JIRA Release for MySQL, but i cant promise you that will be soon, depends what database changes have been done since 3.13, doesnt seems much, so probably the 3.13 scripts can be used on 4.1 also, only found this: 4.0 db changes.
We upgraded JIRA version to 4.1.2 and trying to use jira mixed user mode (Active directory + Jira user management). Some users are different from active directory user and we want to migrate jira username to ldap username. Can you tell us which script is compatible with jira 4.1.2 ?
Thanks.
Use one of the various SQL-Scripts provided here. Which Database Engine and JIRA Version are you using?
If we use "find and replace from xml" method for renaming jira users, there will be wrong updates because of some usernames enlisted in jira issue comment and description fields. How can we solve this problem. We don't want to change issue contents.
we just had an email from atlassian to renew our maintenance contract - US$4000. Guess what, I'm going to rush to pay this just as fast as Atlassian have been rushing to fix this issue!
— here's what I emailed them —
Dear Atlassian,
we feel no need to renew our maintenance contract with any degree of
urgency, just as Atlassian have felt no need to fix some significant
outstanding issues namely
JRA-1391 Renaming groups after creation (7 years old)
JRA-1549 Ability to rename a user (6.5 years old)
Let us know when you fix these and we'll consider spending more money.
— here's the reply (email munged deliberately)---
From: Jason Caragan <salesXX@XXatlassian.com>
Hi Paul,
Thanks for your feedback and sorry to hear you won't be renewing. I'll
be sure to forward your concerns to our Products team and hope to see
them addressed with a future release.
Cheers,
Jason
Jason Caragan
One vote from us also. Over here, some people DO get married and change names...
Come on, guys, this is basic stuff here. Export all your data, do a find/replace, then re-import all your data is a really crappy solution no matter what the problem is.
Also keep in mind that for every user who makes a login and posts and/or votes, there's likely a couple dozen out there that just shake their heads and start looking for alternatives.
Atlassian sales team was kind enough to send us an informational quote to renew our Jira licence.
We were kind enough to reply:
Thank you for your informational quote. We will gladly renew the licence after bugs affecting us have been resolved, namely:
JRA-2364Hide Time Tracking estimates from certain users (e.g. customers)- JRA-1391 Renaming groups after creation.
JRA-1549Ability to rename a userAll of these bugs have been open for seven years now!
Atlassian, treating your customers this way is not a way to do business. If everybody stops paying for Jira, maybe then they'll reconsider. I urge you to do the same.
7 years and it's now the number 5 on the most popular issues, and no assignee? Com'on!
Hi Frank, I have checked the search storedproc again. The tables listing the username are listed in the attached .csv file. I will be searching through our production db soon and will be able to add additional tablenames. I will list these once retrieved.(This is only a test jira install)
Hy Earl,
by a quick lookthrough the it looks good. But it seems very generic. The seasoned scripts mentioned here are only looking in columns identified to be username-relevant. With your storedprocedure you are replacing every column in the database, do you? I guess that can be problematic. Like a group support and a user support (just a simple one i hope).
cheers Frank
I am new to the Jira environment. One of our staff have gotten married. I did some research and figured that its data and as such can be manipulated by sql if you're using sql. I have tested this on a test system but would welcome any comments from the more seasoned Jira Admins.
The search script does just that - searching for occurences of a particular data string. The find and replace does the very same thing except it replaces the 'string' found with any other data. Pls review and advise.
The Jira service needs to be shutdown when performing the change.
Funny part is Atlassian is not even providing any kind of updates here. As I mentioned below, if there is no intention now to fix this problem then just close this issue by saying WON'T FIX!
That way everyone gets a clear picture on what they should be doing rather than keep waiting without any ETA from Atlassian.
Thanks,
Amar
Completely agree with Jonas. I think the age of this issue and the number of votes clearly shows that just voting for the issue is NOT enough. I have stated a number of times on several issues that every major software company end of lifes their products. Forget backward compatibility, I have a number of scripts and other customizations I would gladly rewrite to gain many new features and fixes that Atlassian has used 'backward compatability' as an excuse for not adding or fixing.
Instead of complaining about users that verbaly show that this is a feature we should have had 5 years ago, maybe Atlassian could just fix the bug and close the issue? Further more i think this lack of feature is simpler to conduct if the database scheme is completely restructured, meaning that sure the database will not be backwards compatible, but who would try to upgrade and then downgrade without restoring the last dump?
Ubisoft, I have removed you from watching this issue as per my email to you about your autoresponder.
La requête #466814 - [JIRA] Commented: (JRA-1549) Ability to rename a user a été crée.
Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel.
Cette requête sera traitée dès que possible.
Merci de votre collaboration, Your request 466814 - [JIRA] Commented: (JRA-1549) Ability to rename a user has been created.
For a follow-up, and/or add comments, please reply to this e-mail.
This request will be treated as soon as possible.
Thank you for your cooperation,
Votre requête / Your request
Issue (View Online/jira.atlassian.com/browse/JRA-1549>)
Key: JRA-1549/jira.atlassian.com/browse/JRA-1549>
Issue Type: http://jira.atlassian.com/images/icons/improvement.gif /jira.atlassian.com/browse/JRA-1549> Improvement
Status: http://jira.atlassian.com/images/icons/status_open.gif Open
Priority: http://jira.atlassian.com/images/icons/priority_major.gif Major
Assignee: Unassigned
Reporter: Michael Phillimore-Brown/jira.atlassian.com/secure/ViewProfile.jspa?name=firewater>
Votes: 384
Operations
http://jira.atlassian.com/images/icons/bullet_creme.gif View all/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View comments/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View history/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel>
Ability to rename a user/jira.atlassian.com/browse/JRA-1549>
Updated: 30/Apr/10 11:42 AM Created: 08/Apr/03 7:57 AM
The following comment has been added to this issue: [ Permalink/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=193131#action_193131> ]
Author: Gili/jira.atlassian.com/secure/ViewProfile.jspa?name=cowwoc>
Date: 30/Apr/10 11:42 AM
Comment:
Guys, this is getting spammy. Please stop posting "me too" comments and just vote for the issue. Votes are enough.
Also, can someone please unsubscribe ubisoft from this issue? Their auto-responder only makes things worse.
Project: JIRA/jira.atlassian.com/browse/JRA>
Components: Administration
Affects Versions: 2.0.2
Attachments: D3904554-8F1C-8F48-9B44-FF092AD4E845, D3904554-8F1C-8F48-9B44-FF092AD4E845, D3904554-8F1C-8F48-9B44-FF092AD4E845, D3904554-8F1C-8F48-9B44-FF092AD4E845, jira_renameuser_all.sql, OracleDB-UserNameUpdate-SQL-Jira3.13.4-Enterprise.txt, renameuser.sql
Description
As Jira starts to take off, invariably people play around with the system and begin to use it in anger gradually. During this time they sometimes find that the original username they created is not really the best they could have chosen. However, at the moment they cannot change this.
Would it be possible to change your login id as part of your profile? I know this is often a tough thing to do, but many of our users would find it useful.
Cheers!
This message was automatically generated by Atlassian JIRA/www.atlassian.com/c/JIRA/10140> Enterprise Edition, Version: 4.1.1-522 - Bug/feature request/jira.atlassian.com/default.jsp?clicked=footer>.
If you think it was sent incorrectly, contact one of this server's administrators/jira.atlassian.com/secure/Administrators.jspa>.
Guys, this is getting spammy. Please stop posting "me too" comments and just vote for the issue. Votes are enough.
Also, can someone please unsubscribe ubisoft from this issue? Their auto-responder only makes things worse.
La requête #466807 - [JIRA] Commented: (JRA-1549) Ability to rename a user a été crée.
Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel.
Cette requête sera traitée dès que possible.
Merci de votre collaboration, Your request 466807 - [JIRA] Commented: (JRA-1549) Ability to rename a user has been created.
For a follow-up, and/or add comments, please reply to this e-mail.
This request will be treated as soon as possible.
Thank you for your cooperation,
Votre requête / Your request
Issue (View Online/jira.atlassian.com/browse/JRA-1549>)
Key: JRA-1549/jira.atlassian.com/browse/JRA-1549>
Issue Type: http://jira.atlassian.com/images/icons/improvement.gif /jira.atlassian.com/browse/JRA-1549> Improvement
Status: http://jira.atlassian.com/images/icons/status_open.gif Open
Priority: http://jira.atlassian.com/images/icons/priority_major.gif Major
Assignee: Unassigned
Reporter: Michael Phillimore-Brown/jira.atlassian.com/secure/ViewProfile.jspa?name=firewater>
Votes: 384
Operations
http://jira.atlassian.com/images/icons/bullet_creme.gif View all/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View comments/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View history/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel>
Ability to rename a user/jira.atlassian.com/browse/JRA-1549>
Updated: 30/Apr/10 11:12 AM Created: 08/Apr/03 7:57 AM
The following comment has been added to this issue: [ Permalink/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=193128#action_193128> ]
Author: amar goradia/jira.atlassian.com/secure/ViewProfile.jspa?name=amargoradia>
Date: 30/Apr/10 11:12 AM
Comment:
I echo Michelle. Please help and give us an update ASAP...
On Apr 29, 2010, at 8:23 AM, "Michelle Wetherill (JIRA)"
Project: JIRA/jira.atlassian.com/browse/JRA>
Components: Administration
Affects Versions: 2.0.2
Attachments: D3904554-8F1C-8F48-9B44-FF092AD4E845, D3904554-8F1C-8F48-9B44-FF092AD4E845, D3904554-8F1C-8F48-9B44-FF092AD4E845, jira_renameuser_all.sql, OracleDB-UserNameUpdate-SQL-Jira3.13.4-Enterprise.txt, renameuser.sql
Description
As Jira starts to take off, invariably people play around with the system and begin to use it in anger gradually. During this time they sometimes find that the original username they created is not really the best they could have chosen. However, at the moment they cannot change this.
Would it be possible to change your login id as part of your profile? I know this is often a tough thing to do, but many of our users would find it useful.
Cheers!
This message was automatically generated by Atlassian JIRA/www.atlassian.com/c/JIRA/10140> Enterprise Edition, Version: 4.1.1-522 - Bug/feature request/jira.atlassian.com/default.jsp?clicked=footer>.
If you think it was sent incorrectly, contact one of this server's administrators/jira.atlassian.com/secure/Administrators.jspa>.
I echo Michelle. Please help and give us an update ASAP...
On Apr 29, 2010, at 8:23 AM, "Michelle Wetherill (JIRA)" <jira@atlassian.com
La requête #466364 - [JIRA] Commented: (JRA-1549) Ability to rename a user a été crée.
Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel.
Cette requête sera traitée dès que possible.
Merci de votre collaboration, Your request 466364 - [JIRA] Commented: (JRA-1549) Ability to rename a user has been created.
For a follow-up, and/or add comments, please reply to this e-mail.
This request will be treated as soon as possible.
Thank you for your cooperation,
Votre requête / Your request
Issue (View Online/jira.atlassian.com/browse/JRA-1549>)
Key: JRA-1549/jira.atlassian.com/browse/JRA-1549>
Issue Type: http://jira.atlassian.com/images/icons/improvement.gif /jira.atlassian.com/browse/JRA-1549> Improvement
Status: http://jira.atlassian.com/images/icons/status_open.gif Open
Priority: http://jira.atlassian.com/images/icons/priority_major.gif Major
Assignee: Unassigned
Reporter: Michael Phillimore-Brown/jira.atlassian.com/secure/ViewProfile.jspa?name=firewater>
Votes: 383
Operations
http://jira.atlassian.com/images/icons/bullet_creme.gif View all/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View comments/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View history/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel>
Ability to rename a user/jira.atlassian.com/browse/JRA-1549>
Updated: 29/Apr/10 10:23 AM Created: 08/Apr/03 7:57 AM
The following comment has been added to this issue: [ Permalink/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=193006#action_193006> ]
Author: Michelle Wetherill/jira.atlassian.com/secure/ViewProfile.jspa?name=mwetherill>
Date: 29/Apr/10 10:23 AM
Comment:
Atlassian, please help! We need this fixed! We are trying to integrate with LDAP but the user names in JIRA (and Confluence) do not match up. We need a way to correct all of the user names. What is the recommended approach? Is it still to try and do a find/replace in the XML export? Has someone from Atlassian reviewed the scripts posted on this issue and "approved" them?
Project: JIRA/jira.atlassian.com/browse/JRA>
Components: Administration
Affects Versions: 2.0.2
Attachments: D3904554-8F1C-8F48-9B44-FF092AD4E845, D3904554-8F1C-8F48-9B44-FF092AD4E845, jira_renameuser_all.sql, OracleDB-UserNameUpdate-SQL-Jira3.13.4-Enterprise.txt, renameuser.sql
Description
As Jira starts to take off, invariably people play around with the system and begin to use it in anger gradually. During this time they sometimes find that the original username they created is not really the best they could have chosen. However, at the moment they cannot change this.
Would it be possible to change your login id as part of your profile? I know this is often a tough thing to do, but many of our users would find it useful.
Cheers!
This message was automatically generated by Atlassian JIRA/www.atlassian.com/c/JIRA/10140> Enterprise Edition, Version: 4.1.1-522 - Bug/feature request/jira.atlassian.com/default.jsp?clicked=footer>.
If you think it was sent incorrectly, contact one of this server's administrators/jira.atlassian.com/secure/Administrators.jspa>.
Atlassian, please help! We need this fixed! We are trying to integrate with LDAP but the user names in JIRA (and Confluence) do not match up. We need a way to correct all of the user names. What is the recommended approach? Is it still to try and do a find/replace in the XML export? Has someone from Atlassian reviewed the scripts posted on this issue and "approved" them?
La requête #466181 - [JIRA] Commented: (JRA-1549) Ability to rename a user a été crée.
Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel.
Cette requête sera traitée dès que possible.
Merci de votre collaboration, Your request 466181 - [JIRA] Commented: (JRA-1549) Ability to rename a user has been created.
For a follow-up, and/or add comments, please reply to this e-mail.
This request will be treated as soon as possible.
Thank you for your cooperation,
Votre requête / Your request
Issue (View Online/jira.atlassian.com/browse/JRA-1549>)
Key: JRA-1549/jira.atlassian.com/browse/JRA-1549>
Issue Type: http://jira.atlassian.com/images/icons/improvement.gif /jira.atlassian.com/browse/JRA-1549> Improvement
Status: http://jira.atlassian.com/images/icons/status_open.gif Open
Priority: http://jira.atlassian.com/images/icons/priority_major.gif Major
Assignee: Unassigned
Reporter: Michael Phillimore-Brown/jira.atlassian.com/secure/ViewProfile.jspa?name=firewater>
Votes: 381
Operations
http://jira.atlassian.com/images/icons/bullet_creme.gif View all/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View comments/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View history/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel>
Ability to rename a user/jira.atlassian.com/browse/JRA-1549>
Updated: 29/Apr/10 4:03 AM Created: 08/Apr/03 7:57 AM
The following comment has been added to this issue: [ Permalink/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192984#action_192984> ]
Author: Martin Lopušek [CFH]/jira.atlassian.com/secure/ViewProfile.jspa?name=foster>
Date: 29/Apr/10 4:03 AM
Comment:
It shoud be good if any plugin would be created to rename user. Because this status is absolutely untenable. This is not about: JIRA - because you'got issue, but We've got issue, because we have jira.
Project: JIRA/jira.atlassian.com/browse/JRA>
Components: Administration
Affects Versions: 2.0.2
Attachments: D3904554-8F1C-8F48-9B44-FF092AD4E845, jira_renameuser_all.sql, OracleDB-UserNameUpdate-SQL-Jira3.13.4-Enterprise.txt, renameuser.sql
Description
As Jira starts to take off, invariably people play around with the system and begin to use it in anger gradually. During this time they sometimes find that the original username they created is not really the best they could have chosen. However, at the moment they cannot change this.
Would it be possible to change your login id as part of your profile? I know this is often a tough thing to do, but many of our users would find it useful.
Cheers!
This message was automatically generated by Atlassian JIRA/www.atlassian.com/c/JIRA/10140> Enterprise Edition, Version: 4.1.1-522 - Bug/feature request/jira.atlassian.com/default.jsp?clicked=footer>.
If you think it was sent incorrectly, contact one of this server's administrators/jira.atlassian.com/secure/Administrators.jspa>.
It shoud be good if any plugin would be created to rename user. Because this status is absolutely untenable. This is not about: JIRA - because you'got issue, but We've got issue, because we have jira.
La requête #463924 - [JIRA] Commented: (JRA-1549) Ability to rename a user a été crée.
Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel.
Cette requête sera traitée dès que possible.
Merci de votre collaboration, Your request 463924 - [JIRA] Commented: (JRA-1549) Ability to rename a user has been created.
For a follow-up, and/or add comments, please reply to this e-mail.
This request will be treated as soon as possible.
Thank you for your cooperation,
Votre requête / Your request
Issue (View Online/jira.atlassian.com/browse/JRA-1549>)
Key: JRA-1549/jira.atlassian.com/browse/JRA-1549>
Issue Type: http://jira.atlassian.com/images/icons/improvement.gif /jira.atlassian.com/browse/JRA-1549> Improvement
Status: http://jira.atlassian.com/images/icons/status_open.gif Open
Priority: http://jira.atlassian.com/images/icons/priority_major.gif Major
Assignee: Unassigned
Reporter: Michael Phillimore-Brown/jira.atlassian.com/secure/ViewProfile.jspa?name=firewater>
Votes: 381
Operations
http://jira.atlassian.com/images/icons/bullet_creme.gif View all/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View comments/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel>
http://jira.atlassian.com/images/icons/bullet_creme.gif View history/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel>
Ability to rename a user/jira.atlassian.com/browse/JRA-1549>
Updated: 22/Apr/10 7:34 AM Created: 08/Apr/03 7:57 AM
The following comment has been added to this issue: [ Permalink/jira.atlassian.com/browse/JRA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192415#action_192415> ]
Author: Oleg Chekan/jira.atlassian.com/secure/ViewProfile.jspa?name=oleg.chekan>
Date: 22/Apr/10 7:34 AM
Comment:
this issue became more important now since you introduce Google Apps Integration.
It is a headache for JIRA administrators to recreate users with matching Google Apps usernames!
Project: JIRA/jira.atlassian.com/browse/JRA>
Components: Administration
Affects Versions: 2.0.2
Attachments: jira_renameuser_all.sql, OracleDB-UserNameUpdate-SQL-Jira3.13.4-Enterprise.txt, renameuser.sql
Description
As Jira starts to take off, invariably people play around with the system and begin to use it in anger gradually. During this time they sometimes find that the original username they created is not really the best they could have chosen. However, at the moment they cannot change this.
Would it be possible to change your login id as part of your profile? I know this is often a tough thing to do, but many of our users would find it useful.
Cheers!
This message was automatically generated by Atlassian JIRA/www.atlassian.com/c/JIRA/10140> Enterprise Edition, Version: 4.1.1-522 - Bug/feature request/jira.atlassian.com/default.jsp?clicked=footer>.
If you think it was sent incorrectly, contact one of this server's administrators/jira.atlassian.com/secure/Administrators.jspa>.
this issue became more important now since you introduce Google Apps Integration.
It is a headache for JIRA administrators to recreate users with matching Google Apps usernames!
Absorb these stats for a second...
Created: 08/Apr/03 7:57 AM
Votes: 639
Watchers: 326
Thank you all commenters, for bumping this issue since 2003.
Thank you Atlassian for allowing some plugin developers to make a little money off of this bug.
Seriously though. You should fix it. It's getting annoying.
Even a hacky fix would do for now, like keeping the userid as a back-end foreign key but duplicating that value as an editable attribute (displayname? newname? get-users-off-our-backs-ID? who cares), then changing visual templates so you're displaying that new attribute where userid is currently being displayed (if we can do a find and replace, why can't you guys? keep your DB schema, just change the visual templates so we're looking at AND EDITING a different attribute of the user object).
We don't care how messy your code is, we care how messy our JIRA instances are, and they're getting messy. Since you guys are closed-source, it shouldn't matter what black magic you do on the back-end. Just give the users what they want and close this bug. It's killin me, smalls.