= Synchronize User Account data between multiple Trac projects = {{{ #!html
WARNING: This plugin is at best an early beta. So take special care using it, especially in productive environments!
}}} == Description == This plugin can be used to synchronize user account data between multiple projects within the same `TRAC_PARENT`. Basically, it reads the account information from all the separate environments, merges them, and then updates all environments accordingly. As it currently still is in early beta state at best, a `dryrun` mode is enabled by default - so no changes will be written to the database. Instead, the updates for the affected environments will be stored in `.sql` files to investigate. If you intend to use this plugin in its current state, you are strongly encouraged to... 1. first test it in a non-productive environment, which best is a copy of the intended productive environment to be used on later 1. first let it run in `drymode`, and investigate the resulting `*.sql` files carefully 1. only if everything seems to be fine, and still being in your test environment, and after making a copy of the databases, disable `drymode` and verify the results 1. only if still everything seems to be OK, repeat these steps in your productive environment - at your own risk I (the author) will take no responsibilities whatever, especially concerning possible damage and data loss. You have been warned! If you are still encouraged to try it: Great - I love to receive your feedback! == Limitations == Except this plugin being still in early beta state, there are more limitations to consider: 1. it was not widely tested yet 1. it is not yet "fool-proof" (if it ever will be). This especially means, not all possible exceptions may be handled yet 1. it works only for environments, which... 1. share the same `TRAC_PARENT_DIR` 1. use the AccountManagerPlugin 1. store the user passwords in a `.htpasswd` file 1. share the same `.htpasswd` password file (which at the moment '''''you''''' have to ensure, it's not yet verified) There may be more limitations I'm not aware of at the moment... == Bugs/Feature Requests == Existing bugs and feature requests for TracUserSyncPlugin are [report:9?COMPONENT=TracUserSyncPlugin here]. If you have any issues, create a [http://trac-hacks.org/newticket?component=TracUserSyncPlugin&owner=izzy new ticket]. == Download == Download the zipped source from [download:tracusersyncplugin here]. == Source == You can check out TracUserSyncPlugin from [http://trac-hacks.org/svn/tracusersyncplugin here] using Subversion, or [source:tracusersyncplugin browse the source] with Trac. == Installation == The easiest way to install this plugin is: {{{ easy_install http://trac-hacks.org/svn/tracusersyncplugin/0.11/trunk }}} While you may want to replace "trunk" by one of the branches. "trunk" is usually the "code in development", while the branches should reflect something "stable". You can alos checkout the code from the repository, or download and unpack the zipped source (see above) - and then run either `easy_install` or `python setup.py` from where the `setup.py` file resides. == Configuration == For testing purposes, default settings should be fine. However, there are some settings you can use for "fine-tuning" - they are to be found (or inserted) in(to) your `trac.ini`in the `[user_sync]` section as shown below: {{{ [user_sync] dryrun = true merge_conflicts = skip sql_file_path = sync_fields = email,name }}} The easiest way to modify these settings is using the IniAdminPlugin, where you always have some helpful information displayed next to the options. I will explain them here in short, though: === dryrun === This enables the "test mode", in which no changes won't be done to your environments - especially the databases will not be written to. Instead, changes which would be written to the database will be stored in `*.sql` files, one for each environment. This is a boolean setting - so the only valid values here are "true" and "false". === merge_conflicts === What should be done if records from two (or more) environments conflict. Possible values are "skip" (do not update this user anywhere) and "newer" (use the record from the environment the user was last active in - which must not necessarily be the one with the most recent data). Default is "skip", to be on the safe side. What makes a conflict? Say user Tom registers in environment A, and sets his name to "Tom Sawyer" and his email to "tom@sawyer.tld". His password is stored to the shared `.htpasswd` file, so he can immediately login to environment B without registering again. He does so - but edits his record here, using the name "Tommy". If the field `name` is contained in the `sync_fields` list (see below), this would cause a conflict since the two names don't match - which means, the email won't be synchronized either. The same applies the other way round: If a different email was specified in one environment, the entire record would be considered conflicting. === sql_file_path === The path where the `*.sql` files shall be stored into. If not set, they will be written into the `log` sub directory of the environment the plugin was invoked from. === sync_fields === Which fields of the user records should be considered for synchronization. By default, this is set to `name,email` - the two basic fields. If you use the UserManagerPlugin, you may want to add some more fields. Note that for now a single conflict on any of the fields will exclude a user record from being merged - though this may change in the future. There are two more fields considered here, even if not mentioned (and you should never introduce them into that list): the information used by the email verification. This means, if you enabled email verification in the AccountManagerPlugin, we will try to take care for that as well. So if a user verified for one environment, we try to do this for the other environments as well. == Example == This is what it could look like after a successful synchronization: [[Image(tus.jpg)]] == Future == There are some things I consider for the future: 1. purge users (i.e. if you delete a user in one environment, and thus remove him from the password file, this change should be reflected in the other environments as well - not leaving a bunch of obsolete information) 1. make the plugin more "fool-proof" and reliable (I need your feedback for that) 1. introduce some "Listeners" (to notice registrations/changes in environments and automatically propagate them to the other environments, so you only need to run the synchronization manually once - which is after installation). I have to say here: This is not a promise. I wrote all this in my free time, and I will only continue it if my time permits me to. And believe me, I have some more projects and things I like to do, so don't get mad at me if I delay (or even stop). But hey, in those cases you've got the source, right? == Recent Changes == [[ChangeLog(tracusersyncplugin, 3)]] == Author/Contributors == '''Author:''' [wiki:izzy] [[BR]] '''Contributors:'''