Please clean the issues a little and put the the user and group renaming on your road map - not having the renaming capability is a major pain.

The requirement is very realistic consider a project manager managing all JIRA projects and then leaves the company, so how do we change the username to the new project manager? and I am talking about around 100 JIRA work spaces

So what happens when a woman gets married/divorced and changes her name? Right now, we either have to create a new JIRA user and orphan the old data, or use the cumbersome backup/restore with search/replace on the name – including unnecessary system downtime for an application that our company uses world-wide.

It truly seems to be designed either for only open-source internet-based projects (where people are encouraged not to use their real name) or from a very male-centric viewpoint. I suspect many of the votes for this issue are from other enterprise customers, who like me are at a complete loss when trying to understand why this issue is still low priority and unschduled for any release. At least knowing when it will be fixed might give us a reason to renew maintenance, rather than permanently branching off our source code to fix it ourselves.

How difficult would it be to give users a system-assigned unique key, rather than storing the username in all related tables?

Thank you for your feedback.

We are hoping to improve JIRA's user management by migrating to a Polis - JRA-1962, which will allow a much better support for LDAP users and groups. As part of the migration, we are hoping to address this issue as well.

We will be finalising our plans for JIRA 3.7 in a week or two. I will update this issue as soon as that's done. In either case, we realise that this feature is important, and are hoping to get to it in one of the future releases.

Thanks,
Anton

update userassociation set source_name='newname' where username='oldname';

?

can you tell us something new about this feature? When will there be a version
available resolving the problem?

When will there be a solution for this ?

Cheers,
Nick

I think I need to vent a little.

<RANT>

As a general rule we love JIRA, and it has been a boon for managing our development processes. But you manage to highlight the key area where I am dissatisfied with Atlassian. For a product that does such a good job managing development schedules and priorities, your own project has almost 90% of the open issues lumped in as unscheduled. Saying that you are going to do this "in the next few releases though it is hard to say exactly when" is not really acceptable. I have seen this type of response on a number of other issues that I consider high priority for an enterprise customer.

The core problem is NOT that JIRA is imperfect. Nor is it that some of the deficiencies will take time and effort to get corrected. But when issues seem to stay open for years and years, it gives little hope that they will ever be addressed. When your customers consider an issue to be high priority, the fact that you do not assign them to a versionsends a clear signal that they are not high priority to Atlassian.

Simply building a more extensive roadmap would give your customers some hope that their needs will eventually be addressed. I need such information before I will commit to paying for maintenance on JIRA. Incremental fix releases are nice, but they seem to be reaching the point of diminishing return. We would probably get more value by not purchasing maintenance and staying on our current level of JIRA. In a couple years, if significant improvements have actually arrived, then we could just start over by purchasing a new license.

</RANT>

Sorry for going a little off-topic. But I think that others may echo my sentiments, which is why I posted them here.

Thanks,
Phil

Nick, can you pls list for us what's higher priority in the pipeline than this issue - which has 60-odd votes and has been around for 3.5 years - with an explanation of why they're higher priority? I'm sure there's a good reason why other things need attention sooner, and I'm sure it would allay people's frustration if we understood WHY features like this keep getting bumped / not considered.

Cheers.

I'll answer your separate questions on JRA-11125 over there, but I wanted to let you know a little bit about why every issue is not assigned to a release.

Currently there are 1998 open feature requests in the JIRA project. As of today, this feature request is the 22nd most popular feature request. Many of the issues that you have voted on, or linked to from JRA-11125 are more popular than this issue.

The reason that it has not yet been done:

• it would involve a complete change of the entity model for JIRA, which would make it almost impossible to maintain backward compatibility (something that we have done for the last 3.5 years, and which makes it easy to upgrade JIRA)
• there is a work-around (although cludgy)
• first we have to move to 'atlassian-user', which Confluence have recently moved to, and has shown to have performance problems. Rather than have it affect two products, we are awaiting Confluence fixing the performance problems first.

