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.

I don't get it... this sounds like a severe lack of understanding on the part of Atlassian.

"This is a breaking change....."

"However, here is how to do it manually, without breaking things"

Well... uhhhh.... any first year programmer can take the manual instructions and create code for this process to occur automatically.  (I know, because I am a software developer, and I own a software company, and this is what we expect of first-year programmers we hire)

Add a new screen with one combo box and one input box, and a button called 'rename'

The combo box would select an existing group to rename.

The input box would be the new name

The rename button would uhh... you know... process the rename.

Prior to rename, the Jira app should spit out the possible side-effects and find filters that need to be changed. etc etc...

Have all filters and dependencies laid out on a single page so they can be changed all at once as part of the rename.

Breaking Dependent apps... well that's a given, since apps do their own thing.  And we all know this.

It's not rocket science people.

Yes, nothing new, still developed/owned by Atlassian.
//now I'm torn between smiley face and crying face... and whether any is appropriate even...

Sadly the effect of Atlassian forcing either DC / cloud or nothing, in terms of support/patching - did not reflect in any way shape or form to all reported issues that should be translated as bigger impact due to ... you know more complex, heavier usage and lastly more data...

//Tomas

OMG, 21 months since last Atlassian official update on this issue (april 2019) and nothing has changed? I remember how we were surprised at my previous company that we cannot change user grups (but we have to recreate them and remove old ones). 2 companies forward, issue is back on the table and.... nothing new?!?!?

Like "The Office" x). Hope it goes better than that

Luckily Atlassian worked on the really useful 'comment reactions' feature so I can now give your comment a thumbs up.

Instead of actually fixing useful things, like the ability to rename groups.

I guess Atlassian are planning for Jira to become a new social media app, which is why they're now introducing social media features.

Well Atlassian... What do we have now?

No server support - in fact all the changes already related to DC versions only

No way to migrate to Cloud - incompatible add-ons + doubled price vs. server maintenance

No way to upgrade to Datacenter - price is 5x for teams 100+ users

What to do with all that? Our decision is:

Stop maintenance now

Continue using of server products

Unsubscribe from all about-to-20-years-old issues

Search for alternatives in mid-term prospective (2-3 years)

Good luck. Hopefully Top500 Fortune companies are enough for you.

Another vote for this feature to be added to Data Center.

We have the same issue: we manage several Jira groups (also with the nesting feature) in order to represent our organizations (department, sub-dept, team, etc) so that we use these groups in project roles, notifications, project/filter/dashboard permissions, etc.

Also, in order to have the same level of details, we use the Jira as User Directory in Confluence.

 It means a change in the organization has a big impact both on Jira admin and users. This should be a must-have feature for a Jira admin.

 Honestly, I can't understand why you can't apply your solution as an OOTB feature and we are still waiting for it after 8y

Yes, please add this feature.  I've voted a while back for this.  So I won't write +1....

The problem also affects the Datacenter Edition and this product will continue to exist...

lol, i think not.

They actually discontinued Jira server because they could not implement group renaming 

(and maybe also because it was way too cheap) 

It would be a truly nice surprise if Atlassian would solve some 10-15+ years old cases before end of support for Server.

Come on, shock and amaze us!

Forget folks all the "good times".

They desided to discontinue Jira server NOT TO SOLVE THIS...

Use emojis in the cloud instead

Please +1

Okay, that's a good time to SOLVE THIS! Guys...

Don't be angry Ricky, at least soon you will be able to react to funny coments on this post...

This is one of the most impactful and fundamental features that Atlassian should have and be deeply focused on. 

But instead, let's make sure we can add emojis to comments (https://jira.atlassian.com/browse/JRASERVER-29190) because that's a super agile-value-added features that everyone is dying to have...

How dare you doubling the licensing costs while just leaving something important like this to rot?

The groups in the internal directory are only a part of the problem. Another part is the groups synced with LDAP/AD – they're synced as if the group names were immutable. And then there's another variation of this problem when you want to rename or merge user accounts (it's even more complicated, because usernames are linked to more entities than group names).
Automation for Jira, which uses Jira users as actors and rule owners, and the software house behind which has already been bought by Atlassian, has a feature that seems to address the renamed-users-from-LDAP part of this problem: Transfer User. I haven't tried it yet (the doc is only for the cloud, so I'm not sure if the button I can see in the Server version does anything), but if the coders who make Automation sometimes work on Jira proper, we might actually see this feature added in less than another 18 years

