I hear the frustrations, and have lived with many of them for a long while. The use of a group name instead of a unique id was a mistake right at the start and I wish it had been fixed at the same time that changing user names was added. Perhaps one day it will be, but in the Cloud, unlikely Data Center. I think it's time to close this as Won't Fix. 

p.s. As of January 2025 Atlassian has not been purchased and one of the founders remains. 

We have just moved out of Jira, mainly for the continuous cost increase and an internal competition in our company with ServiceNow (which is not as good as Jira from dev UX and customization perspective). But i can totally relate to what you said. I guess technical debt won't be handled better now that Atlassian has been purchased and initial founders are gone...

We still use Confluence, but also considering moving. We're starting to look into Notion, but it's more expensive than Confluence...

Solutions to generate static web pages from markdown or code, such as Github pages can be a good and unexpensive option for developers. Or opensource CMS / wiki.

PS for Atlassian support: as this issue is likely not going to be fixed, can we rename this thread "Anger for Atlassian, how to quit?"

1e260c3d59e9 we have found great success and cost savings with Microsoft DevOps Boards for Jira replacement. It's also practically free for most users that just need read-only or simple task management. Far more robust support for Agile, no need for the bolt-on Plans which I have always hated. Github Intergration actually works properly too. Good API support to fill in any automation gaps.

On the Confluence side, we moved to Confluence Cloud, we are happy enough with it except for its cost. We keep looking at alternatives, but they are all expensive too. My issues with Jira are foundational to its architecture, while if I had the Infinity Gauntlet I would snap my fingers and remove all Java-based apps from this world, Confluence for the most part is worth saving. It has administrative tech debt for sure, but it’s also truly the best product in its vertical, the same definitely cannot be said for Jira. 

Labels: TBC admin-at-scale affects-cloud affects-server jira_support_feature_request_emea jw-platform pse-request spam

If anything I feel special knowing that this is the ONLY issue that has label "spam"(~April 2023).
I wonder what that does and/or implies.

Someone perhaps cloned this one into JRASERVER-72769 by mistake?
Personally I can't say issue type suggestion sounds right, on the other hand Jira likely never had the feature so it depends on perspective.

//Tomas

Hi Eric,
I totally agree with U. The Licenses, the Users, the Permissions are horrible to administer on Atlassian products. Such a big potential wasted. I would be interest to know what platform you are migrating to? I also start to look at this but I want something similar to Jira/Confluence with capabilities like ScriptRunner offers (in platform dev), workflows, issuetypes creation, with established extensions market, etc. I would also love to have better control over particular "issues" as Jira's per project granularity for all permissions and Issue level security is not enough. You could say I am looking for Jira+Confluence on prem but better. 
Cheers!

P.S. Geographically displaced disaster recovery direct support would be also welcome. Well, I think I am getting dreamy... 

Guys I am totally with you. Especially every year price increase for nothing. But I am not sure, if there is somebody watching this issue because of "spam" label. You should contact Atlassian sales directly to express your feelings. 

8f4f3c407f2b: Just for clarity: What do you mean by "Service now seems to be a way better option for us, [...]"?

98aa6e9bc70b  I totally feel for you mate. 
Even though I personally enjoy the product, its those stupid limitations that push you to check other vendors. Also the continuous increase on prices and limited updates on DC, create the need to check other providers.
We have been using Jira for over a decade now and we seriously consider moving to another platform instead of migrating to cloud. 
Service now seems to be a way better option for us, all things considered.   

This has been open since 2003. The idea that you don't use object GUIDs to store permissions is mind-blowing for 2003, let alone 20+ years later. I can respect how much work it would be to do this right, but I just wanted to take a jab at you for a moment. Why take a jab? Because your decades of tech debt on stuff like this burdens me, the admin. It has for so many years. It’s not just this foundational mistake; it’s all of them. Your foundation is trash, and you have never taken the time to fix it. Moving to the cloud hasn’t made things much better, in many ways worse given the lack of quality API access. At least on-prem, I can edit the db directly to work around your tech debt. 

 I don’t know who needs to hear this at Atlassian, but stuff like this… stuff like this is why I, as the admin of all things Atlassian, am begging my developers to move onto other platforms. I truly hate having to admin your platforms. So many things just like this, ignored and not fixed because the end users don't see it. Well, I see you, and what you’re not doing, it will cost you my company’s continued spends. Each year, I get a few more Jira projects over to other platforms. Once we are off, we will never be back, and it’s because of stuff like this.