Unfortunately, to remain flexible to customers, and help address important issues (such as the one you are raising on JRA-11125), we don't construct artificial road-maps for the next X years, but choose to attempt the issues that will provide the most customer value at each release.

Currently (JIRA 3.7), we are attempting the enterprise issue of project roles. This will reduce administration for almost all 'enterprise' customers, but provides little value for those customers with few users. In future versions of JIRA, we wish to attack core functionality (searching, creating, dashboards), and performance. From our discussions with many of our customers (on jira.atlassian.com, forums, in person, phone calls and emails) this is the best balance for all our customers.

We try to lump features together, and attack many features at once. See JRA-10404 for an example of us killing many birds with one stone. Thus, this feature will most likely be done in conjunction with LDAP integration, atlassian-user, and making JIRA compatible with our new SSO product, Crowd. This will enable us to complete many more customer features than we would otherwise be able to do.

In response to Adam's query - there are at least 21 other issues that have a higher 'customer priority' than this one, and that is even given the skewing that we have towards admin features on this issue tracker (end users generally don't raise feature requests, even though they are the end users of the product). Hence features that help administrators are normally more highly ranked than they otherwise are for the end users of our product. In terms of features that help admins, we feel that project roles are much more of a help (easing user administration / permissioning) than this feature.

To answer Neal's question - when we started JIRA, we used OSUser, which gave us database portability / application server portability of user management. If the J2EE spec had contained user management, this would not have happened. Yes it was a mistake, but as I mentioned above, one that is not easily rectified.

Hopefully that gives you some insight into why we manage the JIRA project as we do.

Cheers,
Scott

Does it work?

I don't suppose this has been tested (it's been up there a few months)..

To my knowledge, the schmea has not changed since the script was created. If it worked then, it should work now. (I doubt that it will work for 3.7).

Cheers,
Nick

Original:
update jiraissue set reporter='newname' where reporter='oldname';
update jiraissue set assignee='newname' where assignee='oldname';
update jiraaction set AUTHOR='newname' where AUTHOR='oldname';
update changegroup set AUTHOR='newname' where AUTHOR='oldname';
update changeitem set OLDVALUE='newname' where OLDVALUE='oldname' and FIELD='assignee';
update changeitem set NEWVALUE='newname' where NEWVALUE='oldname' and FIELD='assignee';
update searchrequest set authorname='newname' where authorname='oldname';
update searchrequest set username='newname' where username='oldname';
update schemepermissions set parameter='newname' where parameter='oldname' and type="user";
update searchrequest set authorname='newname' where authorname='oldname';
update schemepermissions set PARAMETER='newname' where PARAMETER='oldname' and TYPE="user";
update membershipbase set USER_NAME='newname' where USER_NAME='oldname';
update OS_CURRENTSTEP set owner='newname' where owner='oldname';
update OS_CURRENTSTEP set caller='newname' where caller='oldname';
update OS_HISTORYSTEP set owner='newname' where owner='oldname';
update OS_HISTORYSTEP set caller='newname' where caller='oldname';
update fileattachment set author='newname' where author='oldname';
update filtersubscription set username='newname' where username='oldname';
update project set lead='newname' where lead='oldname';
update userbase set username='newname' where username='oldname';
update customfieldvalue set stringvalue='newname' where stringvalue='oldname';
update columnlayout set username='newname' where username='oldname';
update portalpage set username='newname' where username='oldname';

i found these fields also containing the usernames:
update component set LEAD='newname' where LEAD='oldname';
update jiraworkflows set creatorname='newname' where creatorname='oldname';
update userassociation set SOURCE_NAME='newname' where SOURCE_NAME='oldname';

I there a official workaround or a link to a guide like the one for Confluence here ?

We do not encourage modifying the username via SQL / database. However there is a way of editing the username in the XML backup.

Please have a look at the following guide

• http://confluence.atlassian.com/display/JIRA/Changing+the+username+in+Jira

Let me know if it addresses and fixes your problem.

