Asked by Martin Hanke - Unable to rename a JIRA Local User (no option)

[William Crighton [CCC]]

Hi all,

we are running JIRA version 6.1.5 with an internal user directory. Unfortunately, there is no 'username' field in the 'Edit Profile' wizard. Are there any settings I have to maintain in order to be able to change the username?

[William Crighton [CCC] · Accepted solution]

Alright - well, this isn't a real 'answer' yet but it's trying to push back the black a little - hopefully it'll help us along.

Looking into the code it seems very....well, at least fairly, straight-forward. In the java jsp file that is loaded - atlassian-jira/secure/admin/user/views/editprofile.jsp there are the following checks:

<ww:if test="/showRenameUser == true">
<ww:if test="/inMultipleDirectories == true">
    <aui:component template="auimessage.jsp" theme="'aui'">
        <aui:param name="'messageType'">warning</aui:param>
        <aui:param name="'messageHtml'"><ww:text name="'admin.warnings.rename.user.exists.in.multiple'"/></aui:param>
    </aui:component>
</ww:if>

The 2 checks - /showRenameUser and /inMultipleDirectories are accessing code in the following class:

• com.atlassian.jira.web.action.admin.user.EditUser

/showRenameUser is returning the result of a call to routine - userManager.canRenameUser

/inMultipleDirectories is returning the result of a call to routine getUserState().isInMultipleDirectories

Dropping down another level we see that userManager.canRenameUser returns the result from 2 calls combined such that a failure in one is returned as a failure in both:

• userDirectoryAllowsRenameUser && isJaacsUnusedOrRenameAllowedAnyway:

userDirectoryAllowsRenameUser checks that the directory is of type INTERNAL or DELEGATING

jaacsUnusedOrRenameAllowedAnyway checks that

the jpm.xml option for jira.option.user.crowd.allow.rename is set to true (default value) OR

the user directory is external

----

SO - my first thought is to check the value of the jpm.xml flag JIRA_OPTION_USER_CROWD_ALLOW_RENAME - just open up (on JIRA StandAlone install) <jira>/atlassian-jira/WEB-INF/classes/jpm.xml and do a search for 'rename'.

[mlassau_atlassian]

Great detective work William. When JIRA is being used as a user server by another application like Confluence, then we need to be careful about whether that underlying application will handle us doing a rename. This is explained at https://confluence.atlassian.com/display/JIRA/Managing+Users#ManagingUsers-Changingausername under "Using a JIRA User Server for other applications" In fact, I think that that page is a little out of date as the default behaviour changed in JIRA 6.2: https://jdog.jira-dev.com/browse/JDEV-25724

[Arno Wolter]

I checked the jpm.xml on our server, and in fact the property is set to false:

<property>
            <key>jira.option.user.crowd.allow.rename</key>
            <name>Allow users to be renamed even when JIRA is acting as a Crowd server</name>
            <description>Controls whether or not the ability to rename a user is enabled when JIRA is configured to act as a Crowd server. This is disabled by default because other applications depending on JIRA's Crowd server implementation will misinterpret a renamed user as having been deleted and created anew.</description>
            <default-value>false</default-value>
            <type>boolean</type>
            <requires-restart>false</requires-restart>
            <admin-editable>false</admin-editable>
            <sysadmin-editable>false</sysadmin-editable>
</property>

How can I change these settings? Just change them in the file?

[William Crighton [CCC]]

Arno,

GREAT NEWS! That's so easy to change - it's just a text file (xml, but whatever) that you can modify (using vi or notepad depending on OS) while the server is running. The changes won't be read until the application is restarted.

To be safe the best way to go about this would be to have a staging or test system you can do a quick test with first. Up to you.

Open the file, search for 'rename', change the setting to 'true' (no quotes) and restart JIRA.

-wc

William Crighton

Capital City Consultants

[Arno Wolter]

Hey William,