is there an update on this ticket ? 

Would be great to have some focus to develop this functionality that you have since 18 years in backlog it seems. 
It would be great to not have to delete and recreate multiple groups of 50 users each just because we need to change the name... 

 I'm starting to administer Jira full of hope to get things done and aligned. By migrating a server based system into the cloud I were missing the simple "rename" on the groups.

But with the age of 18 years - it could initiate its renaming on its own, doesn't it? 

Im off to my winter-holidays but before I leave I just wanted to wish JRASERVER-1391 a Happy 18th birthday for next week! You're old enough to drink alcohol in most countries!

Radek, once it's 18, it can legally vote for itself, right? 

It's going to be 18 soon, do we throw a virtual party?

I have a conspiracy theory:
They won't fix this ever...
Most customers will move to cloud anyways, and they will make large customers use Atlassian Crowd...

Could we at least have case insensitive autocomplete popup (when adding people to groups) before this is fixed?

The topic is 17 years old... lol... 

Are you waiting for it to be 18 or 21 years old (depending on the country) so you can try to solve it?

Or even better.. someone will tell the customers to buy another plugin...

Hi, I dont get the reason of impossibility to rename a group. It will be so useful and avoid errors if any group creation is missing in a workflow (as it is hard to list all post function, or any action where a group is called).

We need this dev to be efficient and able to manage a simple topic.

Are you sure that it is possible in Datacenter?

I think it's more like February 30, 2024 

February 2, 2024, this is the date when this issue will be resolved! 🤯

Anyone who knows basic relational database design knows not to create a foreign key based on a value a user would like to see/change, especially if that key is used in multiple tables. We use internal unique codes (usually numeric) for this purpose in the vast majority of our tables in our databases. For the most part, Jira got this right. However, someone made a boo-boo on this particular key (group name) and it just snowballed to become more and more difficult to reverse that error. Atlassian, as a company, is generally more transparent about their bugs (which sometimes doesn't help them or us, their clients) than other companies, but I guess it's difficult for them to admit they made this boo-boo over 15 years ago. And now, the effort to fix it, with the complexity that has come on since then is even more, especially with integration, third party add-ons, cloud vs. server, etc. etc.

I'm making a joke, because this(or bugs here) and/or how fast are they fixed is too sad to even cry about:

You miss-understood, they are merely analyzing it as something they didn't think about before.

As obviously it is not something that is quite normal function in all other systems decades ago.

I mean, Do you know when was first version/release of Jira dated?

At the age of Windows 3.11 / 98 perhaps such stuff was not common practice ...

Maybe Unix/Linux didn't reach their office who knows, it's history now.

Is this a joke? SEVENTEEN YEARS and still no way to rename groups, because "it's complicated"?

Gregory, just several minutes ago got first one
Yeah, issues will be for sure. Not because it's a bad plugin, because of a topic complexity.
But I'm ready, send your findings to public ticketing

Roman, thank you for explanations. I know is was a lot of work, and I think, more issues will come from users. Great that you do it, go on ))

Thanks,

a last think I have in mind: Does it replace the default value of a group picker field you have used in a service desk request type?

Hi Jean,

1. Yes, it does. It covers values of Group Picker (single and multiple).
2. Not yet. Thank you for pointing me there. Will be added till the end of the week.

At the moment user picker filtering works in the following way (in case of one rule present):

• filtering still present
• group disappears
• nobody can be selected anymore

Regards, Roman

Hi,

Great that a solution starts to appear, a shame that this is a third party plugin that need to be paid for such an incredibly basic feature..... but that is another story.....

Does this plugin update the existing tickets that reference groups within group pickers fields?
Does this plugin update the user picker fields filters? (eg: can only pick user from group A)

Thanks Roman.

Thanks for the info. I see the plugin isn't approved for Data Center yet, probably in your future plans. I would expect that the cache updates would indeed cause some performance degredation for a while. Hopefully not too much