Cheers,
Kay Nny

why is the sql method not favorised? I find it better, its just running the script and reindexing the instance. Clear Columns will be updated with old -> new names.

In the xml solution i must replace a huge textfile and the point of If the username is a common word (e.g. admin), you may replace text that is not relevant to the user. So please be aware of this issue when performing the replace is giving me a small headache. We have abbrevations for our usernames (2-4 chars long) they may not be unique like a fullname or something else. And the script/reindexing seems to work during usual working hours, the text replace is best to run on weekends isnt it?

Nice.
Dreamweaver 8 works beautifully for a mass find and edit of variables in the xml page. So does SQL

thanks for the scripts. I however modified
them a bit so that you can update many usernames at a time.
Just backup, create a temporary table, insert the usernames that should be converted in the table,
run the scripts, restart and re-index jira.

Worked for me.

This works for jira 3.8 and Oracle 9.2:
-----------
REM Create temporary table for usernames

CREATE TABLE UNAMES
(
OLD VARCHAR2(50),
NEW VARCHAR2(50)
)

REM Use dbms_lob.compare for clob columns in oracle, such as in changeitem.
REM If you have custom fields with user names, you should also update those

update changegroup a set a.AUTHOR = (select b.NEW from unames b where b.OLD = a.AUTHOR)
where a.AUTHOR in (select c.old from unames c);

update columnlayout a set a.username = (select b.NEW from unames b where b.OLD = a.username)
where a.username in (select c.old from unames c);

update component a set a.lead = (select b.NEW from unames b where b.OLD = a.lead)
where a.lead in (select c.old from unames c);

update fileattachment a set a.author = (select b.NEW from unames b where b.OLD = a.author)
where a.author in (select c.old from unames c);

update jiraaction a set a.author = (select b.NEW from unames b where b.OLD = a.author)
where a.author in (select c.old from unames c);

update jiraaction a set a.updateauthor = (select b.NEW from unames b where b.OLD = a.updateauthor)
where a.updateauthor in (select c.old from unames c);

update jiraissue a set a.reporter = (select b.NEW from unames b where b.OLD = a.reporter)
where a.reporter in (select c.old from unames c);

update jiraissue a set a.assignee = (select b.NEW from unames b where b.OLD = a.assignee)
where a.assignee in (select c.old from unames c);

update membershipbase a set a.user_name = (select b.NEW from unames b where b.OLD = a.user_name)
where a.user_name in (select c.old from unames c);

update os_historystep a set a.caller = (select b.NEW from unames b where b.OLD = a.caller)
where a.caller in (select c.old from unames c);

update os_historystep a set a.owner = (select b.NEW from unames b where b.OLD = a.owner)
where a.owner in (select c.old from unames c);

update os_currentstep a set a.caller = (select b.NEW from unames b where b.OLD = a.caller)
where a.caller in (select c.old from unames c);

update os_currentstep a set a.owner = (select b.NEW from unames b where b.OLD = a.owner)
where a.owner in (select c.old from unames c);

update portalpage a set a.username = (select b.NEW from unames b where b.OLD = a.username)
where a.username in (select c.old from unames c);

update project a set a.lead = (select b.NEW from unames b where b.OLD = a.lead)
where a.lead in (select c.old from unames c);

update searchrequest a set a.authorname = (select b.NEW from unames b where b.OLD = a.authorname)
where a.authorname in (select c.old from unames c);

update searchrequest a set a.username = (select b.NEW from unames b where b.OLD = a.username)
where a.username in (select c.old from unames c);

update userassociation a set a.source_name = (select b.NEW from unames b where b.OLD = a.source_name)
where a.source_name in (select c.old from unames c);

update userbase a set a.username = (select b.NEW from unames b where b.OLD = a.username)
where a.username in (select c.old from unames c);

update schemepermissions a set a.perm_parameter=(select b.NEW from unames b where b.OLD = a.perm_parameter)
where a.perm_type='user' and a.perm_parameter in (select c.old from unames c);

