A workaround is to use the browser's developer tools. In Chrome:
Genius in its awesome simplicity. THANK YOU
Well.. so I wanted to to and audit and change full name of couple of employees because in full name "login" was put.
Now i can;t do that as i would mean i have to delete their accounts and create new ones- this would destroy everything for that user
So why we can;t do that?
Now, you can not define a full name for user at all. It's been removed from the "create new user" flow, plus it's not possible to edit.
Must be a bug. I cannot imagine this is intended.
Tha new Managed accounts are now under the domain name in the admin site.
one you get the manage domain then there is the manage account that will allow you to change the username (Name) of the user
I think you mean this: https://confluence.atlassian.com/cloud/organization-administration-938859734.html.
But that only works in the rare case (I think) that all your users share a domain in their email-address that is within a domain you own (doesn't work with gmail accounts, or if you service a Jira instance for your customers, or if your customers like to use different domains because they like to use their own emailadresses).
It's quite odd that I cannot create new users anymore (like Sam Hall shows above) and that I cannot control the users I have created. Imo a limitation that wasn't necessary. It has nothing to do with security, in fact, it is kind to new users if you can create them with a good display name.
This is what worked for me, since (as you might have noticed) Atlassian moved to a new IAM system. Let the user log in to https://id.atlassian.com/
Change the full name to your desire.
Then wait for eventual consistency. It took a few minutes for the update to percolate.
The problem with this approach is, however, the part where you say "let the user log on". That means you have to explain to each user how to do this, instead of being kind and doing it for them.
Do this at your own peril...
Atlassian are enforcing this restriction only client-side. Using your browsers developer tools, you can remove the
disabled attribute from the input field.
You can now edit the Full Name and successfully save it.
This seemed to do it. I originally had my initials as Full Name in Atlassian account, and real full name in Cloud account. When they merged the accounts, they changed the initials to both accounts, which my cowrkers did not appreciate. So I tried to change the Full Name for the Atlassian account, which never (2-3 weeks) relayed to the Cloud side. This saved my day
As administrator I REALLY need to be able to control the display name for new users. Some of our users are external - we identify them by adding the client name to the back of the display name
WHY DID THIS CHANGE - it was perfectly fine the old way
this is very disappointing / not at all user friendly / obvious
We got the same problem. Some long time ago created accounts are in different naming convention, and i have no option to normialize that. I don't want to deletecreate new!!
The way I have seen this handled in the past is to separate the functions
i.e. keep the bit that is needed for single sign on separate / in the system admin function side
and have a "display" name available at the application level
the display name is linked to the user id but can be updated / edited as needed to provide some level of application specific naming consistency. I would go so far as to say the display name could only be updated by an administrator - not but the user themselves
I think I originally logged this issue - have given up in expecting a reasonable response (or even understanding as to why this is a problem for some of us) and as suspected generally see a big mix of ids in reports. from our perspective (we are small users but ...) - it is very hard to know for sure if someone is internal or external (a client) by just looking at the name. We generally can tell by the project but that should not be the case
my 2 cents
The User them self can update it in there profile settings --> Atlassian account. As an Admin you can do it with logging in as the user, but you might need to change their password.
To change the full name, you need to be logged in as that user. Once logged in:
1. Click on the user icon and select 'Profile'.
2. On the profile page, click 'Edit Profile'
3. Next to the full name field, select the link for 'Manage in Atlassian Account.'
On the next form you can edit the full name for the current user. Enter the name, Save it, and it may take a few minutes for the change to propagate through the system. A browser refresh may also help.
As an administrator I can edit my own name following the above steps, but a user that is not an administrator cannot do this for their own profile and administrator with global permissions is not able to edit their name for them even when impersonating them.
Okay so I figured out the solution to this. When I had the user that misspelled their name login to their account and go to their profile, the hyperlink for the Atlassian account was not there like it was for me (as pictured). So I had the user go to https://id.atlassian.com/login to login and go to "Account settings" and from there the user was able to edit their full name and save their changes. The user then logged out of Jira Cloud and logged back in and saw that the changes reflected in their Jira Profile. Hope this helps others!
Signing on as a user is not an acceptable response. First of all I would consider this to be a huge security breach especially if I change data that the user technically should "own". The sign on option is nice to check what the user is seeing versus what I might see as admin but I would never change data on what is effectively their view of life.
Applications should have names that are for display only - i.e. stand independent from any other application security.
Emails / sign on user ids can be totally separate entries that remain uneditable.
Display names are exactly what they sound like - they appear on reports / screens only and they can be managed by the user OR by the application administrator
I think the workaround / hack suggested by Jakob is out of date now (or at least doesn't work permanently).
Getting the user to change themselves (along the lines suggested by Joe Lehn) should work though, but I guess that is not what you are after.
For what it is worth, there is a suggestion on Atlassian's public issue tracker about this: https://jira.atlassian.com/browse/ID-6415
Atlassian have responded on comments of that (for example on 11 Jul 2017). That's possibly the best one to watch/vote/comment to look out for updates.
Hopefully someone from Atlassian will come on here and comment.
I tried the Browser Tools method and my cloud instance seemed to silently ignore the changed input. I think Atl. must have fixed the server-side code since the field workaround was, in essence, a security leak.
This should be fixed. I can't run after everyone who only enters the first name when signing in.
Atlassian, why do you change thinks that work? I don't get it.
- I can't delete rooms in Stride.
- The UI of Jira is far less intuitive than before and I have to explain everyone in our company where they can find their stuff
- And now I have to run after everyone if they don't enter their names correctly
This is annoying...
Doesn't matter if it's cloud or not, if I am the admin of the licensed Jira I should be able to change any name to Peanut Butter Jelly and update their pictures to Mickey Mouse. The account does not belong to the user, it belongs to the company that paid for it and I am the administrator of it. The user only USES the account, the PC, the resources. He does not own them, he does not Pass GO, does not collect 200$.
No. You are wrong.
As a user here in community, you are using your Atlassian account. Now imagine that you are using a Cloud Jira for your work as well.
You're saying that you would be happy for me, as an admin here but without any access to your Jira, to change your name on your Jira to "Gabriel Does Not Understand This System Baciu"?
If you want to own the accounts, you will need to swap Cloud to using accounts that you own and provide. This will separate them from other Atlassian systems, and you'll need to provision them yourself, with g-suite or your own SAML solution.
What you said actually makes sense, and now I understand. They own their account and the company owns the platform, which can be one of many they use on their account.
Turns out though, that if the user account is made through a managed domain, that Full Name CAN be changed by the admin :)
That does make some sense.
Still, what does not make sense is that when I am inviting the user to my cloud-based JIRA, and that user does not have an existing Atlassian cloud account, Atlassian cloud does not allow me to set the proper full name. Nor does it do what would make sense, which is wait for the user to confirm they want the account and set up their profile, including their full name, during the sign-up process.
Rather, it creates the user right away (which means company admins can create Atlassian accounts for all sorts of people, which seems like a security issue, or at the very least something that can cause significant confusion), and assigns them a full name which is simply nonsense e.g. full name "Bob Bob" for user "Bob Smith". Said company admin then has to tell each user to go and edit their own profile manually -- and most users couldn't care less about this so they just leave it.
We're not asking to change the user names everywhere. We're asking to change them in Cloud areas we are admins of.
There's a much simpler solution that Atlassian seems to be ignoring in favor of the ridiculously over-engineered with "Organizations"; there should just be a global name (the Atlassian ID level) and an optional name for each separate product domain. It's that simple.
It is infuriating to see users put their names as "Travel2018" (that's clearly their password ffs) and while JIRA is an otherwise great product, it's stupid changes like this that make the admins look unprofessional, feel powerless, and personally leaves me looking forward to the day we move over to Workfront.
An admin should have full access to change display names for accounts that they administer. How do I police a user that posts an incomplete or even inappropriate display name? Delete them is the only option?! That's just crazy.
They do. But the accounts are not yours, they belong to the user (And Atlassian). It would be illegal to let you change my name on my account because you would affect the use of it in all the systems you do NOT have any rights to change.
I would say that is a massive Atlassian design flaw then, because if my organization is granting a user access to our JIRA information, and we demand that all users supply their full first and last name instead of just one or the other, then we have a problem we cannot fix.
In my opinion and my employers, we do own that account access, and if we choose to demand that user to supply specific information in their account and have no way to enforce it, then that's a product shortcoming.
So how does Atlassian plan to address that?
No, your opinion does not fit with the reality of it here. You do NOT own the account. You've invited it into your system.
@Betty Quaywrote up a decent approach to fixing it in between my comments, although it suffers the weakness that the user can start seeing different names in different systems, which is counter-intuitive and likely to cause problems (especially for someone like me who has access to dozens of Cloud systems).
However, as far as I can tell, Atlassian have no plans to change this.
I understand your thinking here, but the approach does not fit with the business need of THIS particular customer.
My company decided upon JIRA Cloud so that we could sidestep the management of the software. The users "invited" to our system are all brand new. They've never existed in the Atlassian database before (I mean, how could they? We just hired the employee and gave them firstname.lastname@example.org email address), and that's the address they are required to use.
The approach is ass-backwards to me, and solves a problem for Atlassian, not the customer. I don't see how my opinion doesn't fit with reality here.
Nic, I understand your explanation, but in our usage, the account is useless to the user without our company granting permissions into our information. In that context, my challenge is "Why is it more important for the user to own the account rather than the administrator?".
Why make this design decision? I can't imagine that our usage is unique across all JIRA instances (and by the length of this thread and list of confused users, I'm not alone in questioning it).
This seems like a design choice that makes things easy for Atlassian, and hard for the paying customer.
It's because Atlassian accounts are used to access many Atlassian things, many of which are owned by different people. We're both using one now to talk here.
It's the same as other identity providers - google, facebook and steam accounts are other examples - the accounts belong to the user and allow access to different things owned by different people.
Atlassian (and their seeming representative here Nic) are stuck on a certain way of thinking isn't aligned with how people actually use their system. I love Nic's use of language, repeated umpteem times on this thread to many different people:
"No, you're wrong."
"You're opinion does not match reality"
Apparently, everyone on this thread is just wrong, and no more needs be said :-)
I wouldn't place much stock in them changing anything on their end. You'll have to do what most of us have done which is to live with this dumb situation, or use another product (like Atlassian on-premises or a sane cloud product).
Can I set the names of users in my Google Apps account? Yes, of course I can. I'm not adding random identities of random people to my cloud configuration -- I'm adding my own damn users.
I'm not an Atlassian representative, and if you read the comments properly, you'll see that I'm not advocating this particular approach for them either. Where I'm telling people they are wrong, it's about how it currently works, not how it should.
Personally, I don't actually care too strongly. I understand some people want to dictate their user naming conventions.
As an end user, I prefer that I can choose to be called what I like, rather than have an admin dictate something I don't, and prefer that when I'm using many systems, my display name remains what I like.
If you really want to dictate people's names to them, then the answer is simple - move to an identity system you do own (or wait for Atlassian to change Atlassian ID to annoy your users, which is unlikely). Cloud allows for SAML and Google accounts as well as Atlassian IDs now. You can use pretty much anything for Server versions too.
Nic, if you're not an Atlassian representative and you admittedly "don't actually care too strongly", then why are you responding? I'm pretty sure I speak for us all when I say that your responses, and more specifically your combative and insulting tone, are just ticking everyone off more. No one expects that tone from someone with the badge "Community Champion". It certainly doesn't make me want to shell out thousands of dollars a year to Atlassian if Atlassian deems this as acceptable.
Getting back on point though, we all understand that this is Atlassian's ID system. The issue we have is that once a user enters a product we administer, we don't want the user to name themselves "Travel2018" (this is one of my user's passwords that they set as their name ffs) or any random thing. It makes us, as administrators, look like idiots and quite frankly, I'm perfectly capable of making myself look like an idiot without Atlassian's help.
The simple solution, mentioned by both myself and now Betty Quay, is just to have an optional Display Name that both the user and the administrator can modify for each product instance. Atlassian has even come back towards this ... albeit in the most complex possible way with "Organizations".
Really we're just asking Atlassian to give us back an optional power we previously had, while still keeping their ID system. That seems like a win for everyone, but I can't wait to hear you berate me that I'm wrong.
Because I am trying to help. I've had a lot of help from people in this community and I like to put something back.
Is it better that we leave someone flailing and vastly misunderstanding how it works, and not grasping that it is not going to work the way they might think it is, or would it be better to engage, ask and discuss?
I'll take the "combative" tone comment - yes, I do get angry and then post in grumpiness. When people don't read the previous conversation. When people keep banging on that their mistaken beliefs are right. When people don't get it. When they ignore what is being said, that's by far the worst one.
But I very rarely insult, and when I do, it's always, always, done when the other person insulted me first, and they've caught me in a bad mood as well (although I do take "not listening" as an insult)
And, you've fallen into the "When people don't bother to read the previous conversation" category - see my earlier comment about Betty's answer.
You say you're trying to help, but you're insinuating that we're not reading previous comments, and therefore don't understand the issue. You state that our opinion does not match reality. For someone wearing the "Community Champion" moniker, you're doing a terrible job making people feel like part of a community.
To be clear Nic, I TOTALLY understand how it works. So does everyone else in this thread. We just disagree that this is the right approach for us (the customer). You can take a stand that we're incorrect and try to deflect our dissatisfaction of the product, but our comments are not meant for you. It's for Atlassian. So please, do us a favor and help. Be quiet.
Atlassian, I'd love to hear an official response on this complaint from multiple customers. One from a real company representative and not a community fanboy. Can you help us understand why you took this ability away from us, and what your plans are to allow companies to administer their own instances of your products?
Use case #164641:
I just had a user come to me in a panic and state that they accidentally posted their password as their display name. Since they are not familiar with Atlassian ID, he couldn't find his profile page to change it himself. He asked me to do it.
The only help I could provide was to delete his account and have him start over.
The good news is that there's also a bug in Atlassian products so that any content created by a user with the same email address as before will automatically gain ownership over that previous user's content, so he didn't lose anything. That little gem has caused trouble for us in other ways though, like when jsmith leaves the company and we get a new jsmith that inherits the old email address (and therefore also inherits content) from the previous user. Good times...
Atlassian introduced the concept of Organizations to allow users to modify the details of cloud users. The catch is that the user's domain (e.g. @domain.com) must be verified with Atlassian as being owned by the administrator. It's not 100% what we're asking for, but it's something at least.
Domain verification (see "Verify a domain" section)
Assuming you mean user accounts, you should be able to rename a user in the user management section (which isn't really in JIRA technically)
I cannot change the Full name in the admin section or logging in as the user...when I log in as the user, the system prompts me to change MY full name on my account.
Editing active users is only partly possible.
AFAIK you could set the user as inactive, log in as admin, edit the now inactive user from the JIRA Admin UserBrowser, change the Full Name, and re-activate the user.
Same issue here. Unable to do anything on the Administrator side, but the user is unable to edit it themselves in Atlassian Profile. I'm wondering if this is a problem with Internet Explorer, which is unfortuantely the enforced browser in many organisations? I can do it in Chrome.
Hi Atlassian community, My name is Max and I work on the product integration team at Atlassian. I am pleased to announce the early access program for the Jira Cloud add-in for Outlook. This add-in...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events