Ok. Seems that some of you would like to do deep dive into technical stuff
Let me shed some light on some aspects of the implementation.

Places-to-be-renamed. Funny thing, but two official pages from Atlassian (JRASERVER-36740 and How to identify group usage in JIRA) have slightly different lists of group usage and even that is not full. I've covered all places that could find and plan to add 3rd party plugins to the list.

Validation. Before any renaming plugin performs validation against list of rules to prevent inappropriate renaming. Such as:

• Admin rights
• Not a system group
• Directory allows update groups
• ...and others

SQL. Quite tricky part. Each query should be as much simple as it is possible to run on all supported DBs w/o issues. It was a good practice to find all variance of SQL standard implementations.

XML and JQL. Jira's workflows and search requests stored in DB should be parsed first before renaming to be on the safe side.

Swap groups. As you can understand, Jira API does not provide anything to help with group renaming. Except one method, swap groups on deletion. This is the key why external integrations works. Because, user transition and renaming in external directories done by Jira itself.
Answering Gregory's questions:

1. If external user directory allows group update (Read/Write mode), group will be renamed in external directory. Technically, removed and created new one with the same users but other name. This is how group renaming actually works on any sycnc right now.
2. Similar behavior as in #1. Group will be recreated with new name and same membership.

Transaction. All actions performed in transaction and in case of any exceptional situation all changes rolled back.

Clean Java caches. This thing allows to see the changes right after them. Without restart. Clearing caches might cause some performance degradation for some time. But personally I haven't discern such on one huge installation where similar approach is running for a long time.

I cannot call this plugin simple or even trivial. It was ~3 times harder to implement and test than API Tokens for Jira.
I hope it was enough to answer questions that already comes up.
Do not hesitate to ask if something left unclear.

Matt, "the plugin means you don't have to take Jira down" - there is clear Jira Cache in Script Runner, do you know this plugin  ?  Or a function in Power Scripts, so one may create a script for group renaming using sql and add  the script to the gadget to run from a Jira dashboard, without need to restart. 

"not a big issue for one who knows some sql" - to be fair, the plugin means you don't have to take Jira down

Hi all,

Great job, I am sure it is a great add-on, but renaming groups in Jira was not a big issue for one who knows some sql and may read these comments. The problems is outside of Jira itself.

 
So, there are still question for the add-on

1. How does it affect Crowd groups, and generally, the groups in other user directories ?
2. If Jira is used as a user directory server, by Confluence,  Bitbucket, etc., what will happen in these applications after renaming the groups?

Since all these relate to permissions, it may be sensitive topic for applications in the real life

So let me get this straight ... For 17 years Atlassian has claimed this is too complex due to the nature of the poorly designed database structure (which they won't admit as such, but OK), and offered a number of alternatives involving database updates, XML mass search/replace, and downtimes, etc. and now a third party has offered a seamless way of doing this at minimal cost and no downtime?

Hi Roman, thank you, it works!

Alas I don't remember what I wanted to rename 10 years ago when I joined this... ))

Hurray, that's a good step forward!

Hi guys!

Sorry for interrupting such a great party.
Check out my Rename Group in Jira plugin

Feel free to try it and provide feedbacks,
Roman

@Adam Labedzki - I think this is covered under https://jira.atlassian.com/browse/ID-6677 for the Atlassian cloud applications

P.S. does this feature request affects also Jira Cloud? Because I was unable to find any 'group renaming' feature request in Jira Cloud project (and I do not belive that people do not need it).

I had a "WTF" moment when I recently discovered that I cannot rename a user group name... One of the basic features elsewere. As we have changed naming convention and have over 30 projects it is a pain in the ass to manage the groups without renaming them...

Wow what a party

Thanks to all who attended Happy 17 years !!! Here's to another 17. 

Best wishes

Wait until next year when this issue will become 18, allowing it to look at all these sites on the internet, drink alcohol, and vote for other issues!

HBD!

HAPPY B'DAY MOFOS !

https://giphy.com/gifs/l0MYt5jPR6QX5pnqM/html5

Let's pop the champagne!

Happy 17th birthday