update filtersubscription a set a.username=(select b.NEW from unames b where b.OLD = a.username)
where a.username in (select c.old from unames c);

update jiraworkflows a set a.creatorname=(select b.NEW from unames b where b.OLD = a.creatorname)
where a.creatorname in (select c.old from unames c);

Cheers,
Peter

@Atlassian: Would be great to have this in the web Interface.

update jiraworkflows x inner join usermigration u on
x.creatorname = u.oldusername
set x.creatorname = u.newusername;

i also find it more consistent to use the same syntax like on the official renaming-users on confluence here with oldusername/newusername instead of old/new.

but nonetheless, great work

I wish I would have found that confluence-link before I started. Would
have helped a bit

Peter

update changeitem a set a.oldvalue=(select b.NEW from unames b where b.OLD = a.creatorname) where field='assignee' and a.oldvalue in (select c.old from unames c);
update changeitem a set a.newvalue=(select b.NEW from unames b where b.OLD = a.creatorname) where field='assignee' and a.newvalue in (select c.old from unames c);

Daryl

Daryl

that will probably work for some other database, but not in Oracle, since the columns in changeitem are CLOBS (=large objects).

Something like this should work in oracle:

update changeitem set newvalue = (select to_clob(new) from unames where dbms_lob.compare(to_clob(old),newvalue) = 0)
where dbms_lob.substr(newvalue,100) in (select old from unames) and field = 'assignee'

(should also be made for the oldvalue clob and also for other field-types, like reporter etc)

Anyway, I did not update them, since they only contain history data.

Cheers,
Peter

single:

update projectroleactor set roletypeparameter = 'newname' where roletypeparameter='oldname' and roletype='atlassian-user-role-actor';

table-based:

update projectroleactor x inner join usermigration u on
x.roletypeparameter = u.oldusername
set x.roletypeparameter = u.newusername
where roletype='atlassian-user-role-actor';

Edit: As Project Roles were introduced by 3.7 i think i missed this chance since then (obviously as i had some old names in the table )

I did not restart JIRA after I renamed the user. Is there information cached and a restart would solve it? Or am I missing something?

I would rather not use the xml backup restore method for this. We have about 10000 issues with about 700 users around the world. JIRA regularly runs 60 days or more between restarts.

For completeness the mysql script template I used is reproduced here:

update jiraissue set reporter='newname' where reporter='oldname';
update jiraissue set assignee='newname' where assignee='oldname';
update jiraaction set AUTHOR='newname' where AUTHOR='oldname';
update jiraaction set UPDATEAUTHOR='newname' where UPDATEAUTHOR='oldname';
update changegroup set AUTHOR='newname' where AUTHOR='oldname';
update changeitem set OLDVALUE='newname' where OLDVALUE='oldname' and FIELD='assignee';
update changeitem set NEWVALUE='newname' where NEWVALUE='oldname' and FIELD='assignee';
update changeitem set OLDVALUE='newname' where OLDVALUE='oldname' and FIELD='reporter';
update changeitem set NEWVALUE='newname' where NEWVALUE='oldname' and FIELD='reporter';
update searchrequest set authorname='newname' where authorname='oldname';
update searchrequest set username='newname' where username='oldname';
update schemepermissions set perm_parameter='newname' where perm_parameter='oldname' and perm_type="user";
update searchrequest set authorname='newname' where authorname='oldname';
update membershipbase set USER_NAME='newname' where USER_NAME='oldname';
update OS_CURRENTSTEP set owner='newname' where owner='oldname';
update OS_CURRENTSTEP set caller='newname' where caller='oldname';
update OS_HISTORYSTEP set owner='newname' where owner='oldname';
update OS_HISTORYSTEP set caller='newname' where caller='oldname';
update fileattachment set author='newname' where author='oldname';
update filtersubscription set username='newname' where username='oldname';
update project set lead='newname' where lead='oldname';
update userbase set username='newname' where username='oldname';
update customfieldvalue set stringvalue='newname' where stringvalue='oldname';
update columnlayout set username='newname' where username='oldname';
update portalpage set username='newname' where username='oldname';
update component set LEAD='newname' where LEAD='oldname';
update jiraworkflows set creatorname='newname' where creatorname='oldname';
update userassociation set SOURCE_NAME='newname' where SOURCE_NAME='oldname';
update projectroleactor set roletypeparameter = 'newname' where roletypeparameter='oldname' and roletype='atlassian-user-role-actor';