we would have to make fundamental, breaking changes, which would probably need a new platform release

Yes, that is what Major version release notes are for. I don't see a problem there.

How many of those major releases we had while this is open?

Did Atlassian managed to EOL Jira Server in meantime as well?

//Tomas

...to solve the problem of renaming groups in Jira we would have to make fundamental, breaking changes, which would probably need a new platform release

With Jira 10, you've just release a new platform release. Unfortunately, this feature wasn't taken into account. Though, ID-6677 has been deployed half a year ago solving this issue for all cloud products!

@Wonjun Well, that depends on where you are located. In my country, it has already been in rehab. Twice.  

For those who are interested, there is a Rename Group in Jira app on Atlassian Marketplace.

This one is old enough to drink alcohol.

Happy 21st Birthday

Will 2024 be the year this gets implemented? 

+1

Ouch! CWD-4763 is still in Long Term Backlog

Is there any update on this issue after 20 years?

It is really annoying that group renaming in standard ways is not possible!

We are currently using the Kantega SSO Enterprise app with which we can provision AAD groups to Jira.

This works really good - if there are bugs the app support tries to fix this as soon as possible. But we cannot rename the Azure group because then it generates provisioning error because renaming in Jira is not possible.

So please after 20 years and about 2500 votes enable group renaming in standard Jira.

We had a similar requirement from a customer and done the feasibility study.

1. While it may be possible to update the group name via the SQL on the known tables, there are risks of breaking 3rd party apps which are referencing the group names.
2. Another challenge is group names from the Active Directory server which cannot be renamed.
    

It will be a scary scenario with a corrupted database. 
Hence, we came up with an alternative solution which is safer - to allow admins to define alias for user groups in Jira.

The benefits are

• Group names can be business friendly and in context (e.g. approvers vs HR_PROJECT_ACQUISITION_REQ_APPROVERS_GRP)
• It is easier for Jira admins to do group administration
• A group can have different alias for different projects using custom field context
• The underlying group name is still used for permission, issue security and notification schemes
• The group picker custom field will display the configured alias to the user in the issue screens when defined 

The Group Alias Picker is available on Jira Data Center. The brochure under the Gallery section 

We welcome any suggestions to improve it.

Hope this will come soon!!!

Based on

https://community.atlassian.com/t5/Atlassian-Access-articles/Org-admins-can-now-rename-groups-in-cloud/ba-p/2276321

and

https://jira.atlassian.com/browse/ID-8092

looks like Cloud users needed to wait only 3 months.

Apparently, it is possible. Just a bit of will is required, but, yes, it can be done in less than 20 years!!!

So sad to be a second-grade customer.

Any update on this? 

0b54ff294168 There already are two CWD tickets in the Issue links section.

> Like the fact that Confluence documentation says that Global Permissions and system administration separation is possible when it's not.
How do you mean, system administrators and administrators see the same options?

This thing has it's root in crowd has it not?

I might be wrong, but for user mgmt Jira and Confluence uses embedded crowd.

So first Crowd has to have it, then Jira can sort out rest of relationships.

.
Atlassian could very well change status for all these issues on 1st April....

Like the fact that Confluence documentation says that Global Permissions and system administration separation is possible when it's not.

@Piotr - common, there is nothing like merge of codebase. In fact, Atlassian is going totally different way. Cloud and DC are totally different products right now, developed by totally independent teams. The only thing those product have in common is name. That was one my proposal to Cloud Jira. They should rebrand it to some other name, as it is not a "fullsize" Jira nomore. 

@jeff Are you saying we won't be able to take this bug report for its first drink in the US? 😢

If Atlassian merged the codebases of Cloud & Data Center, the advantage would be mutual: they would spend less time troubleshooting, coding & deciding which features belong where; we would get all deployed features regardless of the environment. Unfortunately, this doesn't seem to be their plan...

