| | 87 | === users_keep === |
| | 88 | This option only affects purging: here you can define users which shall always be excluded from purging. The plugin will take care for your permission groups (e.g. anonymous,authenticated) automatically, so you don't need to add those. |
| | 89 | |
| | 90 | == Usage == |
| | 91 | === Settings === |
| | 92 | You will find the interface on the Admin page in the Accounts section as ''User Sync'' (see also 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. By default, currently all found environments are pre-selected - so you might want to uncheck one/some or leave it as is. |
| | 93 | |
| | 94 | The 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. |
| | 95 | |
| | 96 | 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. |
| | 97 | |
| | 98 | {{{ |
| | 99 | #!html |
| | 100 | <DIV STYLE='background: #fdc; border: 2px solid #d00; color: #500; padding: .5em; margin: 1em 0;'> |
| | 101 | <B STYLE='color:#f00;'>WARNING:</B> You should always run in `dryrun` mode first and check the resulting `*.sql` files carefully. Every Trac setup has its specifics, and I only tested the script in my own setup. So as long as there's no feedback from other users, I'd consider it not-yet-safe! |
| | 102 | </DIV> |
| | 103 | }}} |
| | 104 | |
| | 105 | === Results === |
| | 106 | Now that you've made your selections, push the ''Perform actions'' button. When the page is reloaded, it will inform you about the results: |
| | 107 | |
| | 108 | A green box on top (see below screenshot) will give you short information about successful operation. If you got a red box instead, the operation failed completely. |
| | 109 | |
| | 110 | At the end of the page, a new "field set" called ''Log messages'' appears, giving you more detailed information about the process. This includes successful steps as well as "minor failures" (such as environments excluded for reasons like missing privileges or conflicting settings). Read this carefully to get an overview. |
| | 111 | |
| | 112 | Next, you should also investigate the resulting `*.sql` files. Some hints: |
| | 113 | * Check the `NOT IN ()` list of the `DELETE` statements to make sure it contains all the users of your password file (they should be in here) as well as all your permission groups (''should'' be in as well - but the plugin ''may'' have failed to set them all up correctly - remember, it's not yet thoroughly tested) and `users_keep` |
| | 114 | * Check the `INSERT` statements for each environment (e.g. by turning them into `SELECT` statements and run those against the database - they should return '''no data''' then) |
| | 115 | * Check the `UPDATE` statements in the same way, if there are any - in this case, the corresponding `SELECT` '''must''' return a record, but not necessarily with the same data (hence the update) |
| | 116 | |
| | 117 | === Hot run === |
| | 118 | You may disable the `dryrun` mode once you finished the checks above. Well, you may even disable it immediately - but that's currently not recommended :-) Once you are sure everything works fine, you can even disable the writing of the `*.sql` files by setting the `sql_file_path = none` in your `trac.ini`. |
| | 119 | |