While a restart may not be necessary a re-index definitely is necessary.

has anyone achieved a similar thing for confluence, as the user database for that also seems keyed to the username thus making it hard to reverse bad decisions for usernames.

thanks

• full export
• regex search/replaces in the entities.xml file
• full import

I found other tables with username (version: 3.11 - db:sql server):

update searchrequest
set reqcontent = convert(ntext,replace(convert(nvarchar(max),[reqcontent]),convert(nvarchar(max),u.oldusername),convert(nvarchar(max),u.newusername)))
from usermigration u 
where reqcontent like '%'+u.oldusername+'%';

update changeitem 
set OLDVALUE = cast(u.newusername as ntext)
from usermigration u 
where changeitem.field in ('assignee','reporter','Client validator')
and cast (changeitem.OLDVALUE as varchar(max)) = u.oldusername;

update changeitem
set NEWVALUE = cast(u.newusername as ntext)
from usermigration u
where changeitem.field in ('assignee','reporter','Client validator')
and cast (changeitem.NEWVALUE as varchar(max)) = u.oldusername;

update changeitem 
set oldstring = convert(ntext,replace(convert(nvarchar(max),oldstring),convert(nvarchar(max),u.oldusername),convert(nvarchar(max),u.newusername)))
from usermigration u 
where changeitem.field in ('Issue watcher(s)','Business contact','Request responsible','Action responsible(s)')
and cast (changeitem.oldstring as varchar(max)) like '%'+u.oldusername+'%';

update changeitem
set newstring = convert(ntext,replace(convert(nvarchar(max),newstring),convert(nvarchar(max),u.oldusername),convert(nvarchar(max),u.newusername)))
from usermigration u
where changeitem.field in ('Issue watcher(s)','Business contact','Request responsible','Action responsible(s)')
and convert(varchar(max),jira.changeitem.newstring) like '%'+u.oldusername+'%';

you need to pass them until no row is modify

regards, Julien

Has there been any official update as to if they plan to release this as an actual feature inside JIRA?

We need the ability to associate a new user with issues related to another user

This "might be" a workable solution to the change user name issue.

For example, say we have a user: Mary Smith
She disappears for two weeks, comes back with a tan, and a new name: Mary Jones.

I would like to:
1. "retire" her user name in Jira
2. create a new use account for her using her new name
3. bulk change any open issues from the old user to the new user
4. remove her old user account from the assignee list so new issues are assigned to her new id
All this we can do now.
This is where the magic has to happen...
5. somehow associate the old userid with the new one so:

• queries in filters and reports on her new name will also show items associated with her old name
• and vise-versa
  Just some more thoughts...
• users could see her old name on issues if that is what is stored in the database with that particular issue
• probably more than one association to a user should be possible (though cascading them from one to the next to the next is an option).

The reason that it has not yet been done:

• it would involve a complete change of the entity model for JIRA, which would make it almost impossible to maintain backward compatibility (something that we have done for the last 3.5 years, and which makes it easy to upgrade JIRA)

What definition of backwards compatibility are we using here?

My scenario is similar to one described earlier. A certain Jira installation I use requires email addresses as usernames, and username there is an email address that I now no longer use and would like to retire (it's my ISP email address which may go away altogether someday).

Confluence

I also like the suggestion above about just being able to move all references from one user to another user, it just needs to make sure it hits everything (worklogs, ...). Again, no restructuring required.

I just would prefer that
1) the script or process of changing a userID is owned by the Jira Team, so it doesn't get out of sync as the schema changes and
2) I could launch it as an administrative action when viewing a user