"Gregory, you are right. This is exactly how it will be for Amazon, Facebook, Apple, Google, Microsoft, Atlassian, etc. But what is the problem? The earth continues to turn and we all continue to breathe until our time comes."

So what you're saying is it is terrible everywhere. you are just a number on a spreadsheet, nobody cares, resign yourself to an inferior experience. Got it. 

Since they seem to have fixed it in the cloud version, the issue no longer seems 'unsolvable' and there is not many legitimate reasons not to fix it here. If they don't fix it soon, it just looks like they are trying to leverage bugs as a way to force people to upgrade....

@Antreas Solou you are a boundless optimist.

Happy belated birthday to the simplest, yet not available, feature of Jira that is causing us nightmares
Lets hope this is the last year

Gregory, you are right. This is exactly how it will be for Amazon, Facebook, Apple, Google, Microsoft, Atlassian, etc. But what is the problem? The earth continues to turn and we all continue to breathe until our time comes.

Happy belated 20th birthday to my favorite bug! I'm glad to see you are FINALLY getting the attention you deserve, but I will miss you a little when I don't get the emails asking for updates.

I'm honestly a little sad that we might not get to see your 21st birthday....

"And in some cases, the cost of fixing such deficits simply exceeds the value of the software itself. Then any serious entrepreneur is forced to forego fixing these deficits. And only illusionists believe that these deficits must be remedied anyway."

That line of thinking justifies what we are seeing here where they don't bother to fix anything. 

I've seen this happen on many SaaS packages. Users will ask for commonsense feature that you wonder why the devs didn't think of it in the first place and they're told sorry, because of architecture we can't do this. 

But you know what? Inevitably, someone else will come along and solve the problem with a competing product that eats the other company's lunch. 

The correct answer is not that the problem is insoluble but that this organization is incapable of arriving at the solution, for reasons. 

That pretty much seems to be the software company lifecycle. Brash, young punk hits the scene and blows everyone away with the new hotness. Explosive growth of features and users, eventually matures and innovation slows. Becomes encrusted with bureaucracy and excessive layers of management. Revenues growth stalls and management's bright idea is to try soaking the existing customers for more money. Customers put up with it for a while because of vendor lock-in until such point they feel the pain of leaving is less than the pain of staying. Likely they'll be peeled away with some new brash, young punk comes along. Management panics as customer base dwindles at rapid rate, tries more stunts to retain them which only accelerates departures. Ultimately bought out by some other company, maybe even that new brash, young punk who is easing into his own incumbency. And in turn he will grow stale and inflexible and be deposed. it's the circle of life! ♫

Renaming groups via direct SQL is an error prone process - specially when we need to deal with so many add-on apps & integrated Atlassian eco-system (Crowd, JIRA, Confluence, Bitbucket, Bamboo) + changing world. It's not a smooth ride on quality aspect

if an enterprise customer investing heavily on data center products (high availability) they why he should face scheduled outage pain. It is not about convincing end-users or leadership for scheduled outage. Instead it is about what make sense or not make sense

Scheduled outage & quality issues are the big concerns

Gavan, I don't think this argument holds water. There MUST be maintenance windows for any software that is operated. And with well written "stored procedures" downtime can be reduced to a few minutes.

I rather think that the stakeholders have a problem with the maintenance windows not being accepted. It's easier to complain about Atlassian than to tell your boss that he can't have something the way he wants it.

Rolf - I am less concerned about that I need to write DB SQL's to overcome this feature limitation. Instead, I am more concerned about the scheduled outage (instance unavailability) needed for group rename. It might be less concerning for small Jira site but it is big concerning for large Atlassian installations. Atlassian feature & bug fixing policy is Atlassian friendly / not customer friendly. We can look this enhancement - pending for 20 years, too may votes, huge impact to the large Atlassian installations - nothing is helping to prioritise this issue

Gavad, these are big words. And unfortunately, these big words often speak the language of excessive hubris.

All software has architectural deficits. Even Docker and Kubenetes have such deficits. They are an implicit part of software development.

