Changes between Version 19 and Version 20 of TracUserSyncPlugin


Ignore:
Timestamp:
Sep 11, 2016, 7:36:28 AM (8 years ago)
Author:
figaro
Comment:

Further cosmetic changes

Legend:

Unmodified
Added
Removed
Modified

  • TracUserSyncPlugin

    v19 v20  
    33= Synchronize User Account data between multiple Trac projects
    44
    5 {{{
    6 #!html
    7 <DIV STYLE='background: #fdc; border: 2px solid #d00; color: #500; padding: .5em; margin: 1em 0;'>
    8 <B STYLE='color:#f00;'>WARNING:</B> This plugin is at best an early beta. So take special care using it, especially in production environments!
    9 </DIV>
     5{{{#!box warn
     6'''Warning:''' This plugin is at best an early beta. So take special care using it, especially in production environments!
    107}}}
    118
    … …  
    6663You can also 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.
    6764
    68 == Configuration
    69 
    70 First you of course need to activate the plugin. This is, as usual, done in the components section of your `trac.ini`:
     65Then you need to activate the plugin, by adding the following in the components section of your `trac.ini` file:
    7166{{{#!ini
    7267[components]
    … …  
    7469}}}
    7570
    76 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:
     71== Configuration
     72
     73For testing purposes, the default settings should be fine. However, there are some additional settings in the `[user_sync]` section of your `trac.ini` file:
    7774{{{#!ini
    7875[user_sync]
    … …  
    8582}}}
    8683
    87 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:
     84The easiest way to modify these settings is using the IniAdminPlugin, where you always have some helpful information displayed next to the options. Here are some brief explanations:
    8885
    8986=== dryrun
    9087
    91 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".
     88This enables the "test mode", in which no changes will be done to your environments including the databases. 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".
    9289
    9390=== merge_conflicts
    9491
    95 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.
     92What 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 is not necessarily the one with the most recent data). Default is "skip", to be on the safe side.
    9693
    97 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.
     94What 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.
    9895
    9996=== sql_file_path
    … …  
    103100=== sync_fields
    104101
    105 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) - so the more fields added, the higher are chances for conflicts.
     102Which 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, so the more fields added, the higher the chances are for conflicts.
    106103
    107104There 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.
    … …  
    119116=== Settings
    120117
    121 You will find the interface on the Admin page in the Accounts section as ''User Sync'' (see also [#Example below screenshot]). After invoking this page, you can select the environments to synchronize. The list includes all Trac environments sharing the `TRAC_PARENT_DIR` with the environment you are currently in - though it did not yet check what password store they are using or even whether they share the same password file (this may be added later). If your selection includes an environment with conflicting data, it will be excluded later. All found environments are pre-selected except those mentioned in the `exclude_envs` setting - so you might want to (un)check one/some or leave it as is.
     118You will find the interface on the Admin page in the Accounts section as ''User Sync'' (see also [#Example screenshot]). After invoking this page, you can select the environments to synchronize. The list includes all Trac environments sharing the `TRAC_PARENT_DIR` with the environment you are currently in - though it did not yet check what password store they are using or even whether they share the same password file (this may be added later). If your selection includes an environment with conflicting data, it will be excluded later. All found environments are pre-selected except those mentioned in the `exclude_envs` setting, so you might want to (un)check one/some or leave it as is.
    122119
    123120The second "field set" shows you the password file used by the current environment, and what users have been stored there. This is just for your information.
    124121
    125 The third section lets you select the actions to perform. ''Synchronize'' is already pre-selected here, since this is the main task this plugin is for, and also is what you probably want to do. This action means: Make sure all included environments get the account data users have entered in one of the environments for fields contained in the `sync_fields` setting. The second check box, labeled ''Purge'', will cause the plugin to remove all users from all environments - except those contained in the password file or mentioned in the `users_keep` setting. Of course, it would not touch your permission groups (anonymous,authenticated, and whatever you may have added) - these are evaluated automatically.
     122The third section lets you select the actions to perform. ''Synchronize'' is already pre-selected here, since this is the main task this plugin is for, and also is what you probably want to do. This action means: Make sure all included environments get the account data users have entered in one of the environments for fields contained in the `sync_fields` setting. The second check box, labeled ''Purge'', will cause the plugin to remove all users from all environments, except those contained in the password file or mentioned in the `users_keep` setting. Of course, it would not touch your permission groups (anonymous, authenticated and whatever you may have added), these are evaluated automatically.
    126123
    127124{{{#!html
    … …  
    152149This is what it could look like after a successful synchronization:
    153150
    154 [[Image(tus.jpg)]]
     151[[Image(tus.jpg, border=2)]]
    155152
    156 == Future
     153== Planned features
    157154
    158155There are some things I consider for the future:
    159  1. only list "compatible" environments (i.e. those sharing the same password file, and where the current user has the required privileges)
     156 1. only list "compatible" environments, ie those sharing the same password file, and where the current user has the required privileges
    160157 1. make the plugin more "fool-proof" and reliable (I need your feedback for that)
    161  1. identify and remove "dummy users" (i.e. spammers whose spam you already removed: registered users with no ownership/authorship of any ticket, wiki article, component, whatsoever - and a last_visit xx days in the past)
    162  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).
     158 1. identify and remove "dummy users", ie spammers whose spam you already removed: registered users with no ownership/authorship of any ticket, wiki article, component, whatsoever - and a last_visit xx days in the past
     159 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.
     160 1. Reduce the amount of fields that conflicts are checked for: this would result in allowing a higher amount of overlap between attributes of users and reduce the amount of conflicts.
    163161
    164162== User Comments