the Jira documentation states that the jpm.xml should not be edited (upgrade reasons, see https://confluence.atlassian.com/display/JIRA/Advanced+JIRA+Configuration), so I will try to use jira-config.properties instead. After doing it, it still doesn't work. But of course it could be due to a wrong jira-config.properties. I will try to figure out whether the options in jira-config.properties have been taken over successfully.

[William Crighton [CCC]]

Arno,

Hmmmm...well, would you show me the line/s you added to the jira-config.properties file?

I'm going to play with it for a bit - I get tired of 'melding' the old version with the new version on every upgrade. however, I've been doing it that way for several years and I can guarentee you that it works - you just have to re-apply the changes every upgrade. If you modify the jira- config.properties file, located at the root of your jira.home directory, the changes will be mostly preserved across upgrades. I say mostly because from the way I read that page JIRA only looks in jira-config.properties for things it can't find in the database, so as they enable more of the config options (pulling them into the interface) you'll need to update your jira-config.properties file (just to say it no longer controls a particular setting) and then set the option in the interface. no biggie.

-wc

[Arno Wolter]

William,

I agree, of course you can also change the jpm.xml. I had to create the jira-config.properties file as it was not existing before. And then I added this line:

jira.option.user.crowd.allow.rename = true

In the logfile it showed the correctly changed property then.

-Arno

[William Crighton [CCC]]

And that is or is not working? Sorry, I couldn't follow from your previous comment that it still dosen't work and this one that says 'the logfile showed the correctly'

-wc

[Arno Wolter]

oh, sorry, it does work now. the startup log shows the correctly changed value of the property! Thanks for your help!

-Arno

[William Crighton [CCC]]

Again, great news Arno. Hopefully this'll help out other people.

If you'd be so kind as to vote up my 'not an answer' post which led to the fix I'd appreciate it. But regardless thanks for sticking with it and providing updates before I forgot about it.

Of course, if you ever want to evaluate a plugin of ours you are more than welcome to and I could probably talk to MGMT and get a promo code sent your way to decrease the cost. (just search for CCC in the marketplace).

Fun solving this problem, hoping that Martin Hanke is making out ok.

Will you be attending Summit in 8 days?

Cheers,

-wc

[Martin Hanke]

Hi all,

yes, it works! Actually, we did not even have to change any XML file. The setting was available under 'Administration'->'System'->'Advanced Settings'->'jira.option.user.crowd.allow.rename'

Thank you William for your great support!!!

Cheers,

Martin

[mlassau_atlassian]

Yep, the ability to change this through UI was added in JIRA 6.1.2 https://jira.atlassian.com/browse/JRA-35523 Furthermore in JIRA 6.2 the default value is changed from allow to disallow. This is because modern versions of Confluence can now detect the rename coming from JIRA.

[William Crighton [CCC]]

Arno,

Sry - this was dumb question - active flag has nothing to do with ability to rename user

-Are the users you are trying to change the names of deactivated in JIRA? If they are you'll need to set them as 'active' first (from what I understand)-

-wc

[William Crighton [CCC]]

Martin,

Ok, there might be something unsupported going on - let's just confirm a few things:

1) you mention a JIRA version and it's not the latest so I assumed you are not using OnDemand - please confirm

2) you referenced a user with the 'internal user directory' - can you confirm that the 5th column looks similar to the image below? (JIRA Internal Directory)

[William Crighton [CCC]]

My initial reply:

Martin,

I believe you need to navigate to Administration/User Management/<your user - click their name> and then click the 'Actions' button on the right and select 'edit profile' - you should then see a 3 field model dialog with the first field being their editable user name.

you should also check our these excellent posts on the same topic:

• https://answers.atlassian.com/questions/259040/how-do-i-edit-a-user-name
• https://answers.atlassian.com/questions/33254/how-can-i-change-a-user-s-user_name

-wc

[William Crighton [CCC]]

His response:

Hi William, thx for your quick reply. Well, I have tried that already. Please have a look at the attached screenshot. There is no 3rd field available...

[Martin Hanke]

Hi Arno, unforutnately not yet. I will post the solution as soon as possible.

[Martin Hanke]

Hi William,

1) Yes, we are running JIRA on our own server.

2) Yes, it looks exactly as shown in your screenshot

[William Crighton [CCC]]

Couple more questions - sorry it's not as rapid as I'm sure you want, if you want to email me direct my address isn't hard to find. I'm interested in figuring out what's wrong and then posting the solution here - there should be no voodoo in software - so here's my q's:

1) do you have more than one user directory (i.e. an internal one, one for crowd, one for legacy external ldap not hooked to crowd, etc)?

2) does the user in question have an account in one of the external directories as well?

Here's what I'm thinking - the user rename functionality does work, and it works pretty damn well in providing a mechanism for migrating user names from a legacy system (where users had 'non standard' names) to one where all the names are 'standardized'. However, it's not w/o faults here an there and there are some tripping points to be aware of - the main one being if the user exists in an external system you need to disconnect the external system, rename the local user (which renames all of the objects they 'own', reconnect the external system and move on...that was probably a bad example, we used it when there were local users with 'legacy' names and an external ldap with standardized names - we disconnected ldap, renamed the local users to match ldap, then reconnected ldap and the users could log in with their new names and all of their issues were owned properly, history updated, etc... just like the brochure.

-wc

[William Crighton [CCC]]

discussion continuing via email - if anyone has any bright ideas / thoughts, or even dull, tarnished ones that are spot on, please Share!

Otherwise keep it down and we'll post the solution (along with what's going wrong in greater detail) when it sorts itself out.

-wc

[Arno Wolter]

So, almost one month later, is there a solution? We are encountering the same issue, running on v6.0.4