Details

    • Last commented by user?:
      true
    • Support reference count:
      32
    • Epic Link:

      Description

      Confluence does not provide a function to change the username via the web or remote interface.

      Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key. Therefore if you need to update the username, you will have to update every occurrence of the username used as foreign key in all tables. This procedure should be automated to avoid corruption in the database due to mistakes made in the process.

      Atlassian Status as of January 22, 2013

      Hi All,
      Thanks for your feedback on this issue thus far. We acknowledge that administrators need a way to change usernames within the system. Please note, that users can still change their Full Name as it appears in the Confluence user interface. For example, a user can change his Full Name from Bill Arconati to John Smith but currently can't change his username from barconati to jsmith.

      At this stage we do not have a supported way to change the username in your system. However, we've documented a series of SQL scripts to allow an administrator to update a username directly inside the Confluence database. Please note that the process is not supported but a number of customers have been successful with them.

      We have started exploring solutions to this complex issue and hope to provide a more eloquent way of updating usernames within the next year. We will update the status of this issue once we have made further progress.

      Thank you for your patience.
      Bill Arconati

        Issue Links

          Activity

          jens@atlassian.com Jens Schumacher [Atlassian] created issue -
          Hide
          jens@atlassian.com Jens Schumacher [Atlassian] added a comment -

          Another more radical way would be to change the relationship in the database. There are a few ways to handle the external user management problem more nicely. One solution was suggested by Nick Minutello in the forums:

          "Basically, there should be a 1st class "ConfluenceUser" entity - which
          has is involved in all of the relationships with all of the other tables -
          no os_username anywhere in other tables.
          The ConfluenceUser entity needs to have an osusername field - which is used
          to load it from the security credentials.

          The benefit of this approach is that osusername isnt scattered everywhere -
          and you are able to change the osusername simply by updating the one table
          (and also in the osuser datasource - which may be in userbase table - or in
          an external system)
          Also you can properly enforce constraints around the other entities'
          relationships with user - something that both Jira and Confluence kinda
          suffer from the lack of..."

          Show
          jens@atlassian.com Jens Schumacher [Atlassian] added a comment - Another more radical way would be to change the relationship in the database. There are a few ways to handle the external user management problem more nicely. One solution was suggested by Nick Minutello in the forums: "Basically, there should be a 1st class "ConfluenceUser" entity - which has is involved in all of the relationships with all of the other tables - no os_username anywhere in other tables. The ConfluenceUser entity needs to have an osusername field - which is used to load it from the security credentials. The benefit of this approach is that osusername isnt scattered everywhere - and you are able to change the osusername simply by updating the one table (and also in the osuser datasource - which may be in userbase table - or in an external system) Also you can properly enforce constraints around the other entities' relationships with user - something that both Jira and Confluence kinda suffer from the lack of..."
          cmiller@atlassian.com Charles Miller made changes -
          Field Original Value New Value
          Summary Changing the username in Confluence Change usernames
          Type Bug [ 1 ] New Feature [ 2 ]
          Hide
          matt@atlassian.com Matt Ryall [Atlassian] added a comment -

          The Confluence documentation now has a page that lists some workaround solutions:

          http://confluence.atlassian.com/display/DOC/Changing+Usernames

          Show
          matt@atlassian.com Matt Ryall [Atlassian] added a comment - The Confluence documentation now has a page that lists some workaround solutions: http://confluence.atlassian.com/display/DOC/Changing+Usernames
          matt@atlassian.com Matt Ryall [Atlassian] made changes -
          Link This issue is duplicated by CONF-5567 [ CONF-5567 ]
          Hide
          skoch Steve Koch added a comment -

          Jens Schumacher's solution is more robust, providing all the ramifications of the change are understood.

          Show
          skoch Steve Koch added a comment - Jens Schumacher's solution is more robust, providing all the ramifications of the change are understood.
          Hide
          danjirawork Dan Chapman added a comment -

          The ability to update our userid is key to us as we are currently merging two companies together - hence creating new corporate identifiers.... We currently use LDAP authentication (on top of ActiveDirectory)

          Show
          danjirawork Dan Chapman added a comment - The ability to update our userid is key to us as we are currently merging two companies together - hence creating new corporate identifiers.... We currently use LDAP authentication (on top of ActiveDirectory)
          Hide
          chrlov Christian Løverås added a comment -

          We created the Confluence users before we decided to integrate with our LDAP server (should have thought of that first, of course). A simpler way to change all usernames than manually SQL-ing it as in Matt Ryall's link would save us from a lot of work.

          I suspect others might run into the same kind of problems if they start using Confluence and then later need to integrate with other systems.

          Show
          chrlov Christian Løverås added a comment - We created the Confluence users before we decided to integrate with our LDAP server (should have thought of that first, of course). A simpler way to change all usernames than manually SQL-ing it as in Matt Ryall's link would save us from a lot of work. I suspect others might run into the same kind of problems if they start using Confluence and then later need to integrate with other systems.
          Hide
          wadestebbings Wade Stebbings added a comment -

          I voted for this.

          I would be OK with a programmable (ie, SOAP, XML-RPC) way of changing users - especially good for bulk changes, but having the web-based method would be great for those occasionally changes. We, like Dan Chapman's case above are two large companies being merged, with I'm sure other mergers on the way. There is the present user management scheme which is in place now (within various systems) which we are also adopting, presently, for our JIRA and Confluence implementations. This scheme is not so user-friendly, of course - it is based on the employee number. So there is effort to change this scheme to use more user-friendly names. So we will need to change our user names in the not-so-distant future. In the transition, I can see blocks of users remaining on one scheme while others migrate (as a possibility). A bulk-change facility would also be nice to have in addition to the one-offs.

          Show
          wadestebbings Wade Stebbings added a comment - I voted for this. I would be OK with a programmable (ie, SOAP, XML-RPC) way of changing users - especially good for bulk changes, but having the web-based method would be great for those occasionally changes. We, like Dan Chapman's case above are two large companies being merged, with I'm sure other mergers on the way. There is the present user management scheme which is in place now (within various systems) which we are also adopting, presently, for our JIRA and Confluence implementations. This scheme is not so user-friendly, of course - it is based on the employee number. So there is effort to change this scheme to use more user-friendly names. So we will need to change our user names in the not-so-distant future. In the transition, I can see blocks of users remaining on one scheme while others migrate (as a possibility). A bulk-change facility would also be nice to have in addition to the one-offs.
          cmiller@atlassian.com Charles Miller made changes -
          Link This issue is duplicated by CONF-7288 [ CONF-7288 ]
          Hide
          aforsey Andrew Forsey added a comment -

          I agree this is a very important change to be made. Like Christian, my company didn't start out with LDAP integration but are changing to it now. I'm having in issue with a few usernames which belong to very active users and are different than they are in LDAP. If nothing else, people's names can change and I've found many users like to have their usernames updated when this happens.

          Show
          aforsey Andrew Forsey added a comment - I agree this is a very important change to be made. Like Christian, my company didn't start out with LDAP integration but are changing to it now. I'm having in issue with a few usernames which belong to very active users and are different than they are in LDAP. If nothing else, people's names can change and I've found many users like to have their usernames updated when this happens.
          Hide
          bcallahan Bill Callahan added a comment -

          It seems that the safest way to do this which ensures a consistent database is to make user name change a STORED PROCEDURE in the database itself. Then Confluence would only need to call this stored procedure when an administrator needs to do a name change. In fact, the procedure would not be much different from the list of commands that Atlassian suggest that you give to your DBA to do this.

          Atlassian could supply the SQL to create this stored procedure, or better yet, integrate it with UI in the user administration console.

          Bill

          Show
          bcallahan Bill Callahan added a comment - It seems that the safest way to do this which ensures a consistent database is to make user name change a STORED PROCEDURE in the database itself. Then Confluence would only need to call this stored procedure when an administrator needs to do a name change. In fact, the procedure would not be much different from the list of commands that Atlassian suggest that you give to your DBA to do this. Atlassian could supply the SQL to create this stored procedure, or better yet, integrate it with UI in the user administration console. Bill
          Hide
          dominion Andrew Whyte added a comment -

          Makeing the username change more complex may hurt flexibility in the future. The best method is to get away from the username being the unique key for identifying the user entry.

          Using a numeric or alphanumeric field as the primary key means that you can tie the user-auth system to any external setup you want without limiting your options. Leave it up to the external system to provide a unique ident, and just store/use that if needed leaving all of the important confluence data alone.

          Once you move the key to being just a key field, you free to change the username at will, so long as it test to make sure that it's still unique and doesn't collide with someone elses choice. Username basically becomes a "display name", and something to login with.

          -Andrew

          Show
          dominion Andrew Whyte added a comment - Makeing the username change more complex may hurt flexibility in the future. The best method is to get away from the username being the unique key for identifying the user entry. Using a numeric or alphanumeric field as the primary key means that you can tie the user-auth system to any external setup you want without limiting your options. Leave it up to the external system to provide a unique ident, and just store/use that if needed leaving all of the important confluence data alone. Once you move the key to being just a key field, you free to change the username at will, so long as it test to make sure that it's still unique and doesn't collide with someone elses choice. Username basically becomes a "display name", and something to login with. -Andrew
          Hide
          cmiller@atlassian.com Charles Miller added a comment -

          Given the range of different databases we support, a stored procedure isn't an option.

          Show
          cmiller@atlassian.com Charles Miller added a comment - Given the range of different databases we support, a stored procedure isn't an option.
          Hide
          ramar rama roberts added a comment -

          In addition to the web/remote interface for changing usernames, it would be ideal to have a developer friendly Java API to do the same. This would be helpful for the remote user management scenario.

          It would also be great if the database can be normalized.

          Show
          ramar rama roberts added a comment - In addition to the web/remote interface for changing usernames, it would be ideal to have a developer friendly Java API to do the same. This would be helpful for the remote user management scenario. It would also be great if the database can be normalized.
          Hide
          mrjcleaver Martin Cleaver [Blended Perspectives] added a comment -

          http://forums.atlassian.com/thread.jspa?messageID=257250010 - that user names also change when people get married.

          Show
          mrjcleaver Martin Cleaver [Blended Perspectives] added a comment - http://forums.atlassian.com/thread.jspa?messageID=257250010 - that user names also change when people get married.
          Hide
          javahollic Andy Brook (Javahollic Software) added a comment -

          I just hit this today. Registering users as 'abc' not abc@place.com, internal users registered via email get the email @place.com - not required.

          My +1 to fix. I now have a bundle of users created that I need to fix....

          Show
          javahollic Andy Brook (Javahollic Software) added a comment - I just hit this today. Registering users as 'abc' not abc@place.com, internal users registered via email get the email @place.com - not required. My +1 to fix. I now have a bundle of users created that I need to fix....
          Hide
          bquintrell Bill Quintrell added a comment -

          Since it appears this is not going to be addressed I will comment on a solution which requires a lot of work but has proven successful in other very large systems.
          Concepts:

          • Internally, a user is represented by a unique "key" object. Similar to today's user ID. This is the "internal user ID" or IID. This is never displayed to a user.
          • User's have a login user ID - much like they do today. These are unique. However, the system should allow for more than one user login ID per Internal user ID. This is not a requirement but will prove handy as show later.
          • User's have a Display Name associated with the IID.
          • An advanced system (like confluence should be) will also retain all previous Display Names for an IID along with the date range that name was in force.
          • All stored references to a user must be to the Internal ID - not the login ID or the display name. Also, make sure you retain a date along with the IID reference. For example, if the user made a Comment entry the entry will have the user's IID and the date the entry was created/modified. Equally, all permissions or ACLs retain the IID and not the login Id or Display Name.

          Of course, whenever a stored item is displayed the code should reach out and, using the IID, get the user's display. In fact, it should consider the date of the entry and (based on a server setting) display either the current user's display name or the display name in force at the time the entry was created (since each display name has a date range associated with it).

          This design allows for:

          User name changes are simply a Display Name change in the user's profile. Non-critical systems may allow the user to change their display name without administrator involvement given that the administrator typically does not validate new names.

          The user Login ID can be changed without any impact to permissions (ACLs) etc. In fact, the administrator can add a new/additional login ID and the user is free to use both/either login ID (since they point to the same user record) until the administrator or system decides to disable the old login ID. This solves the problem of coordination between when the administrator enables a new login ID and when the user is notified they should start using the new Login ID.

          Finally, there is the issue of "Who made the comment?". If Jane Doe creates a comment and later becomes Jane Deer, should the old comments and documents display "Jane Doe" or "Jane Deer"? That is the system administrator's decision/setting. Both arguments are valid for a given context. This design allows for either setting AND allows for changing the setting should a policy change be necessary. Of course, both display name links will point to the same, current user record to clearly pinpoint the actual user in question.

          When considering/integrating systems into the enterprise, these are the first design changes we consider. The next considerations involve sub-organizations or subsidiaries and "zoned" administration. But that's another topic. Unless you are amused at an enterprise product not supporting nested groups (CONF-101?).

          Show
          bquintrell Bill Quintrell added a comment - Since it appears this is not going to be addressed I will comment on a solution which requires a lot of work but has proven successful in other very large systems. Concepts: Internally, a user is represented by a unique "key" object. Similar to today's user ID. This is the "internal user ID" or IID. This is never displayed to a user. User's have a login user ID - much like they do today. These are unique. However, the system should allow for more than one user login ID per Internal user ID. This is not a requirement but will prove handy as show later. User's have a Display Name associated with the IID. An advanced system (like confluence should be) will also retain all previous Display Names for an IID along with the date range that name was in force. All stored references to a user must be to the Internal ID - not the login ID or the display name. Also, make sure you retain a date along with the IID reference. For example, if the user made a Comment entry the entry will have the user's IID and the date the entry was created/modified. Equally, all permissions or ACLs retain the IID and not the login Id or Display Name. Of course, whenever a stored item is displayed the code should reach out and, using the IID, get the user's display. In fact, it should consider the date of the entry and (based on a server setting) display either the current user's display name or the display name in force at the time the entry was created (since each display name has a date range associated with it). This design allows for: User name changes are simply a Display Name change in the user's profile. Non-critical systems may allow the user to change their display name without administrator involvement given that the administrator typically does not validate new names. The user Login ID can be changed without any impact to permissions (ACLs) etc. In fact, the administrator can add a new/additional login ID and the user is free to use both/either login ID (since they point to the same user record) until the administrator or system decides to disable the old login ID. This solves the problem of coordination between when the administrator enables a new login ID and when the user is notified they should start using the new Login ID. Finally, there is the issue of "Who made the comment?". If Jane Doe creates a comment and later becomes Jane Deer, should the old comments and documents display "Jane Doe" or "Jane Deer"? That is the system administrator's decision/setting. Both arguments are valid for a given context. This design allows for either setting AND allows for changing the setting should a policy change be necessary. Of course, both display name links will point to the same, current user record to clearly pinpoint the actual user in question. When considering/integrating systems into the enterprise, these are the first design changes we consider. The next considerations involve sub-organizations or subsidiaries and "zoned" administration. But that's another topic. Unless you are amused at an enterprise product not supporting nested groups (CONF-101?).
          fst Frank Stiller made changes -
          Link This issue is incorporated by CONF-9159 [ CONF-9159 ]
          supportcountupdater Support Count Updater made changes -
          Support reference count 8
          pfragemann Per Fragemann [Atlassian] made changes -
          Workflow jira [ 39438 ] reviewflow [ 95719 ]
          pfragemann Per Fragemann [Atlassian] made changes -
          Workflow reviewflow [ 95719 ] jira [ 103511 ]
          pfragemann Per Fragemann [Atlassian] made changes -
          Workflow jira [ 103511 ] reviewflow [ 111835 ]
          pfragemann Per Fragemann [Atlassian] made changes -
          Component/s Users & Groups [ 10318 ]
          matt@atlassian.com Matt Ryall [Atlassian] made changes -
          Comment [ From what I've heard, Atlassian is going to fix this issue in Confluence 2.7.

          cheers,
          Igor ]
          matt@atlassian.com Matt Ryall [Atlassian] made changes -
          Comment [ Just a short comment to Igor: We will not be working on this issue for the 2.7 release, there is currently no ETA for this issue.

          Cheers,
          Per ]
          matt@atlassian.com Matt Ryall [Atlassian] made changes -
          Comment [ added the proper component to this issue ]
          jens@atlassian.com Jens Schumacher [Atlassian] made changes -
          Description Confluence does not provide a function to change the username via the web or remote interface.

          Since it is not guaranteed that the users will be in the confluence database (eg. using external user management) the username rather then the id is used as a foreign key. Therefore if you need to update the username, you will have to update every occurence of the username used as foreign key in all tables. This procedure should be automated to avoid corruption in the database due to mistakes made in the process.
          Confluence does not provide a function to change the username via the web or remote interface.

          Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key. Therefore if you need to update the username, you will have to update every occurrence of the username used as foreign key in all tables. This procedure should be automated to avoid corruption in the database due to mistakes made in the process.
          Hide
          igorminar Igor Minar added a comment -

          Hi Jens,

          Why don't you create one table in the db that will map user id to user name, cache the data in the table and use it to map user names from the external storage to the Confluence ids?

          IMO that would solve all the headaches with renaming users (even for those stored in an external storage).

          cheers,
          Igor

          Show
          igorminar Igor Minar added a comment - Hi Jens, Why don't you create one table in the db that will map user id to user name, cache the data in the table and use it to map user names from the external storage to the Confluence ids? IMO that would solve all the headaches with renaming users (even for those stored in an external storage). cheers, Igor
          supportcountupdater Support Count Updater made changes -
          Support reference count 8 13
          Hide
          jimbirch Jim Birch added a comment -

          As many of the commenters on this issue are ldapped it might be worth considering the use of a external ldap invariant field and working everthing around that. In Active Directory there is a user guid that never changes, even if login name, surname, sex (or whatever) change.

          This would create a login sequence like: check ldap username, validate, fetch invariant, match to local user invariant (or create user), update any local information if required. A couple of extra steps but this will match to the authoritative ldap source painlessly handing the corporate provisioning for Confluence once and for all.

          Of course, I leave to someone else the design of a scheme that will handle all the variants - local DB only, Crowd-based, self registration, ldap plus local, ldap-only, ldap users but not groups, external invariants, etc. And I wish them luck

          Show
          jimbirch Jim Birch added a comment - As many of the commenters on this issue are ldapped it might be worth considering the use of a external ldap invariant field and working everthing around that. In Active Directory there is a user guid that never changes, even if login name, surname, sex (or whatever) change. This would create a login sequence like: check ldap username, validate, fetch invariant, match to local user invariant (or create user), update any local information if required. A couple of extra steps but this will match to the authoritative ldap source painlessly handing the corporate provisioning for Confluence once and for all. Of course, I leave to someone else the design of a scheme that will handle all the variants - local DB only, Crowd-based, self registration, ldap plus local, ldap-only, ldap users but not groups, external invariants, etc. And I wish them luck
          Hide
          mdoar Matt Doar (ServiceRocket) added a comment -

          Is there anything wrong with exporting the contents of the site, running a script over the entities.xml file where the users are defined, then importing the data?

          #!/usr/bin/python
          
          #
          # Script to update Confluence userids
          #
          # Matt Doar, Consulting Toolsmiths
          #
          # unip mybackup.zip
          # cd mybackup
          #
          # Run this script with:
          # ../userid_change entity.xml new.xml
          #
          # Check the changes:
          # diff entity.xml new.xml | more
          #
          # mv  new.xml entity.xml new.xml
          # zip -r ../newbackup.zip .
          #
          # and then restore as usual
          
          import sys
          import re
          
          # Add your users here: (old userid, new userid)
          mapping = [
              ('joesmith', 'jsmith'),
              ]
          
          
          if __name__=='__main__':
              if len(sys.argv) != 3:
                  print "Usage: %s <input file> <output file>" % sys.argv[0]
                  sys.exit(1)
              inputfile = sys.argv[1]
              outputfile = sys.argv[2]
              input = open(inputfile)
              output = open(outputfile, 'w')
              patterns = {}
              for old, new in mapping:
                  patterns[old] = re.compile('%s]' % old)
              for line in input:
          #        print "line: %s" % line
                  for old, new in mapping:
          #            print "%s is mapped to %s" % (old, new)
                      (newline, num) = patterns[old].subn("%s]" % new, line)
                      if num:
                          # No need to match other patterns
                          break
                  output.write(newline)
              input.close()
              output.close()
          
          Show
          mdoar Matt Doar (ServiceRocket) added a comment - Is there anything wrong with exporting the contents of the site, running a script over the entities.xml file where the users are defined, then importing the data? #!/usr/bin/python # # Script to update Confluence userids # # Matt Doar, Consulting Toolsmiths # # unip mybackup.zip # cd mybackup # # Run this script with: # ../userid_change entity.xml new.xml # # Check the changes: # diff entity.xml new.xml | more # # mv new.xml entity.xml new.xml # zip -r ../newbackup.zip . # # and then restore as usual import sys import re # Add your users here: (old userid, new userid) mapping = [ ('joesmith', 'jsmith'), ] if __name__=='__main__': if len(sys.argv) != 3: print "Usage: %s <input file> <output file>" % sys.argv[0] sys.exit(1) inputfile = sys.argv[1] outputfile = sys.argv[2] input = open(inputfile) output = open(outputfile, 'w') patterns = {} for old, new in mapping: patterns[old] = re.compile('%s]' % old) for line in input: # print "line: %s" % line for old, new in mapping: # print "%s is mapped to %s" % (old, new) (newline, num) = patterns[old].subn("%s]" % new, line) if num: # No need to match other patterns break output.write(newline) input.close() output.close()
          Hide
          bob.swift Bob Swift added a comment -

          Support has repeatedly told us that restoring from backup is not reliable and should be avoided at least for larger sites.

          Show
          bob.swift Bob Swift added a comment - Support has repeatedly told us that restoring from backup is not reliable and should be avoided at least for larger sites.
          Hide
          bob.swift Bob Swift added a comment -

          Furthermore, I would hope an Atlassian solution would include handing [~userid] references.

          Show
          bob.swift Bob Swift added a comment - Furthermore, I would hope an Atlassian solution would include handing [~userid] references.
          Hide
          mdoar Matt Doar (ServiceRocket) added a comment -

          Thanks, Bob. Yes, the ~userid case needs adding to that script.

          So ... is that backups that are larger than say 100MB, or only backups with attachments? Is there a note about this in the docs anywhere? Seems to me that making backups that are not reliable only benefits disk manufacturers!

          Show
          mdoar Matt Doar (ServiceRocket) added a comment - Thanks, Bob. Yes, the ~userid case needs adding to that script. So ... is that backups that are larger than say 100MB, or only backups with attachments? Is there a note about this in the docs anywhere? Seems to me that making backups that are not reliable only benefits disk manufacturers!
          Hide
          fishloa Alex Fishlock added a comment -

          We, (Brit Telecom), only take backups from the database and confluence.home, as xml restore takes an AGE, and often breaks with out of memory on our huge deployment.

          if you store attachments in the database then this is transactionally safe.. if not then there is a possibility that an attachment is deleted/added during the backup process and you miss it.

          Show
          fishloa Alex Fishlock added a comment - We, (Brit Telecom), only take backups from the database and confluence.home, as xml restore takes an AGE, and often breaks with out of memory on our huge deployment. if you store attachments in the database then this is transactionally safe.. if not then there is a possibility that an attachment is deleted/added during the backup process and you miss it.
          Hide
          fishloa Alex Fishlock added a comment -

          We used to have to change usernames in the database.. we wrote a simple sql script which did a lookup and replace in all the right places..

          I am sure that we missed something out.. but it seemed to work. We moved to a fully custom atlassian user provider a while ago, and are now moving to crowd..

          BUT the problem wills till remain for those that need to change usernames.. and basically right now,, a chunk of sql is required.

          This is basically what we did: http://confluence.atlassian.com/display/DOC/Changing+Usernames

          Show
          fishloa Alex Fishlock added a comment - We used to have to change usernames in the database.. we wrote a simple sql script which did a lookup and replace in all the right places.. I am sure that we missed something out.. but it seemed to work. We moved to a fully custom atlassian user provider a while ago, and are now moving to crowd.. BUT the problem wills till remain for those that need to change usernames.. and basically right now,, a chunk of sql is required. This is basically what we did: http://confluence.atlassian.com/display/DOC/Changing+Usernames
          Hide
          bob.swift@charter.net Bob Swift added a comment -

          Alex, yes, we used that sql script as well, we think it worked properly . Plus it only took a few minutes of downtime to execute. My only concern with the sql is that Atlassian doesn't commit to it being right or ensure it is correct for a specific version.

          Matt, not sure all of the concerns or bugs, but our restore was failing and the support response was essentially don't do that. Unfortunately, we were moving databases, so was no alternative. We eventually got all the pieces to work but it was not pleasant. Now we do database and home backup as Alex mentioned. And it is much faster. I think we were about 100MBs without attachments.

          Show
          bob.swift@charter.net Bob Swift added a comment - Alex, yes, we used that sql script as well, we think it worked properly . Plus it only took a few minutes of downtime to execute. My only concern with the sql is that Atlassian doesn't commit to it being right or ensure it is correct for a specific version. Matt, not sure all of the concerns or bugs, but our restore was failing and the support response was essentially don't do that . Unfortunately, we were moving databases, so was no alternative. We eventually got all the pieces to work but it was not pleasant. Now we do database and home backup as Alex mentioned. And it is much faster. I think we were about 100MBs without attachments.
          Hide
          javahollic Andy Brook (Javahollic Software) added a comment -

          In reply to Alex earlier (slightly off issue topic) I too had a long XML backup execution time. It was taking about 4Hours to generate a 30MB zip file (no attachments). After database connection related problems (SQLServer on gigabit LAN) I got fed up and migrated to a windows DB2 instance running on the same hardware as Confluence/Jboss. Backup times for 30MB zips are now down to 35minutes which is bearable! Out of interest, what size of XML zip/duration of backup did you decide it was not worth pursuing further (having the XML backup is the only way I can see of switching databases...).

          Show
          javahollic Andy Brook (Javahollic Software) added a comment - In reply to Alex earlier (slightly off issue topic) I too had a long XML backup execution time. It was taking about 4Hours to generate a 30MB zip file (no attachments). After database connection related problems (SQLServer on gigabit LAN) I got fed up and migrated to a windows DB2 instance running on the same hardware as Confluence/Jboss. Backup times for 30MB zips are now down to 35minutes which is bearable! Out of interest, what size of XML zip/duration of backup did you decide it was not worth pursuing further (having the XML backup is the only way I can see of switching databases...).
          Hide
          mdoar Matt Doar (ServiceRocket) added a comment -

          Good to hear people's experiences of this. About 3 years ago I used to always rely on database backups and copying the attachments directory. Then XML backups seemed to work ok, so I began using them. The one I was dealing with yesterday was only 1MB without attachments (150MB with attachments). I'll bear this in mind when I recommend backup strategies for clients. My gut feel is that I'll use the database backup if the XML backup without attachments takes more than about 10 minutes.

          As an aside, the groups in confluence seemed to get messed up internally with the above Python script, but I think it may have been upgrade related and not the script.

          Show
          mdoar Matt Doar (ServiceRocket) added a comment - Good to hear people's experiences of this. About 3 years ago I used to always rely on database backups and copying the attachments directory. Then XML backups seemed to work ok, so I began using them. The one I was dealing with yesterday was only 1MB without attachments (150MB with attachments). I'll bear this in mind when I recommend backup strategies for clients. My gut feel is that I'll use the database backup if the XML backup without attachments takes more than about 10 minutes. As an aside, the groups in confluence seemed to get messed up internally with the above Python script, but I think it may have been upgrade related and not the script.
          supportcountupdater Support Count Updater made changes -
          Support reference count 13 19
          Hide
          jknight@blackboard.com John Knight added a comment -
          Show
          jknight@blackboard.com John Knight added a comment - I've added a more robust script for Postgresql and 2.9 here: http://confluence.atlassian.com/display/DOC/Changing+Usernames?focusedCommentId=166004656#comment-166004656
          pfragemann Per Fragemann [Atlassian] made changes -
          Workflow reviewflow [ 111835 ] Quality Review Flow [ 144897 ]
          Hide
          clehoux Charlie Le Houx added a comment -

          We've got the same problem

          Been using confluence for a year, when we started we were using FirstinitialSurname, and since then after merging with another company we've changed to Firstname.Lastname

          Now i've just intergrated confluence with AD, and due to not being able to change the usernames none of the users match up. I've got 2 copies of each user. One brand new one synced up with AD, and one with a years worth of history and posts that isn't hooked up to AD.

          So we've got to decided weather to lose a years worth of history linked to each user, or to not take advantage of the AD intergration. Which we were very keen on making users automatically log into confluence.

          Or to wait for this feature to be implemented, or to attempt it myself.

          This seems to have been around for 3 years!! now, is there any chance of it ever being included? it seems like a basic thing which is causing a lot of problems.

          Or does anyone have any idea about how to make the chaged manually to Oracle? or know or anyone whoz tried?

          We've got an Oracle guru inhouse, but not too keen on passing it over if we're going to risk corruption...

          Another vote from me!

          Show
          clehoux Charlie Le Houx added a comment - We've got the same problem Been using confluence for a year, when we started we were using FirstinitialSurname, and since then after merging with another company we've changed to Firstname.Lastname Now i've just intergrated confluence with AD, and due to not being able to change the usernames none of the users match up. I've got 2 copies of each user. One brand new one synced up with AD, and one with a years worth of history and posts that isn't hooked up to AD. So we've got to decided weather to lose a years worth of history linked to each user, or to not take advantage of the AD intergration. Which we were very keen on making users automatically log into confluence. Or to wait for this feature to be implemented, or to attempt it myself. This seems to have been around for 3 years!! now, is there any chance of it ever being included? it seems like a basic thing which is causing a lot of problems. Or does anyone have any idea about how to make the chaged manually to Oracle? or know or anyone whoz tried? We've got an Oracle guru inhouse, but not too keen on passing it over if we're going to risk corruption... Another vote from me!
          Hide
          jimbirch Jim Birch added a comment -

          Charlie, It's not too hard to change usernames via sql scripts. The main difficulty is that the tables are not fully normalized so you have to find all instances of the names and fix them all. You probably want to run it first on a test instance of Confluence and confirm the process, but it's not really that hard. You do need to do a controlled sequence: backup, stop confluence, run db updates, restart confluence, reindex. In your case you will need to modify the listed scripts to account for the fact that your new user names already exist and you want to coalesce two users into a single person but your DB guy should be easily up to the task. Then you get AD plus history: definitely worth doing.

          Show
          jimbirch Jim Birch added a comment - Charlie, It's not too hard to change usernames via sql scripts. The main difficulty is that the tables are not fully normalized so you have to find all instances of the names and fix them all. You probably want to run it first on a test instance of Confluence and confirm the process, but it's not really that hard. You do need to do a controlled sequence: backup, stop confluence, run db updates, restart confluence, reindex. In your case you will need to modify the listed scripts to account for the fact that your new user names already exist and you want to coalesce two users into a single person but your DB guy should be easily up to the task. Then you get AD plus history: definitely worth doing.
          Hide
          ewells Eric Wells added a comment -

          I'm with Charlie. This is a feature that ought to be handled by the tool, no matter how easy or hard it is to do in SQL. Changing something so integral to the system (users) is vulnerable to a mistake that could have significant repercussions.

          For example, simply changing all instances from one name to another is not valid. If a user signes up for an alert (notification) as A and then changes to B and signs up for the same alert, then updating the original alert to B is not correct (it will either create a duplicate alert as B, or the SQL will fail due to a constraint, I haven't checked to see which will happen).

          I'm a SQL jockey so this really looks like no big deal, but the risk factor is there. Plus, in a large enterprise environment, I can't simply write up SQL and fire it off, it has to involve the DBA team and a full deployment with CCB and everything (modifying production data manually is a big deal here).

          The point is, users shouldn't need to do a database analysis to find all instances of a column, then do the analysis do determine which can be simly "renamed" (and which, such as alerts, need more care). Too risky. I believe this is needed as a tool feature.

          I've put in my vote.

          Show
          ewells Eric Wells added a comment - I'm with Charlie. This is a feature that ought to be handled by the tool, no matter how easy or hard it is to do in SQL. Changing something so integral to the system (users) is vulnerable to a mistake that could have significant repercussions. For example, simply changing all instances from one name to another is not valid. If a user signes up for an alert (notification) as A and then changes to B and signs up for the same alert, then updating the original alert to B is not correct (it will either create a duplicate alert as B, or the SQL will fail due to a constraint, I haven't checked to see which will happen). I'm a SQL jockey so this really looks like no big deal, but the risk factor is there. Plus, in a large enterprise environment, I can't simply write up SQL and fire it off, it has to involve the DBA team and a full deployment with CCB and everything (modifying production data manually is a big deal here). The point is, users shouldn't need to do a database analysis to find all instances of a column, then do the analysis do determine which can be simly "renamed" (and which, such as alerts, need more care). Too risky. I believe this is needed as a tool feature. I've put in my vote.
          Hide
          igorminar Igor Minar added a comment -

          It gets even better - if you use a plugin that stores information against users in the bandana storage, the usernames become part of the xml strings stored in the bandana table.

          Show
          igorminar Igor Minar added a comment - It gets even better - if you use a plugin that stores information against users in the bandana storage, the usernames become part of the xml strings stored in the bandana table.
          supportcountupdater Support Count Updater made changes -
          Support reference count 19 28
          aeng Audra Eng [Atlassian] made changes -
          PM Reviewed 22/Jan/09
          Hide
          pcsapo Paul Csapo added a comment -

          I have a similar concern with usernames in JIRA.

          Understandably, things become complex once you start using external username/password management, but for the base application itself (and for at least all supported plugins for it), it should be able to "fully" handle the username renaming process.

          In my case I think Auto XML find and replace renaming is not reliable.

          Show
          pcsapo Paul Csapo added a comment - I have a similar concern with usernames in JIRA. Understandably, things become complex once you start using external username/password management, but for the base application itself (and for at least all supported plugins for it), it should be able to "fully" handle the username renaming process. In my case I think Auto XML find and replace renaming is not reliable.
          aeng Audra Eng [Atlassian] made changes -
          Labels user_admin
          Hide
          aeng Audra Eng [Atlassian] added a comment -

          We agree that this is a good feature request and popular. We estimate this to be a large effort (estimated 2 months effort) to address this and are assessing when this could fit into a release. This may not show up until next year, depending on priorities and available resources.

          If you're interested to know how we decide on which features to implement, please read this:
          http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

          Show
          aeng Audra Eng [Atlassian] added a comment - We agree that this is a good feature request and popular. We estimate this to be a large effort (estimated 2 months effort) to address this and are assessing when this could fit into a release. This may not show up until next year, depending on priorities and available resources. If you're interested to know how we decide on which features to implement, please read this: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements
          aeng Audra Eng [Atlassian] made changes -
          PM Value 2.61
          aeng Audra Eng [Atlassian] made changes -
          PM Value 2.61 2.46
          supportcountupdater Support Count Updater made changes -
          Support reference count 28 33
          supportcountupdater Support Count Updater made changes -
          Support reference count 31
          Hide
          oleksii.gnatkevych Oleksii Gnatkevych added a comment -

          Two months? Checking the possibility of renaming, running 10-20 SQL's and firing reindexing affected content - two months?

          Show
          oleksii.gnatkevych Oleksii Gnatkevych added a comment - Two months? Checking the possibility of renaming, running 10-20 SQL's and firing reindexing affected content - two months?
          supportcountupdater Support Count Updater made changes -
          Support reference count 31 32
          Hide
          bpatterson Brendan Patterson [Atlassian] added a comment -

          Hi Oleksii,

          I'm guessing that they're talking about adding a layer of abstraction between the username and how it gets used everywhere which is the real fix. This is a big architectural change probably all over the code. PLUS they'd still have to provide the SQL statements you mentioned in a transitionally safe way tested against however many supported databases ~6.

          I'd be surprised if it only took a couple of engineers two months.

          However this is the single biggest Confluence architectural flaw in my opinion and really is worth fixing.

          Show
          bpatterson Brendan Patterson [Atlassian] added a comment - Hi Oleksii, I'm guessing that they're talking about adding a layer of abstraction between the username and how it gets used everywhere which is the real fix. This is a big architectural change probably all over the code. PLUS they'd still have to provide the SQL statements you mentioned in a transitionally safe way tested against however many supported databases ~6. I'd be surprised if it only took a couple of engineers two months. However this is the single biggest Confluence architectural flaw in my opinion and really is worth fixing.
          aeng Audra Eng [Atlassian] made changes -
          Labels user_admin top25
          aeng Audra Eng [Atlassian] made changes -
          Labels top25 User_Admin top25
          Hide
          fst Frank Stiller added a comment -

          Is this fix intended to be fixed in the long term, means rather a Confluence 4.0 than a 3.x? Then i would agree definitely to increase the power of the workaround/documentation of CONF-12437.

          I am currently evaluating how i can change some usernames in confluence, i posted my latest results to the Confluence Page. But i dont find it a good solution that every customer has to do this by himself, for every Confluence Version and for every Database they use. As the official statement there is currently outdated/incomplete i would like to see the mentioned Issue resolved CONF-12437 get the workaround wiki page up to date

          Show
          fst Frank Stiller added a comment - Is this fix intended to be fixed in the long term, means rather a Confluence 4.0 than a 3.x? Then i would agree definitely to increase the power of the workaround/documentation of CONF-12437 . I am currently evaluating how i can change some usernames in confluence, i posted my latest results to the Confluence Page . But i dont find it a good solution that every customer has to do this by himself, for every Confluence Version and for every Database they use . As the official statement there is currently outdated/incomplete i would like to see the mentioned Issue resolved CONF-12437 get the workaround wiki page up to date
          fst Frank Stiller made changes -
          Link This issue causes CONF-12437 [ CONF-12437 ]
          aeng Audra Eng [Atlassian] made changes -
          Labels User_Admin top25 User_Admin mt top25
          pkamal Partha Kamal [Atlassian] made changes -
          Labels User_Admin mt top25 User_Admin bugfix_support_backlog mt top25
          Hide
          upeinelt Uwe Peinelt added a comment -

          More than 4 years of discussion. It's a shame for an "Enterprise Wiki"! Now there is confluence 3.1 with some new features, which aren't really needed but increase the complexity. Have anybody here voted for these new features? I didn't!

          Show
          upeinelt Uwe Peinelt added a comment - More than 4 years of discussion. It's a shame for an "Enterprise Wiki"! Now there is confluence 3.1 with some new features, which aren't really needed but increase the complexity. Have anybody here voted for these new features? I didn't!
          Hide
          nathandunn Nathan Dunn added a comment -

          Though a bit snarky, I think it is a very good point.

          Show
          nathandunn Nathan Dunn added a comment - Though a bit snarky, I think it is a very good point.
          Hide
          jens@atlassian.com Jens Schumacher [Atlassian] added a comment -

          Hi Uwe,

          Be assured that we understand your frustration with this issue and the severity of this architectural flaw. However, as Brendan pointed out, correcting this flaw is a bigger amount of work than most people would estimate and therefore this "feature" will be scheduled like all other features according to our policy:

          http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+Policy

          We started work on improving the general user-management in Confluence and depending on upcoming priorities and the available resources we hope that we will be able to address this issue next year.

          You may not have personally voted for the features in Confluence 3.1, but be assured that we carefully consider all the features that go on the roadmap. Moving pages for example has been a big problem for customers with a large number of pages in a single space and Office 2007 support was a feature people have been asking for on a weekly basis. We sincerely hope that these new features will benefit you as well.

          Show
          jens@atlassian.com Jens Schumacher [Atlassian] added a comment - Hi Uwe, Be assured that we understand your frustration with this issue and the severity of this architectural flaw. However, as Brendan pointed out, correcting this flaw is a bigger amount of work than most people would estimate and therefore this "feature" will be scheduled like all other features according to our policy: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+Policy We started work on improving the general user-management in Confluence and depending on upcoming priorities and the available resources we hope that we will be able to address this issue next year. You may not have personally voted for the features in Confluence 3.1, but be assured that we carefully consider all the features that go on the roadmap. Moving pages for example has been a big problem for customers with a large number of pages in a single space and Office 2007 support was a feature people have been asking for on a weekly basis. We sincerely hope that these new features will benefit you as well.
          Hide
          eluzcando Edgardo Luzcando added a comment - - edited

          While I understand that such a change is difficult and requires a large effort, it is difficult to simply follow instructions such as http://confluence.atlassian.com/display/CONF30/Changing+Usernames (we are currently on 3.0.2) because there is little guarantee that it will work properly since we cannot test on behalf of the users we are impacting. And not providing support for it leaves us in a potentially bad situation.

          In our case we had to integrate to LDAP in order to comply with provisioning and de-provisioning services corporate wide. Now, as usernames are updated in our LDAP, impacted users loose total access to the Confluence application. Because of our strict control to enact production changes and have outages, we have to go through a formal process that takes some time. In the meantime, impacted users don't have access.

          We could give access to these users with a new username (and update with SQL after the fact) to at least give them access quickly, but of course they would loose the ability to see/edit previously owned content.

          If I were in a shop where I could simply go to the production system and stop things and run SQL, or even run SQL while the application is live then I could see how this is not a big deal. Unfortunately for us, this is not the case. I assume this to be true for anyone who has a high maturity level in supporting their production applications. We dependent on our Confluence application for certain things, and expect the application to not require outages to perform maintenance tasks. Or at least minimize outages as much as possible.

          As it was stated earlier, while I appreciate new functionality, not taking care of your "old" customers will simply create a case to abandon the product. Perhaps you can offer support for the SQL alternative? Or have detailed and tested instructions for each release and associated databases? I understand that the feature is not available due to lack of resources and time, but not having a solid alternative makes it difficult for me to ensure my QA department that what I am going to do in production is proven.

          Show
          eluzcando Edgardo Luzcando added a comment - - edited While I understand that such a change is difficult and requires a large effort, it is difficult to simply follow instructions such as http://confluence.atlassian.com/display/CONF30/Changing+Usernames (we are currently on 3.0.2) because there is little guarantee that it will work properly since we cannot test on behalf of the users we are impacting. And not providing support for it leaves us in a potentially bad situation. In our case we had to integrate to LDAP in order to comply with provisioning and de-provisioning services corporate wide. Now, as usernames are updated in our LDAP, impacted users loose total access to the Confluence application. Because of our strict control to enact production changes and have outages, we have to go through a formal process that takes some time. In the meantime, impacted users don't have access. We could give access to these users with a new username (and update with SQL after the fact) to at least give them access quickly, but of course they would loose the ability to see/edit previously owned content. If I were in a shop where I could simply go to the production system and stop things and run SQL, or even run SQL while the application is live then I could see how this is not a big deal. Unfortunately for us, this is not the case. I assume this to be true for anyone who has a high maturity level in supporting their production applications. We dependent on our Confluence application for certain things, and expect the application to not require outages to perform maintenance tasks. Or at least minimize outages as much as possible. As it was stated earlier, while I appreciate new functionality, not taking care of your "old" customers will simply create a case to abandon the product. Perhaps you can offer support for the SQL alternative? Or have detailed and tested instructions for each release and associated databases? I understand that the feature is not available due to lack of resources and time, but not having a solid alternative makes it difficult for me to ensure my QA department that what I am going to do in production is proven.
          Hide
          mhaderman@sonomatech.com Michael Haderman added a comment -

          This has been open for 5 years? I've used the trial application for ten minutes and already I need to change someone's username. As a database developer I'm shocked that you aren't using IDs. My company is currently trying to determine which application we would like to use for bug tracking and this alone makes me wary of recommending Jira.

          Show
          mhaderman@sonomatech.com Michael Haderman added a comment - This has been open for 5 years? I've used the trial application for ten minutes and already I need to change someone's username. As a database developer I'm shocked that you aren't using IDs. My company is currently trying to determine which application we would like to use for bug tracking and this alone makes me wary of recommending Jira.
          pkamal Partha Kamal [Atlassian] made changes -
          Labels User_Admin bugfix_support_backlog mt top25 User_Admin mt top25
          pkamal Partha Kamal [Atlassian] made changes -
          Labels User_Admin mt top25 User_Admin mt pm_review top25
          smansour Sherif Mansour [Atlassian] made changes -
          Link This issue blocks CONF-17212 [ CONF-17212 ]
          pkamal Partha Kamal [Atlassian] made changes -
          Link This issue causes CONF-18568 [ CONF-18568 ]
          smansour Sherif Mansour [Atlassian] made changes -
          Link This issue blocks CONF-18403 [ CONF-18403 ]
          nbhawnani Niraj Bhawnani [Atlassian] made changes -
          Link This issue blocks CONF-18403 [ CONF-18403 ]
          jclark@atlassian.com Joseph Clark [Atlassian] made changes -
          Link This issue blocks CONF-20157 [ CONF-20157 ]
          rkrishna Roy Krishna [Atlassian] made changes -
          Workflow Quality Review Flow [ 144897 ] PM Feature Request Workflow [ 234827 ]
          Hide
          lai Liya AI added a comment -

          Is that true "every customer has to do this by himself, for every Confluence Version and for every Database they use." or technical support need to do the change for every customer for every Confluence Version and for every Database they use? That is TOO much. Any updates?

          Show
          lai Liya AI added a comment - Is that true "every customer has to do this by himself, for every Confluence Version and for every Database they use." or technical support need to do the change for every customer for every Confluence Version and for every Database they use? That is TOO much. Any updates?
          Hide
          mjdowney Michael Downey added a comment -

          Sigh. This issue has been open five (!!) years. JIRA has the same problems (see JRA-1549). As Edgardo stated, this is extremely frustrating, challenging, and time-consuming for organizations that use external user management and have change control processes in place. Can we get an update on where this fits in to Confluence's roadmap, such as the JIRA team did for JRA-1549? Thanks.

          Show
          mjdowney Michael Downey added a comment - Sigh. This issue has been open five (!!) years. JIRA has the same problems (see JRA-1549 ). As Edgardo stated, this is extremely frustrating, challenging, and time-consuming for organizations that use external user management and have change control processes in place. Can we get an update on where this fits in to Confluence's roadmap, such as the JIRA team did for JRA-1549 ? Thanks.
          Hide
          rp Ronny Pettersen added a comment -

          This issue is at the moment #8 in the top voted list, so I would assume Atlassian is working to get this resolved very soon.
          All of the top 30 voted unresolved issues are more than 4 years old, so it doesn't look good. I thought voting would give Atlassian some idea of what is important for the customers.

          Show
          rp Ronny Pettersen added a comment - This issue is at the moment #8 in the top voted list, so I would assume Atlassian is working to get this resolved very soon. All of the top 30 voted unresolved issues are more than 4 years old, so it doesn't look good. I thought voting would give Atlassian some idea of what is important for the customers.
          Hide
          ncarbonneau Normand Carbonneau added a comment -

          One important thing to remember is that the developer's wish list, or what the developers think would be fun to code must NEVER prevail on what customers really need. This is a golden rule that we, as developers, often forget...
          In the last releases, there were several nice to have things that were added, but that are really VERY FAR in the importance list, and on the other side, the things that are important in our day to day work are not taken into consideration at all by Atlassian.

          This is really disappointing because you really have a GREAT software.

          Show
          ncarbonneau Normand Carbonneau added a comment - One important thing to remember is that the developer's wish list, or what the developers think would be fun to code must NEVER prevail on what customers really need. This is a golden rule that we, as developers, often forget... In the last releases, there were several nice to have things that were added, but that are really VERY FAR in the importance list, and on the other side, the things that are important in our day to day work are not taken into consideration at all by Atlassian. This is really disappointing because you really have a GREAT software.
          Hide
          bkozumplik@mint.com Brian Kozumplik added a comment -

          This is awful. If not username change, need to have a way to reassign ticket refrences from one user to another.

          Show
          bkozumplik@mint.com Brian Kozumplik added a comment - This is awful. If not username change, need to have a way to reassign ticket refrences from one user to another.
          Hide
          sschoonveld Steffen Schoonveld added a comment -

          I'm struggling with this issue on Jira, Confluence and Bamboo. My client decided to use LDAP authentication after the application instances are used for two years. The internal user directory grew up to 400+ users. Finding and replacing in XML export files is a nightmare when your export is over 2.000.000 lines, you have more the 400 user and they can occur up to 5.000 it the XML file. Do the math!

          This is a serious issue. LDAP integration on existing instances is virtually impossible this way, at least way to buggy!

          I voted and hope this one finally get's implemented!!

          Show
          sschoonveld Steffen Schoonveld added a comment - I'm struggling with this issue on Jira, Confluence and Bamboo. My client decided to use LDAP authentication after the application instances are used for two years. The internal user directory grew up to 400+ users. Finding and replacing in XML export files is a nightmare when your export is over 2.000.000 lines, you have more the 400 user and they can occur up to 5.000 it the XML file. Do the math! This is a serious issue. LDAP integration on existing instances is virtually impossible this way, at least way to buggy! I voted and hope this one finally get's implemented!!
          Hide
          carsten.heidmann Carsten Heidmann added a comment -

          This issue has been created 6 (six) years ago. The last comment from someone from Atlassian ist dated 10/Dec/09, saying that

          ... we hope that we will be able to address this issue next year ...

          So - 2010 has passed away, bringing lot of nice little features in Confluence and JIRA which for sure are not so important as this one. Could someone from Atlassian at least comment on the recent developments of this issue? I hope the fact that it is labelled top25 means something?

          Show
          carsten.heidmann Carsten Heidmann added a comment - This issue has been created 6 (six) years ago. The last comment from someone from Atlassian ist dated 10/Dec/09, saying that ... we hope that we will be able to address this issue next year ... So - 2010 has passed away, bringing lot of nice little features in Confluence and JIRA which for sure are not so important as this one. Could someone from Atlassian at least comment on the recent developments of this issue? I hope the fact that it is labelled top25 means something?
          Hide
          agosselin@elt-inc.com Tony Gosselin added a comment -

          Just to reiterate what Steffen said, doing an export and search / replace to correct this issue isn't a viable fix for something that comes up as often as this does (especially given how prone that solution is to error). Please give us an update on this issue; the new features are great but this is a huge sore spot for the folks who actually have to administer the product, and it makes it tough for me to evangelize this product (which I otherwise love) to other back-office IT colleagues when core bugs like this go unaddressed for years on end.

          Show
          agosselin@elt-inc.com Tony Gosselin added a comment - Just to reiterate what Steffen said, doing an export and search / replace to correct this issue isn't a viable fix for something that comes up as often as this does (especially given how prone that solution is to error). Please give us an update on this issue; the new features are great but this is a huge sore spot for the folks who actually have to administer the product, and it makes it tough for me to evangelize this product (which I otherwise love) to other back-office IT colleagues when core bugs like this go unaddressed for years on end.
          Hide
          mjdowney Michael Downey added a comment -

          +1. No, +infinity. Every time I talk about the good stuff Atlassian does, I always give the caveat that, despite all the cool stuff, they seem unable or unwilling to ever address common sense, basic stuff like changing usernames in an enterprise system. This issue (across all Atlassian products) is nothing less than epic fail.

          Show
          mjdowney Michael Downey added a comment - +1. No, +infinity. Every time I talk about the good stuff Atlassian does, I always give the caveat that, despite all the cool stuff, they seem unable or unwilling to ever address common sense, basic stuff like changing usernames in an enterprise system. This issue (across all Atlassian products) is nothing less than epic fail.
          Hide
          bkozumplik@mint.com Brian Kozumplik added a comment -

          agreed. This is awful, gross lack of a basic functionality requirement. Whoever drew up the spec should get canned. And why is this sore spot continually ignored? Atlassian? Whats the problem exactly?
          This is a big red flag for my organization when evalling the "crowd" module. If they cant get this even close to right, why should they be trusted with creds of any kind. This needs to be fixed.

          Show
          bkozumplik@mint.com Brian Kozumplik added a comment - agreed. This is awful, gross lack of a basic functionality requirement. Whoever drew up the spec should get canned. And why is this sore spot continually ignored? Atlassian? Whats the problem exactly? This is a big red flag for my organization when evalling the "crowd" module. If they cant get this even close to right, why should they be trusted with creds of any kind. This needs to be fixed.
          Hide
          jujaehrig@cyberport.de Jens Jährig added a comment -

          I have to totally agree. It's a shame for atlassian to not address this issue.

          Show
          jujaehrig@cyberport.de Jens Jährig added a comment - I have to totally agree. It's a shame for atlassian to not address this issue.
          Hide
          barconati Bill Arconati added a comment -

          added PM status.

          Show
          barconati Bill Arconati added a comment - added PM status.
          barconati Bill Arconati made changes -
          Description Confluence does not provide a function to change the username via the web or remote interface.

          Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key. Therefore if you need to update the username, you will have to update every occurrence of the username used as foreign key in all tables. This procedure should be automated to avoid corruption in the database due to mistakes made in the process.
          Confluence does not provide a function to change the username via the web or remote interface.

          Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key. Therefore if you need to update the username, you will have to update every occurrence of the username used as foreign key in all tables. This procedure should be automated to avoid corruption in the database due to mistakes made in the process.

          {panel:title=Atlassian Status as of July 1, 2011|borderStyle=solid|borderColor=#3C78B5| titleBGColor=#3C78B5| bgColor=#E7F4FA}
          Hi All,
          Thanks for your feedback on this issue thus far. We acknowledge that administrators need a way to change usernames within the system. *Please note, that users can still* *[change their Full Name|http://confluence.atlassian.com/display/DOC/Editing+User+Profile]* *as it appears in the Confluence user interface.* For example, a user can change his Full Name from _Bill Arconati_ to _John Smith_ but currently can't change his username from _barconati_ to _jsmith_.

          At this stage we do not have a supported way to change the username in your system. However, we've [documented|http://confluence.atlassian.com/display/DOC/Changing+Usernames] a series of SQL scripts to allow an administrator to update a username directly inside the Confluence database. Please note that the *process is not supported* but a number of customers have been successful with them.

          We hope to provide a more eloquent way of updating usernames in the future but have no immediate plans to do so at this time. We will update the status of this issue once we have made further progress.

          Thank you for your patience.
          Bill Arconati
          {panel}
          Hide
          carsten.heidmann Carsten Heidmann added a comment -

          @Bill Arconati
          Bill, thanks for giving at least a status update on this issue. Atlassians answer on this issue (which is labelled as top25 for some reason) is however not satisfiying for those commenting on it. I am pretty sure that every single one is aware of the unsupported SQL scripts and also of the fact that the display name is changeable (which is, I have to say, completely irrelevant for this issue). I really do like Atlassian products, but this issue is so annoying and, as some of the previous comments said, this puts Atlassian in a really bad light from the focus of Enterprise-ready software. Our patience lasted now for 6 years - please see to it, that there will not be added more years on top of it.

          Show
          carsten.heidmann Carsten Heidmann added a comment - @Bill Arconati Bill, thanks for giving at least a status update on this issue. Atlassians answer on this issue (which is labelled as top25 for some reason) is however not satisfiying for those commenting on it. I am pretty sure that every single one is aware of the unsupported SQL scripts and also of the fact that the display name is changeable (which is, I have to say, completely irrelevant for this issue). I really do like Atlassian products, but this issue is so annoying and, as some of the previous comments said, this puts Atlassian in a really bad light from the focus of Enterprise-ready software. Our patience lasted now for 6 years - please see to it, that there will not be added more years on top of it.
          Hide
          michjosi Michael Jositz added a comment -

          The update in my opinion is very disappointing, no immediate plans to provide this functionality? As Carsten said chnaging the Full Name is completely irrelevant here. We are more and more facing this issue and IT is in big trouble to explain why we can't change the login name! Unsupported scripts are not allowed for a good reason in a big company like I work for. I guess the issue will stay unresolved another few years, the updated description is not very promissing...

          Show
          michjosi Michael Jositz added a comment - The update in my opinion is very disappointing, no immediate plans to provide this functionality? As Carsten said chnaging the Full Name is completely irrelevant here. We are more and more facing this issue and IT is in big trouble to explain why we can't change the login name! Unsupported scripts are not allowed for a good reason in a big company like I work for. I guess the issue will stay unresolved another few years, the updated description is not very promissing...
          Hide
          mjdowney Michael Downey added a comment -

          Not a week goes by that we don't get questions from our organization (1000+ users) as to why user accounts can't be renamed. It's disappointing how I have to explain the reasons every time, not to mention embarrassing to Atlassian – not only the poor design decision, but the fact it has gone ignored for OVER SEVEN (7) YEARS. This is absolutely not acceptable for enterprise software.

          Show
          mjdowney Michael Downey added a comment - Not a week goes by that we don't get questions from our organization (1000+ users) as to why user accounts can't be renamed. It's disappointing how I have to explain the reasons every time, not to mention embarrassing to Atlassian – not only the poor design decision, but the fact it has gone ignored for OVER SEVEN (7) YEARS. This is absolutely not acceptable for enterprise software.
          Hide
          ewells Eric Wells added a comment - - edited

          Fundamentally, it is poor database design. A cardinal rule is that the primary key should always be a meaningless key, then things with business value (such as username) are stored in the record as a business key (potentially even unquie) but not as the primary key. With this approach you'd be able to change the username in one place very easily.

          As it is, changing the business key that's also functioning as a primary key involves making the same exact change to all the records in all the various tables that use this "key", plus dealing with any constraints that might make such a change difficult (you may have to drop the constraints, do the work, then put them back... but dropping the constraints allow you to really mess things up good!). This is tricky, and with all the databases Confluence supports, it becomes a risky venture, something I can understand why they wouldn't want to support.

          The catch is that making the correction in a future release is almost as risky. You'd need to add a new key column (preferably numeric) to all those same tables, then assign them all the correct values, then purge username from all but the single user table. And again, constraints and referential integrity would be tricky and risky. And that doesn't even count all the macros and APIs and whatever else that would need to be re-written.

          Basically, by starting out with a bad design, they have dug themselves into a hole. And it's only getting deeper.

          Show
          ewells Eric Wells added a comment - - edited Fundamentally, it is poor database design. A cardinal rule is that the primary key should always be a meaningless key, then things with business value (such as username) are stored in the record as a business key (potentially even unquie) but not as the primary key. With this approach you'd be able to change the username in one place very easily. As it is, changing the business key that's also functioning as a primary key involves making the same exact change to all the records in all the various tables that use this "key", plus dealing with any constraints that might make such a change difficult (you may have to drop the constraints, do the work, then put them back... but dropping the constraints allow you to really mess things up good!). This is tricky, and with all the databases Confluence supports, it becomes a risky venture, something I can understand why they wouldn't want to support. The catch is that making the correction in a future release is almost as risky. You'd need to add a new key column (preferably numeric) to all those same tables, then assign them all the correct values, then purge username from all but the single user table. And again, constraints and referential integrity would be tricky and risky. And that doesn't even count all the macros and APIs and whatever else that would need to be re-written. Basically, by starting out with a bad design, they have dug themselves into a hole. And it's only getting deeper.
          Hide
          mdoar Matt Doar (ServiceRocket) added a comment -

          @Eric - I suspect the original decision was due to supporting multiple authentication services, where the username is what is unique across all services. Using an approach of an ID in one database doesn't work so well for that.

          ~Matt

          Show
          mdoar Matt Doar (ServiceRocket) added a comment - @Eric - I suspect the original decision was due to supporting multiple authentication services, where the username is what is unique across all services. Using an approach of an ID in one database doesn't work so well for that. ~Matt
          Hide
          forceten Rick Hadsall added a comment -

          Why? It's just as easy to accept the foreign auth service's username and still provide insulation. You essentially treat the internal source as an foreign source and reference it. Where it comes from is irrelevant.

          Show
          forceten Rick Hadsall added a comment - Why? It's just as easy to accept the foreign auth service's username and still provide insulation. You essentially treat the internal source as an foreign source and reference it. Where it comes from is irrelevant.
          Hide
          ewells Eric Wells added a comment -

          @Matt, you may be right. But that's resolved by having a simple crossref table with the username and ID as the only two columns in the table. The rest of the system works on the ID and the username gets isolated in one place, once again making it relatively easy to change if needed (it's only in one place).

          But to your bigger point, you're right, I should reserve knee-jerk judgment until I know all the issues they faced and the rationale behind the compromise they took. Maybe it was a lesser-of-all-evils deal. But I have to believe there was a better way.

          Show
          ewells Eric Wells added a comment - @Matt, you may be right. But that's resolved by having a simple crossref table with the username and ID as the only two columns in the table. The rest of the system works on the ID and the username gets isolated in one place, once again making it relatively easy to change if needed (it's only in one place). But to your bigger point, you're right, I should reserve knee-jerk judgment until I know all the issues they faced and the rationale behind the compromise they took. Maybe it was a lesser-of-all-evils deal. But I have to believe there was a better way.
          Hide
          ewells Eric Wells added a comment -

          @Rick, good point, that's an even better solution.

          Show
          ewells Eric Wells added a comment - @Rick, good point, that's an even better solution.
          matt@atlassian.com Matt Ryall [Atlassian] made changes -
          Workflow PM Feature Request Workflow [ 234827 ] Confluence Default Workflow [ 337612 ]
          Hide
          silvana.pulicari@cervedgroup.com Silvana Pulicari added a comment -

          We are planning migration of all users to another repository where all usernames are different
          Doing this operation with Atlassian support would be very important
          thank you

          Show
          silvana.pulicari@cervedgroup.com Silvana Pulicari added a comment - We are planning migration of all users to another repository where all usernames are different Doing this operation with Atlassian support would be very important thank you
          Hide
          paulina1976 Paula Winkler added a comment -

          We are planning to upgrade from 500 to 2000 Users. Almost every week somebody marries and changes his or her name. Then the username from LDAP also changes. It would be very useful to have that feature.
          Thank you.

          Show
          paulina1976 Paula Winkler added a comment - We are planning to upgrade from 500 to 2000 Users. Almost every week somebody marries and changes his or her name. Then the username from LDAP also changes. It would be very useful to have that feature. Thank you.
          Hide
          soeren Sören Sauerland added a comment -

          We are now in migration phase of all users in our active directory, so nearly every userid changes.
          So it would be VERY useful to have that NICE feature.
          Thank you.

          Show
          soeren Sören Sauerland added a comment - We are now in migration phase of all users in our active directory, so nearly every userid changes. So it would be VERY useful to have that NICE feature. Thank you.
          Hide
          bkozumplik@mint.com Brian Kozumplik added a comment -

          So unsupported sql scripts is the answer? Can I ask, why cant you put your stamp of approval on them and support them? I remember reading somewhere that not only are these "unsupported" they are "not reccomended". Can you help us understand what might go wrong? I hate the idea that I could make changes and then later revisit them having had people add content that cant be lost.

          Show
          bkozumplik@mint.com Brian Kozumplik added a comment - So unsupported sql scripts is the answer? Can I ask, why cant you put your stamp of approval on them and support them? I remember reading somewhere that not only are these "unsupported" they are "not reccomended". Can you help us understand what might go wrong? I hate the idea that I could make changes and then later revisit them having had people add content that cant be lost.
          Hide
          daniel.pardes@equinox.com Daniel Pardes added a comment -

          These scripts are seriously out of date. Can you please update them and include a version for each of the supported databases? We (like many companies) are trying to grow WITH and not OUT OF Atlassian's software. Being able to switch to LDAP is a very important feature and this is preventing us from doing so. Thanks for your help!

          Show
          daniel.pardes@equinox.com Daniel Pardes added a comment - These scripts are seriously out of date. Can you please update them and include a version for each of the supported databases? We (like many companies) are trying to grow WITH and not OUT OF Atlassian's software. Being able to switch to LDAP is a very important feature and this is preventing us from doing so. Thanks for your help!
          mseager Michael Seager [Atlassian] made changes -
          Remote Link This issue links to "Wiki Page (Extranet)" [ 15105 ]
          mseager Michael Seager [Atlassian] made changes -
          Labels User_Admin mt pm_review top25 User_Admin conf_support_backlog_pa mt pm_review top25
          Hide
          jfireham J Fire added a comment -

          When one company buys another, which happens fairly often, they often try to get everyone on the same directory server. We cannot do this until we can rename users. It makes zero sense that enterprise software like atlassian's does not support this. I know it's hard, but if you can't find cycles to fix your schema so that the username is an column rather than a key, at least put in cycles to write and test SQL scripts to do so, at least for the latest supported version. "Come on, man."

          Show
          jfireham J Fire added a comment - When one company buys another, which happens fairly often, they often try to get everyone on the same directory server. We cannot do this until we can rename users. It makes zero sense that enterprise software like atlassian's does not support this. I know it's hard , but if you can't find cycles to fix your schema so that the username is an column rather than a key, at least put in cycles to write and test SQL scripts to do so, at least for the latest supported version. "Come on, man."
          Hide
          sheppe.pharis@disney.com Sheppe Pharis added a comment -

          I'm in exactly the situation described by J Fire, except the company I work for has bought several other companies. Please Atlassian, get this issue resolved sooner rather than later!

          Show
          sheppe.pharis@disney.com Sheppe Pharis added a comment - I'm in exactly the situation described by J Fire, except the company I work for has bought several other companies. Please Atlassian, get this issue resolved sooner rather than later!
          Hide
          jderksenco jderksen added a comment -

          We need to change user names in Confluence occasionally. We are synching with LDAP, and the username we are tied to in LDAP do sometimes change. This is out of our control. We need to be able to have Confluence follow suit,and synch to the new user name in a way that preserve's the user's existing content under their new username. At least have someone unofficially tracking on the posted SQL and updating for new versions. Thanks

          Show
          jderksenco jderksen added a comment - We need to change user names in Confluence occasionally. We are synching with LDAP, and the username we are tied to in LDAP do sometimes change. This is out of our control. We need to be able to have Confluence follow suit,and synch to the new user name in a way that preserve's the user's existing content under their new username. At least have someone unofficially tracking on the posted SQL and updating for new versions. Thanks
          barconati Bill Arconati made changes -
          Remote Link This issue links to "Wiki Page (Pug)" [ 16481 ]
          dunterwurzacher Denise Unterwurzacher [Atlassian] made changes -
          Labels User_Admin conf_support_backlog_pa mt pm_review top25 User_Admin mt pm_review top25
          barconati Bill Arconati made changes -
          Labels User_Admin mt pm_review top25 User_Admin enterprise mt pm_review top25
          barconati Bill Arconati made changes -
          Rank Ranked higher
          barconati Bill Arconati made changes -
          Remote Link This issue links to "Wiki Page (Pug)" [ 22563 ]
          barconati Bill Arconati made changes -
          Labels User_Admin enterprise mt pm_review top25 User_Admin enterprise manage-users mt pm_review top25
          barconati Bill Arconati made changes -
          Link This issue is related to CONFDEV-10808 [ CONFDEV-10808 ]
          barconati Bill Arconati made changes -
          Epic Link CONFDEV-10808 [ 208275 ]
          barconati Bill Arconati made changes -
          Description Confluence does not provide a function to change the username via the web or remote interface.

          Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key. Therefore if you need to update the username, you will have to update every occurrence of the username used as foreign key in all tables. This procedure should be automated to avoid corruption in the database due to mistakes made in the process.

          {panel:title=Atlassian Status as of July 1, 2011|borderStyle=solid|borderColor=#3C78B5| titleBGColor=#3C78B5| bgColor=#E7F4FA}
          Hi All,
          Thanks for your feedback on this issue thus far. We acknowledge that administrators need a way to change usernames within the system. *Please note, that users can still* *[change their Full Name|http://confluence.atlassian.com/display/DOC/Editing+User+Profile]* *as it appears in the Confluence user interface.* For example, a user can change his Full Name from _Bill Arconati_ to _John Smith_ but currently can't change his username from _barconati_ to _jsmith_.

          At this stage we do not have a supported way to change the username in your system. However, we've [documented|http://confluence.atlassian.com/display/DOC/Changing+Usernames] a series of SQL scripts to allow an administrator to update a username directly inside the Confluence database. Please note that the *process is not supported* but a number of customers have been successful with them.

          We hope to provide a more eloquent way of updating usernames in the future but have no immediate plans to do so at this time. We will update the status of this issue once we have made further progress.

          Thank you for your patience.
          Bill Arconati
          {panel}
          Confluence does not provide a function to change the username via the web or remote interface.

          Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key. Therefore if you need to update the username, you will have to update every occurrence of the username used as foreign key in all tables. This procedure should be automated to avoid corruption in the database due to mistakes made in the process.

          {panel:title=Atlassian Status as of January 22, 2013|borderStyle=solid|borderColor=#3C78B5| titleBGColor=#3C78B5| bgColor=#E7F4FA}
          Hi All,
          Thanks for your feedback on this issue thus far. We acknowledge that administrators need a way to change usernames within the system. *Please note, that users can still* *[change their Full Name|http://confluence.atlassian.com/display/DOC/Editing+User+Profile]* *as it appears in the Confluence user interface.* For example, a user can change his Full Name from _Bill Arconati_ to _John Smith_ but currently can't change his username from _barconati_ to _jsmith_.

          At this stage we do not have a supported way to change the username in your system. However, we've [documented|http://confluence.atlassian.com/display/DOC/Changing+Usernames] a series of SQL scripts to allow an administrator to update a username directly inside the Confluence database. Please note that the *process is not supported* but a number of customers have been successful with them.

          We have started exploring solutions to this complex issue and hope to provide a more eloquent way of updating usernames within the next year. We will update the status of this issue once we have made further progress.

          Thank you for your patience.
          Bill Arconati
          {panel}
          Hide
          sven.lecherbonnier Sven Lecherbonnier added a comment -

          We plan to standardize our username to got on SSO.
          We are looking for a proper solution not SQL solution.

          Could you please confirm if that functionality will be in JIRA 6 ?

          Show
          sven.lecherbonnier Sven Lecherbonnier added a comment - We plan to standardize our username to got on SSO. We are looking for a proper solution not SQL solution. Could you please confirm if that functionality will be in JIRA 6 ?
          Hide
          joris vandermeersch Joris Vandermeersch added a comment -

          Sven: This issue is about Confluence, not JIRA. JIRA currently already has this functionality, in built-in scripts in the Admin panel.

          Show
          joris vandermeersch Joris Vandermeersch added a comment - Sven: This issue is about Confluence, not JIRA. JIRA currently already has this functionality, in built-in scripts in the Admin panel.
          Hide
          sven.lecherbonnier Sven Lecherbonnier added a comment -

          Oops my apologize.

          Show
          sven.lecherbonnier Sven Lecherbonnier added a comment - Oops my apologize.
          Hide
          jfireham J Fire added a comment - - edited

          @Sven Lecherbonnier since when? At one time there was a plugin but it was not complete and I think Atlassian said it should not be used. JIRA has the same issue in that the PK is the username, not an ID.

          Show
          jfireham J Fire added a comment - - edited @Sven Lecherbonnier since when? At one time there was a plugin but it was not complete and I think Atlassian said it should not be used. JIRA has the same issue in that the PK is the username, not an ID.
          Hide
          jfireham J Fire added a comment -

          Bill, there is only one way to fix this. The original statement says

          Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key.

          however, it is that very reason that you use use an ID!.

          This is how it should work, along with a use case:

          • When using, say, Crowd, when the user database is synced, if there is no user entry, one is created in the Confluence database with a unique ID as PK. So let's say my username is 'joel' in my LDAP directory, which is a directory in Crowd.
          • This ID is used wherever username is now used.
          • Now, say, my company is bought. They specify that my username in their LDAP directory is 'jfireham'. Months later they require that our old LDAP directory must be phased out.
          • So now, we add the new LDAP server to Crowd. In Confluence, I go the entry for 'joel', and change the username to 'jfireham'. Since the username is simply a column on that table, and does not appear anywhere else, it is that easy.

          This is the only correct solution to the problem. You must figure out how to upgrade the schema on the next major release of Confluence. Otherwise I cannot justify continuing to renew my license so that I get newer versions. This is simply a requirement of enterprise software. The use case I presented is quite common, and it's causing us significant pain.

          Show
          jfireham J Fire added a comment - Bill, there is only one way to fix this. The original statement says Since it is not guaranteed that users will be stored in the confluence database (eg. using external user management), the username instead of an id is used as the foreign key. however, it is that very reason that you use use an ID!. This is how it should work, along with a use case: When using, say, Crowd, when the user database is synced, if there is no user entry, one is created in the Confluence database with a unique ID as PK. So let's say my username is 'joel' in my LDAP directory, which is a directory in Crowd. This ID is used wherever username is now used. Now, say, my company is bought. They specify that my username in their LDAP directory is 'jfireham'. Months later they require that our old LDAP directory must be phased out. So now, we add the new LDAP server to Crowd. In Confluence, I go the entry for 'joel', and change the username to 'jfireham'. Since the username is simply a column on that table, and does not appear anywhere else, it is that easy. This is the only correct solution to the problem. You must figure out how to upgrade the schema on the next major release of Confluence. Otherwise I cannot justify continuing to renew my license so that I get newer versions. This is simply a requirement of enterprise software. The use case I presented is quite common, and it's causing us significant pain.
          Hide
          joris vandermeersch Joris Vandermeersch added a comment -

          Now that you mention it, it seems indeed to be a plugin in our JIRA instance that provides this functionality. I've used it a couple of times though, I'm not sure if and why Atlassian has said not to use it but it seems to work fine here. I do agree that it should be a built-in functionality though...

          Show
          joris vandermeersch Joris Vandermeersch added a comment - Now that you mention it, it seems indeed to be a plugin in our JIRA instance that provides this functionality. I've used it a couple of times though, I'm not sure if and why Atlassian has said not to use it but it seems to work fine here. I do agree that it should be a built-in functionality though...
          Hide
          gajan83 Gaj added a comment - - edited

          Hi,

          We currently have several accounts on Confluence which are on the local directory. A username on the local directory as an example will be 'jsmith', we now wish to connect our LDAP to the confluence but our LDAP username is different and this is called 'john.smith'. jsmith has several contents he is the owner off but we now want to rename the local userid 'jsmith' to be the LDAP user ID 'john.smith'. Is there a way to do this without using any SSO user management systems that can handle alias?

          I tried changing the id in cwd_user table so that the id of jsmith was changed to have the id of john.smith and then did a full reindex but it didn't work. I thought the id is the primary key so changing just this should change everything.

          I'm using Confluence 4.21 on a SQL server database.

          Cheers,
          Gaj

          Update - okay i see it's not as straight forward as changing the id because the username is what's being used in all the tables in confluence rather than the id. What I don't understand is why this is such a difficult fix for Atlassian so that all the tables that have usernames use the id instead.

          Show
          gajan83 Gaj added a comment - - edited Hi, We currently have several accounts on Confluence which are on the local directory. A username on the local directory as an example will be 'jsmith', we now wish to connect our LDAP to the confluence but our LDAP username is different and this is called 'john.smith'. jsmith has several contents he is the owner off but we now want to rename the local userid 'jsmith' to be the LDAP user ID 'john.smith'. Is there a way to do this without using any SSO user management systems that can handle alias? I tried changing the id in cwd_user table so that the id of jsmith was changed to have the id of john.smith and then did a full reindex but it didn't work. I thought the id is the primary key so changing just this should change everything. I'm using Confluence 4.21 on a SQL server database. Cheers, Gaj Update - okay i see it's not as straight forward as changing the id because the username is what's being used in all the tables in confluence rather than the id. What I don't understand is why this is such a difficult fix for Atlassian so that all the tables that have usernames use the id instead.
          akazatchkov.adm Anatoli Kazatchkov [Administrative Account] made changes -
          Workflow Confluence Default Workflow [ 337612 ] New Confluence Default Workflow [ 485668 ]
          mhodges Matt Hodges [Atlassian] made changes -
          Remote Link This issue links to "Wiki Page (Extranet)" [ 41216 ]
          mhodges Matt Hodges [Atlassian] made changes -
          Remote Link This issue links to "Wiki Page (Extranet)" [ 41429 ]
          pcurren Paul Curren made changes -
          Rank Ranked lower
          Hide
          administrator6 Administrator@webcourseworks.com added a comment -

          You call this a feature? Basic user management? AD/Crowd/and user management is just broken. I need to maintain past employees indefinitely. And yes I made the mistake of changing a user's name when she was married. It was a week before we had the mess sorted out. If you remove a user from AD, then any ticket that was associated with that user becomes non functional. past present and future. I understand there needs to be a solution but it would seem this isn't going anywhere. I see my past tickets for this issue do not even exist anymore.

          Show
          administrator6 Administrator@webcourseworks.com added a comment - You call this a feature? Basic user management? AD/Crowd/and user management is just broken. I need to maintain past employees indefinitely. And yes I made the mistake of changing a user's name when she was married. It was a week before we had the mess sorted out. If you remove a user from AD, then any ticket that was associated with that user becomes non functional. past present and future. I understand there needs to be a solution but it would seem this isn't going anywhere. I see my past tickets for this issue do not even exist anymore.
          Hide
          mrjcleaver Martin Cleaver [Blended Perspectives] added a comment -

          Confluence 5.2 has some new support for renaming usernames.

          It's not released yet but there does exist a beta.

          Show
          mrjcleaver Martin Cleaver [Blended Perspectives] added a comment - Confluence 5.2 has some new support for renaming usernames. It's not released yet but there does exist a beta.
          Hide
          administrator6 Administrator@webcourseworks.com added a comment -

          good to hear, will this support include Crowd, JIRA, LDAP/AD integration?

          Thanks,

          Show
          administrator6 Administrator@webcourseworks.com added a comment - good to hear, will this support include Crowd, JIRA, LDAP/AD integration? Thanks,
          Hide
          jimbirch Jim Birch added a comment -

          In the ldap, a common circumstance would be
          1. ldap user (v1) logs into Confluence and gets a local Confluence ID.
          2. ldap user gets married (etc) and changes login name and display name
          3. ldap user (v2) logs into Confluence using new ID (or, is logged in automatically by SSO) and generates a new Confluence ID.
          4. User has two separate IDs, current and historical

          In this situation, we really want to be able MERGE the two IDs than rename an ID. This might be seem semantic, but we really need to be able to change all reference to the old account to match a new one even if it exists or we don't have a solution.

          ===

          In the case of Active Directory the ideal solution would be to read the user's objectGUID into the Confluence directory as an invariant object attribute. This 128bit AD attribute is unique not just in that Active Directory but in the universe and persists for the life of the AD object. What more could you possibly want! AD has its problems but the use of GUIDs really works brilliantly in identity management and provides a high level of reliability across renames.

          When a user logs in with a new name but with a known GUID, the account could actually be automatically renamed using the new source name attributes. Maybe a checkbox to authorise AD as a The Source of Truth for identities and permit automatic renames might allay fears, but this is what should happen, seamlessly. Doing anything else - that is, what some generalized GUIDless-multidirectory safe might process require - constitutes integration failure. I don't know your numbers, but I would expect that Confluence with a single external AD constitutes a significant chunk of your ldap installations so this option would be kill a lot of birds with a single stone.

          AFAICS the exception condition where an attempt to rename clashes with an existing name should actually halt and produce an exception report. In the above scenario it should never happen but if it does the solution will likely require some thinking, reconfiguration and/or changes outside Confluence.

          This doesn't solve the myriad of problems that can arise with multiple directories that don't have unique persistent identifiers but a configuration that supports this approach should form a part of the solution.

          Show
          jimbirch Jim Birch added a comment - In the ldap, a common circumstance would be 1. ldap user (v1) logs into Confluence and gets a local Confluence ID. 2. ldap user gets married (etc) and changes login name and display name 3. ldap user (v2) logs into Confluence using new ID (or, is logged in automatically by SSO) and generates a new Confluence ID. 4. User has two separate IDs, current and historical In this situation, we really want to be able MERGE the two IDs than rename an ID. This might be seem semantic, but we really need to be able to change all reference to the old account to match a new one even if it exists or we don't have a solution. === In the case of Active Directory the ideal solution would be to read the user's objectGUID into the Confluence directory as an invariant object attribute. This 128bit AD attribute is unique not just in that Active Directory but in the universe and persists for the life of the AD object. What more could you possibly want! AD has its problems but the use of GUIDs really works brilliantly in identity management and provides a high level of reliability across renames. When a user logs in with a new name but with a known GUID, the account could actually be automatically renamed using the new source name attributes. Maybe a checkbox to authorise AD as a The Source of Truth for identities and permit automatic renames might allay fears, but this is what should happen, seamlessly. Doing anything else - that is, what some generalized GUIDless-multidirectory safe might process require - constitutes integration failure. I don't know your numbers, but I would expect that Confluence with a single external AD constitutes a significant chunk of your ldap installations so this option would be kill a lot of birds with a single stone. AFAICS the exception condition where an attempt to rename clashes with an existing name should actually halt and produce an exception report. In the above scenario it should never happen but if it does the solution will likely require some thinking, reconfiguration and/or changes outside Confluence. This doesn't solve the myriad of problems that can arise with multiple directories that don't have unique persistent identifiers but a configuration that supports this approach should form a part of the solution.
          Hide
          atlassian6 François Nonnenmacher added a comment -

          Merging content for duplicate accounts is indeed the most painful issue. I have close to 1,000 duplicate accounts on one Confluence instance because of a switch to LDAP (many people previously using local accounts got a new one once authenticated via LDAP), and I bet many others have the same issue. It's not trivial because you can't always predict what to do and develop a user-friendly conflict resolution interface (e.g. à la Apple when you have conflicts in your contacts or agendas) is a serious task (the lazy solution would be to ask users to migrate content manually and just delete/deactivate their old account).

          Show
          atlassian6 François Nonnenmacher added a comment - Merging content for duplicate accounts is indeed the most painful issue. I have close to 1,000 duplicate accounts on one Confluence instance because of a switch to LDAP (many people previously using local accounts got a new one once authenticated via LDAP), and I bet many others have the same issue. It's not trivial because you can't always predict what to do and develop a user-friendly conflict resolution interface (e.g. à la Apple when you have conflicts in your contacts or agendas) is a serious task (the lazy solution would be to ask users to migrate content manually and just delete/deactivate their old account).
          Hide
          fajar.suryawan Fajar Suryawan added a comment -

          good to hear this issue is addressed in future releases!

          Confluence 5.2-m19 EAP discussion:
          https://confluence.atlassian.com/display/DOC/Confluence+5.2-m19+EAP+Release+Notes

          Show
          fajar.suryawan Fajar Suryawan added a comment - good to hear this issue is addressed in future releases! Confluence 5.2-m19 EAP discussion: https://confluence.atlassian.com/display/DOC/Confluence+5.2-m19+EAP+Release+Notes
          Hide
          pcurren Paul Curren added a comment -

          A definite is that we will support a local user rename.

          So if we delivered this bare minimum then in the case where an LDAP/Crowd/JIRA managed user was renamed you would then manually via the GUI (or script it via the remote API) change the username in Confluence to match. This is a straight replacement to our current "offering" of running lots of scripts

          What we are actually hoping to deliver at the same time however is the detection of renames in an LDAP directory which will remove the need for the manual step. We are likely to deliver this in Confluence 5.3 but it is dependent on other development teams within Atlassian so I can't offer a guarantee yet.

          Further down the line we should be offering the same detection for Crowd managed users but this is unlikely to be ready in time for Confluence 5.3.

          Show
          pcurren Paul Curren added a comment - A definite is that we will support a local user rename. So if we delivered this bare minimum then in the case where an LDAP/Crowd/JIRA managed user was renamed you would then manually via the GUI (or script it via the remote API) change the username in Confluence to match. This is a straight replacement to our current "offering" of running lots of scripts What we are actually hoping to deliver at the same time however is the detection of renames in an LDAP directory which will remove the need for the manual step. We are likely to deliver this in Confluence 5.3 but it is dependent on other development teams within Atlassian so I can't offer a guarantee yet. Further down the line we should be offering the same detection for Crowd managed users but this is unlikely to be ready in time for Confluence 5.3.
          pcurren Paul Curren made changes -
          Rank Ranked lower
          barconati Bill Arconati made changes -
          Link This issue relates to CONF-30228 [ CONF-30228 ]
          pcurren Paul Curren made changes -
          Rank Ranked higher
          pcurren Paul Curren made changes -
          Comment [ A comment with security level 'atlassian-staff' was removed. ]
          pcurren Paul Curren made changes -
          Sprint Enterprise Sprint 18 [ 667 ]
          pcurren Paul Curren made changes -
          Rank Ranked higher
          pcurren Paul Curren made changes -
          Sprint Enterprise Sprint 18 [ 667 ]
          Hide
          sgk Steffan Klein added a comment -

          I would even be happy with a simple way to reassign comments so I can delete a user and create a new one.
          I don't want to lose comments by a user - why can they not simply stay in system and keep their original commenter name, even of that user no longer exists?

          Show
          sgk Steffan Klein added a comment - I would even be happy with a simple way to reassign comments so I can delete a user and create a new one. I don't want to lose comments by a user - why can they not simply stay in system and keep their original commenter name, even of that user no longer exists?
          pcurren Paul Curren made changes -
          Rank Ranked higher
          barconati Bill Arconati made changes -
          Remote Link This issue links to "Wiki Page (Pug - Confluence Dogfood)" [ 49575 ]
          pcurren Paul Curren made changes -
          Rank Ranked lower
          Hide
          stephen.cooper1 Stephen Cooper added a comment -

          Glad to hear that this will be addressed in Confluence 5.2!
          At our location, we switched from LDAP to Active Directory when our company got bought. All users who were here when we were bought have two accounts, with content associated with both authentication mechanisms.

          Will we be able to merge user accounts? Or does this only allow for a rename of a user account if the new account doesn't have any content associated with it?

          Show
          stephen.cooper1 Stephen Cooper added a comment - Glad to hear that this will be addressed in Confluence 5.2! At our location, we switched from LDAP to Active Directory when our company got bought. All users who were here when we were bought have two accounts, with content associated with both authentication mechanisms. Will we be able to merge user accounts? Or does this only allow for a rename of a user account if the new account doesn't have any content associated with it?
          Hide
          rrobins Rachel Robins [Atlassian Tech Writer] added a comment -

          We are pleased to announce this will be fixed in the upcoming Confluence 5.3 release due out shortly.

          Show
          rrobins Rachel Robins [Atlassian Tech Writer] added a comment - We are pleased to announce this will be fixed in the upcoming Confluence 5.3 release due out shortly.
          rrobins Rachel Robins [Atlassian Tech Writer] made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Assignee Paul Curren [Atlassian] [ pcurren ]
          Fix Version/s 5.3 [ 35892 ]
          Resolution Fixed [ 1 ]
          Hide
          pcurren Paul Curren added a comment -

          A number of the comments on this issue refer to the ability to merge two separate user accounts with content. This can be discussed and tracked separately on CONF-11990.

          Show
          pcurren Paul Curren added a comment - A number of the comments on this issue refer to the ability to merge two separate user accounts with content. This can be discussed and tracked separately on CONF-11990 .
          Hide
          jimbirch Jim Birch added a comment - - edited

          In a corporate scenario with and external AD/LDAP directory, a user would get married (etc), get an external name change pushed by HR processes likely automatically, but asynchronously. At some point they would login to Confluence and get a new local account since Crowd doesn't attach the external account to an external invariant like the AD user GUID. It's going to be approximately impossible to guarantee that the Confluence ID is changed when the external ID is changed. So name change without merge capability won't get the job done.

          Show
          jimbirch Jim Birch added a comment - - edited In a corporate scenario with and external AD/LDAP directory, a user would get married (etc), get an external name change pushed by HR processes likely automatically, but asynchronously. At some point they would login to Confluence and get a new local account since Crowd doesn't attach the external account to an external invariant like the AD user GUID. It's going to be approximately impossible to guarantee that the Confluence ID is changed when the external ID is changed. So name change without merge capability won't get the job done.
          jcaragan Jason Caragan [Atlassian] made changes -
          Remote Link This issue links to "Page (Extranet)" [ 52978 ]
          jcaragan Jason Caragan [Atlassian] made changes -
          Remote Link This issue links to "Page (Extranet)" [ 52978 ] This issue links to "Page (Extranet)" [ 52978 ]
          konqi Marcel Trautwein alias childno͡.de made changes -
          Link This issue is related to JRA-1549 [ JRA-1549 ]
          konqi Marcel Trautwein alias childno͡.de made changes -
          Link This issue relates to CONF-2191 [ CONF-2191 ]
          pcurren Paul Curren made changes -
          Remote Link This issue links to "Wiki Page (Pug)" [ 16481 ] This issue links to "Page (Pug - Confluence Dogfood)" [ 16481 ]
          pcurren Paul Curren made changes -
          Remote Link This issue links to "Page (Pug - Confluence Dogfood)" [ 16481 ] This issue links to "Page (Pug - Confluence Dogfood)" [ 16481 ]