|
The Confluence documentation now has a page that lists some workaround solutions:
http://confluence.atlassian.com/display/DOC/Changing+Usernames Jens Schumacher's solution is more robust, providing all the ramifications of the change are understood.
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)
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. 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. 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.
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 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 Given the range of different databases we support, a stored procedure isn't an option.
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. http://forums.atlassian.com/thread.jspa?messageID=257250010
 - that user names also change when people get married. 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.... 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:
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?). 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, 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 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()
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! 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. 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 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. 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...).
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. 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
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! 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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Change usernames
"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..."