And in some cases, the cost of fixing such deficits simply exceeds the value of the software itself. Then any serious entrepreneur is forced to forego fixing these deficits. And only illusionists believe that these deficits must be remedied anyway.

In such cases, I have always gone the way of writing 'stored procedures' and testing them sufficiently to achieve the desired result. This is tedious but for me the only sensible way.

Maybe you all did not recognize what happened in the last decade... Atlassian went to stock market in 2015. The worst thing that could have happened to this product. What is the purpose #1 of being at stock market? Making money! How you best make money? You don't develop on-premise products, but strengthen the addon-platform, so 3rd party vendors can develop what the tool needs and has not implemented, as the "market regulates it self". With this strategy, there will be potentially more addons available. More Addons means more licenses where Atlassian can earn money with + the high license costs of Server/DC. What is the consequece? Atlassian has no interest to invest time and money to improve their product (as it is a stable and good product) that is the start of the end... If you don't like it go to the Cloud, because it is better and has the newest features. That is what Atlassian is basically targeting. So if they would improve the on-premise application, there would be less reasons why going into Atlassian Cloud. And why is the Cloud so important to Atlassian? Because they controll the Admin knowhow and don't need to give it away to customers that potentially solve their problems on their own. So you pay Atlassian for the administration in the background. Otherwise if you still want to have your own admins, you nowadays have to pay for their basic tranining in tha Atlassian university... Atlassian wants just your best - your money.

Summary: On-premise customers pay more and get less.

Atlassian will only re-think their strategy when customers are leaving and start using other tools... but then it is probably too late, as usual.

As far as I experienced via manual group renaming via direct DB SQL's, Jira is having design issue from the early age  - not using group DB id in several referenced locations. It is become more complicated in integrated Atlassian ecosystem where groups data spread via Crowd integration and dependent Atlassian SDK add-ons. All these design issues/ complexity translate to the big effort / investment for delivering this feature

Every year, I have to deal 2 to 3 big migrations and I struggle for this feature limitation. As this is a product design issue, top migration add-ons (i..e CMJ, PCJ etc.) also not able to deliver this 

In Germany it is already an alcoholic since two years.

The next time I ever see one of these long, outstanding tickets closed it'll be the first. Ticket is 20 years old now. Next year it'll be old enough to drink. 

They managed to switch to IDs for users >10 years back too. It's just a nightmare if you clean up groups to find all filters, filter visibilities etc. etc. using the old group name and update all.

d7fdaff0f02d Basically they can do, by creating a new group, get the users of the old one and assign all of them to the new group and adapt the settings to switch the group. Basically you can all do that with the API. And as long as they are just using the group to license the users for the application, respectively to access and use it (as I guess Atlassian will not pay themselve for licenses) there is no big deal, is it?
The main issue Atlassian has with this request is, the groups have no ID in the directory. So it is not just renaming the group and all other tables in the database are referencing to the ID. It references to the group name. So if you change it, you have to change it wherever it is referenced. I don't see how this is possible without leading to some data corruption.

Somewhere in an internal Atlassian Jira instance...a dev is assigned a task with Summary ~ "Rename jira-servicedesk-users group to jira-servicemanagement-users to complete rebranding"

Having watched this issue fester, I take some solace in knowing that Atlassian hasn't completely rebranded their product because it isn't simple to rename a group.

just make it possible! a lot of people needs this feature and you just delay.

its been 19 years of creating this ticket and more than 2300 votes and still nothing.

In reply to recent comments, don't get me wrong, I am not supporting Atlassian's position. I'm just explaining why they think it's not a trivial change. If they hadn't keyed on the ID in the first place it likely would have been. Although I don't understand how they can claim this is so complicated while a plugin developer can do it. Over 2,000 votes from an issue created in 2003 (January if you look at JRASERVER-1132) ... makes one wonder.

I can only agree with Mark, Daniel, Neil.

"This is a breaking change....."
cought, I'm sorry I'm just allergic to bs.
Now seriously, isn't breaking change something Major release of the product is for? Isn't that what you use it for?

