|
|
|
Yes, please allow renaming groups. On a site already running JIRA and having lots of groups/projects it is difficult/impossible to create the new - correct - group name, go through all the permission and notification schemes and switch the old name to the new one and then delete the old one. If only one can simply rename a group...
Please fix this, as this creates problems with user management.
Please fix this asap. We're using the Jira & Confluence shared user ID's which puts pressure into adding more groups into the system - we currently have 55 groups, half of which should be renamed for clarity.
This is certainly something we need to fix. The hacky workaround is to create an XML backup, and do a search & replace of '"<groupname>"', and import the modified XML.
How about this interim solution: make an "upgrade task" that renames the groups during startup and create a way for the administrators to somehow specify which groups should be renamed? The XML trick is tough one since a group name is actually quite likely to match some content in issue descriptions...
A proper fix would be not much more effort than any interim hack. For the search & replace, if you include the quotes, s/"<groupname>"/"<newgroupname>"/g, that would avoid matching mentions in comments.
Hi,
Rename of group is a MUST for Jira. Changing group name is a feature you have in Windows, Netware, email servers, etc. Alvaro Alonso Hi,
We need this functionnality because of workflow reorganisation. Thanks Yes, being able to change a group's name would make life in the fast lane much easier! (And we all live there - right?!)
Hi,
Somehow two diffferent groups have been created with the SAME group name (shouldn't that be checked and forbidden at first ?). Now, when assigning groups to users, we have two entries that look identical but correspond in fact to these two different groups. As expected, people often choose the wrong entry. As they are different, the easy solution is to rename one of them. So please, fix it. Thanks. Ps: This feature has been request for almost 4 years... Is it that hard to implement ? How is it that today, people are still writing applications for which you can't edit dumb strings like a group name... ? I too am surprise this issue's been lurking around for so long. How hard can it be? It's just adding a form field to the group-edit screen, isn't it?
First, I think it was some design oversight by Atlassian in using group names instead of ID's in all the foreign key relationships. Hard to understand since the rest of JIRA uses ID's (except for usernames). So, that's probably why it's not an easy fix. Second - regarding the duplicate group names - can you query the database directly? Is it perhaps a case sensitivity issue or a trailing space or something?
Use goups as an id was a mistake, but perhaps it can be fixed by adding a "label".
Users would be only aware of the label, but internaly the old name/id would be used. I am currently at the edge of setting up a new clearly defined new System with a database of more then one year. So i have quite some groups to rename. I could not yet find any help in renaming groups in JIRA, not even as SQL-Script.
So i am currently digging around and maybe someone can help me to find something in this direction. I have created a table with oldgroupname and newgroupname which i called tab_groupmigration. This SQL-Script looks good as i restarted my 3.7 testinstance on mysql: update membershipbase x inner join tab_groupmigration z on x.GROUP_NAME = z.oldgroupname set GROUP_NAME = z.newgroupname update schemepermissions x inner join tab_groupmigration z on x.perm_parameter = z.oldgroupname set perm_parameter = z.newgroupname I would be nice i someone could state that i did not forget any relevant field. p.s. i am aware of that the same field exists for the notification scheme table. Maybe i will comment later on again (if no one replies After digging a bit deaper i have the following solution for me (so far):
I would appriciate any confirmation to this or other hints to this Frank, here's a little script I wrote to find columns of a certain name (not just for JIRA, but in my work):
select obj.name+ '.' +col.name from syscolumns col, sysobjects obj It found this: changeitem.groupid, filtersubscription.groupname, groupbase.groupname, jiraperms.groupname, It's not 100% complete in finding the columns you need (the name of the column is all that's checked), but it can be helpful. I would also check that the viewable by Group for comments is included in your search. In the XML it looks like this: Thanks Neal.
Of course i forgot the most important Table groupbase. And the good hint to the jiraaction-table ended in these 2 additional SQL-Statements: update groupbase x inner join tab_groupmigration z on x.groupname = z.oldgroupname set groupname = z.newgroupname; update jiraaction x inner join tab_groupmigration z on x.actionlevel = z.oldgroupname set actionlevel = z.newgroupname; I dont think the rest must be modified. The Parameter-Columns are not in your resultset as they didnt contain the group in its name, but i think it is quite a good base to work with now. Is that issue really that complicated to do?
It seems to be a fairly basic requirement, which is really helpful. we have just defined naming conventions for our hundreds of groups...
please please implement this feature. I just renamed some groups in JIRA 3.10, with the following SQL-Code (for MySQL) i did not find any old groupnames in the extracted XML:
update groupbase x inner join tab_groupmigration z on x.groupname = z.oldgroupname set groupname = z.newgroupname; update membershipbase x inner join tab_groupmigration z on x.GROUP_NAME = z.oldgroupname set GROUP_NAME = z.newgroupname; update schemepermissions x inner join tab_groupmigration z on x.perm_parameter = z.oldgroupname set perm_parameter = z.newgroupname where perm_type = 'group'; update notification x inner join tab_groupmigration z on x.notif_parameter = z.oldgroupname set notif_parameter = z.newgroupname where notif_type = 'Group_Dropdown'; update schemeissuesecurities x inner join tab_groupmigration z on x.sec_parameter = z.oldgroupname set sec_parameter = z.newgroupname where sec_type = 'group'; update searchrequest x inner join tab_groupmigration z on x.groupname = z.oldgroupname set groupname = z.newgroupname; update filtersubscription x inner join tab_groupmigration z on x.groupname = z.oldgroupname set groupname = z.newgroupname; update jiraaction x inner join tab_groupmigration z on x.actionlevel = z.oldgroupname set actionlevel = z.newgroupname; update worklog x inner join tab_groupmigration z on x.grouplevel = z.oldgroupname set grouplevel = z.newgroupname; update projectroleactor x inner join tab_groupmigration z on x.roletypeparameter = z.oldgroupname set roletypeparameter = z.newgroupname where roletype = 'atlassian-group-role-actor' it looks stable from my point of view. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
order is otherway around as the other issue have no description.