Thanks in advance.

(for me this is a bug and not an improvement)

With regards to your LDAP Jira integration & migration effort - we had the same problem - we had users already in Jira, before we integrated it with LDAP. I've written a script (PHP) that looks up that users email in our LDAP servers, then goes through and updates the Jira usernames according to their smAccountName logins - this worked well for me. Let me know if you need a hand with it.

Sherif

PS: I tried the search/replace solution, but my backupfile is just way too big for that and I calculated that it would take me 9 working days to do the migration (file opens and searches very slow...), in which the app would be offline...

I had to do a full migration of all user accounts because our management decided we'd go from the intuitive <first initial><last name> to cryptic employee # accounts. Using the free GUI tool "A.F.9 Replace some bytes", it was easy to make a mass text replace job on the XML with just a text file of the old and new usernames. It was 10000 times faster than using Windows Notepad. Hope this helps someone...

The Database-Dump in Confluence on the other hand is many times bigger (in our case 10x) and thats more of an issue, when it comes to a clean replacement as it is common to have usernames within a pages bodycontent. I think before using a self written script to make a text replace, use the self written script to do a database update

Thankful for a response from someone that can actually change this product to become the true enterprise product we payed for?

A useful related tool would be one that allows you to change ownership of stuff from one user to another. When we ran out of licenses on confluence or jira, I manually went through and changed ownership of all the items belonging to former members of staff to their manager, and was then able to delete the unwanted usernames.

Having to hit the database manually for such fundamentally important housework tasks is a disgrace to Atlassian.

update favouriteassociations set username=@NEWUSERNAME where username=@OLDUSERNAME;
update trustedapp set CREATED_BY=@NEWUSERNAME where CREATED_BY=@OLDUSERNAME;
update trustedapp set UPDATED_BY=@NEWUSERNAME where UPDATED_BY=@OLDUSERNAME;
update worklog set AUTHOR=@NEWUSERNAME where AUTHOR=@OLDUSERNAME;
update worklog set UPDATEAUTHOR=@NEWUSERNAME where UPDATEAUTHOR=@OLDUSERNAME;

Not sure if any of these fields are custom to plugins only we use so i included them anyway.

Once more, atlassian: Get a grip, take control and motivate us to keep paying for this "enterprise"-product.

The list of users is broken after modifying the tables userbase and membershipbase and I have absolutely no idea why...

UPDATE: already solved - the problem is not in index, it is because no database integrity - I update table userbase with a duplicate username, there is no warning or error message

I had to abandon this approach since it seems field containing the username mid-field was not updated (for instance a link to a confluence-article in the jira issue).

My solution so far has been sed-replacing database dumps and re-import them. On confluence this seemed to work out fine, but on jira it seems the user needs to be created before the database is converted (which makes little sense if all data is really stored in the database).

Will keep this updated as i break new ground.

Also, i am looking into doing the same conversion of crucible, has anyone managed to dump the HSQL to something clear-text that can be reimported after the same sed-replace treatment?

Your message will be read and, if needed, responded to on Friday,
May 29, 2009.

For Synchronicity related issues post an issue in the
"Data Managment / Revision Control" Category of EDA Help.

For UNIX support please post issues in the "Systems and Netowrking"
Category of EDA Help.

Jeff.

i'm not exactly sure why is it prioritized as Minor... - this is not a minor issue...

this can also become a night mare when LDAP Integration will finaly be Integrated into JIRA Properly.

Vote + 1...

Your message will be read and, if needed, responded to on Friday,
May 29, 2009.

For Synchronicity related issues post an issue in the
"Data Managment / Revision Control" Category of EDA Help.

For UNIX support please post issues in the "Systems and Netowrking"
Category of EDA Help.

Jeff.

I am going to try the sql update technique, reimporting a giant database that needs to have as close to 100% as possible uptime is simply not an option for me.