Secondly, why is Atlassian not really specific about their process for "fixing" bugs/new features(excluding security impact that is)?
This one has >2k votes and at least half of it watchers(I guess the rest lost their hope), how can you still mark it as "UNDER CONSIDERATION" ?
Do you really expect our teams to ask everyone from our user-tier - and I mean every user of >40k users(just in our case) to create account here and put a vote?
Are you serious right now?

Are you between lines asking for someone else(who lost patience and has access to code as per license) to fix this for you even though you are still getting paid for the license?
Actually why not, is Atlassian considering making a bounty for their issues so someone can deliver with expectation for the bounty paid? Imagine how would tide change will all those people knowledgeable from developing plugins?

I could see why relation between tens of tables could appear like road to hell before, but seriously, isn't the lack of them the reason your product needs so much care, ie: integrity checker(btw doesn't seem like it was updated while the product did develop, instead your solution is to make KBs), and why you don't even fix real cause it has to even be in the product(ie: bad design decision) in the first place?
Why not fix it?

All you have to do is optimize that "hell" afterwards.

//Tomas

In Reply to @Neal Applebaum 

Storing things by group name, group id, group star alignment, phase of the moon... actually doesn't really matter at all.  As long as you have consistency.  A Group 'ID' is nothing more than a token that's uniquely identifiable across the domain it's a member of.  A group ID can be a numeric identifier as per traditional relational design, but a group ID can be a name as well.  There's actually nothing inherently wrong with using a group name as the unique identifier as long as it's unique with respect to the things you're working with.  ie: unique globally, unique per project, etc etc, AND you use the database tools to make your life easier with cascading updates to ensure consistency when making changes.

Obviously some indirection by having an id+name combination as per typical relational design would make life easier as you mentioned, but life would be also much much much easier if they chose other design decisions as well.

Here now we bring in proper relational design, with cascading updates and soforth which Atlassian has chosen not to use.  I could see maybe 30 years ago there *might (and that's a big 'might') be a justifiable reason to not trust the consistency of a RDBMS rules.  But in this day and age, even mysql of all things has reasonable consistency enforcement and supports triggers/etc.

As far as the Jira database goes, There are literally zero constraints the last time I looked at my Postgres db that stores the Jira data.  There's no foreign keys... all of that is done at the application level.... which makes design considerably harder because now you have to code all the relationship management by hand in app code without the database to help you keep consistency. (This is why we have garbage like duplicate fields and whatnot that the 'Jira integrity checker' has to now fix)

Place blame where blame is due... it's due to the fact that none of the backend actually utilizes the RDBMS to its full potential, and instead has a hodgepodge of app-side management code to handle things like group name renames (or lack thereof).  But as they say "the work has to be done somewhere".  You might as well use the RDBMS for what it's truly designed for.  Holding your data with high levels of consistency, as defined by the consistency rules... which as we know in this project, don't exist.

Edit: Preformat didn't work well for quoting.. lets try a table.

Daniel, your comment says it all.  We are having the same thoughts on a shaky foundation.

I think everyone can see why what you Neal A explained creates a problem but that's really not an excuse to not fix it in 19 years. Third party plugins are updated all the time (much more than the ones Atlassian sadly keeps taking over) and over the years they could have flagged for an upcoming change and give third party devs plenty of time to adhere to the new convention. With this sort of thinking we would still all be using windows 95. It's also the reason why they might eventually be completely outrun by a new competitor. Aiming to go enterprise with a shaky foundation and no will to sort it out doesn't bode well.

That is ridiculus! We consider finding a better solution, now.

No update... AS ALWAYS WITH THIS COMPANY

So...what's the "official" Atlassian update on this?

Addressed to the previous comment (Mark M). If you read through this ticket (especially my older comments) you will see that the problem is that instead of using a unique ID for each group to join across all the tables, a developer used the actual group name. So you cannot change the group name without also updating the reference to it in dozens of tables. As you say you are a software developer, you wouldn't have made this mistake nor expected it from your first-year programmers either. What Atlassian should have done was create a relationship between internal unique ID and group name so they changing the group name would indeed be as simple as you said. All internal references would remain linked by ID. I'm sure you can just imagine all the tables that would be affected by this, so here we are.