-
Suggestion
-
Resolution: Unresolved
-
None
-
910
-
169
-
-
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
Original request description:
As a JIRA administrator I am responsible for managing a large installation with multiple users and groups. Given the dynamic nature of my environment it is very difficult for me to create the correct user group name which can be used for many projects later on. I need to be able to rename the user groups, to reflect the changes my organisation undergoes.
- is duplicated by
-
JRASERVER-61890 Renamed LDAP Group is Not Reflected in Permission Scheme
-
- Gathering Impact
-
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- is incorporated by
-
- Closed
- is related to
-
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
-
- Gathering Interest
- relates to
-
- Closed
-
- Closed
-
- Closed
-
- Gathering Interest
-
- Under Consideration
- was cloned as
-
- Gathering Interest
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[JRASERVER-1391] Provide the ability to rename groups after creation
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
| 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. |
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.
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?!?!?
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.
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
The tag is also affect-cloud, it is not a matter of server edition or datacenter or cloud: it is a global Jira (core) problem.
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
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 
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!
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.
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,
- Yes, it does. It covers values of Group Picker (single and multiple).
- 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:
- 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.
- 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
- How does it affect Crowd groups, and generally, the groups in other user directories ?
- 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... ))
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!
Well, 367 me-too's start to become boring. Just vote then. The point has been made, there hasn't been anything new.
Let's continue this lovely discussion elsewhere.
He was providing an argument in favor of the feature. I find it interesting. We hope Atlassian finds it interesting. it was meant for them, not for you. You were the one who subscribed to observe.
Your life is really interesting, but can we keep this thread for interesting updates from atlassian?
Created: 03/Mar/2003 10:23 AM
This ticket will soon be of age .
Let's celebrate ? LMAO
Really struggling with how this is still not possible. As creating new groups as well as adding new members and then having to configure all the different atlassian product permissions is already rather a tedious process in the UI. And now you tell me I have to basically do those things all over again just due to the fact that a group might need a better name or possibly might even just have a typo.
rudy.dullier to be totally honest, you can manage groups in JIRA, but just not rename them. Also, project permissions can be defined per group, but the UX for that is not that nice, in my opinion.
This actually shows this is quite a tech debt. There are various ways to mitigate the debt, but apparently the Product Owners of Jira software do not consider this so important to prioritize this problem high enough.
At least from the reputation point, I would prioritize this very high. Or maybe create a bounty and allow the community to solve this. Yet, we have nothing, so we have to live with this.
Does it mean it's a great product that is unmanageable?
Should we number project A-B-C-D and number groups 1-2-3-4 so we never want to rename one? Looks silly.
I'm curious how big they are assuming our setups are. In big corporations its very common to reorganize and rename teams, as such the security groups must be updated.
Also individual securities per person is a shame. And that's what happen in User and Roles, a project administrator is not allowed to update a user group, instead they must manage people one by one for each and every project.
To some extent, it might be as valid to have a "replace group by", so that we can create a new group and apply it where a former group was used.
I actually did that years ago to migrate a product between Active Directories.
In fact I had :
- Delete group : For cleanup
- Extend group : To add a group alongside an existing one, so actually using 2 groups for the different ADs
- Replace group : To add a group and remove the former
I wonder how it is still in "Under Consideration" stage even after 15 years. Strange ! @ Atlassian team, please fix this.
This made my team sick! lol!
Dear Atlassian Team, are we a joke to you?
I'm wondering if the cost to actually implement this is actually higher or lower than having like 10 people partying to celebrate this issue.
For those going the shady database way, I've found the "full text search" feature of "Dbeaver / Free Universal Database Tool" (free or paid plans) to be very useful. It's even possible to lookup numbers (like hidden IDs )
Well we did get a cake for the 15th https://jira.atlassian.com/browse/JRASERVER-1391?focusedCommentId=1741664&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1741664
Hi,
I was probably missing something, indeed, there is no rename group built-in.
Thanks to ephemeralin for providing such script, i'll give it a try.
To Atlassian, don't forget to provide REST API for this too. In 2019 (and already before that) people are more and more relying on automation.
I'm feeling sad to be able to create a user from API (still in experimental state?), add user to a group, but not actually manage it later on.
Use case is to embed these actions in ServiceNow to fully automate management of our user base based on external users requests/validation.
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