UPDATE: Also, running the query trick did not work. The username is updated everywhere in the database, but the admin screen, the user searcher, and individual issues still show the old username. Also, the user cannot log in.

I cant take a 15 minute outage in the middle of the day to rebuild the indexes either.

http://jira.atlassian.com/browse/JRA-1549?focusedCommentId=65655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_65655

Furthermore, suggesting that voting is ignored seems wrong. JIRA 3.13 resolved issues with 435, 409, and 177, and 131 votes (and others with plenty of votes). Looking at the popular issues list, I see a number scheduled for 4.0, including issues with 517 (the top voted!), 289, 173, and 148 votes (and others with plenty of votes).

You have every right to be frustrated. This issue is a pain. I'm a little surprised this was not targeted at JIRA 4.0, as that seems a natural time for such a major change. However, I don't think Atlassian is simply ignoring this issue. My guess is they have not considered this issue to be worth the effort required because there is a feasible workaround.

Second bullet point is "there is a work-around (although cludgy)". Work arounds are usually ment to be temporary until the developers fix the product. I don't know anyone that considers six years temporary. I have no problem using workarounds when they are necessary, but this seems like it should take no more than two minutes in the front end. Also, workarounds are usually unsupported. It would be nice to have an offical, supported way to rename a user. Although I have to say from my experience Atlassian support is excellent, and I almost never say that about any company's support group.

The third bullet point "first we have to move to 'atlassian-user', which Confluence have recently moved to, and has shown to have performance problems. Rather than have it affect two products, we are awaiting Confluence fixing the performance problems first. This is another feature we have been waiting on for quite some time.

AS far as voting goes, yes they have added some issues that have a high number of votes. However, so many other issues that seem trivial are being added to the roadmap while major issue's like this (Atlassian consider's this minor) are left on the back burner.

Also, this is not the only issue that seems like basic functionality that has been raised but ignored. There are many issues left untouched by atlassian that could provide a world of difference for many users. For most of these issues, the backward compatibility excuse is used. AS you stated Daniel, 4.0 is supposed to be a major change. What a great time to EOL previous versions and start fresh with an amazing product.

I like JIRA better than any other project management app I have used. However so many seemingly basic functions have been left out it that it gets beyond frustrating.

Again, thanks for responding. Atlassian, where are you???

Atlassian, please DO THE RIGHT THING and fix this "not so flashy" feature that every JIRA administrator longs for!

I really don't understand this position that changing the DB schema so that the user login wasn't the primary key of the users table (and accordingly a foreign key in other situations) is such a major drama, and would cause these perceived backwards compat issues. It'd just be a DB upgrade script - drop some constraints, add some columns to various tables for the new PK & FKs, populate said columns with appropriate data which maps the user name to the new keys, re-add the constraints - that would need to be run when the application is upgraded. Irrespective of what a mess the DB schema is, it's going to be a variation on that theme. It's not "no work", sure, but it's hardly rocket science.

Isn't the real reason for not dealing with this issue that is that it'd be work that you can't make any money on, and accordingly you don't feel like fixing it? I think that'd be fair enough, to be honest. If that's actually the case, then why not say it, and close the issue.

That said, whilst you perhaps can't make any money on it, you have definitely lost money through not fixing it. We stopped paying for our maintenance, and I have stopped recommending Jira on the basis of the treatment you give to this issue, and a couple of other ones being dealt with in the same way.

To answer Neal's question - when we started JIRA, we used OSUser, which gave us database portability / application server portability of user management. If the J2EE spec had contained user management, this would not have happened. Yes it was a mistake, but as I mentioned above, one that is not easily rectified.

Still, I agree with all the recent posts. Bite the bullet. Here's a typical scenario:

"Hey, Mr. JIRA Administrator, the VP of development has just gotten married and moved to California. Please change her username to match her new corporate account ID, and set her user preference to be the U.S. Pacific time zone. Thanks so much."
response: "Um, we can't change usernames, nor show local time zones".