adobe-apiplatform/user-sync.py v1.2rc2

Second release candidate for 1.2

on GitHub

Important Note: We will be dropping the 1.2 release in favor of 2.0. Any further testing should move there.

Note: This build is for testing purposes only. It should NOT be distributed to customers nor used for production work.

This has all the features and bug fixes comleted and seems quite stable. Items to take special note of, because these affect the invocation args and configuration files:

• All pathnames found in config files are now interpreted relative to the file that contains them (full fix of #30). This means you can put the config file anywhere, and it can refer to files relative to its location (e.g., it can refer to the connector configs via relative pathnames), and then the referred to files can refer to other files relative to their location (e.g., a connector config could refer relatively to a private key file).
• There has been a rename of arguments so that, instead of referring to nonexistent-users (whatever those are), we talk about unmatched-users (that is, users on the Adobe side that have no match on the customer side). You can now specify any one of the following processing args for unmatched users:
  --remove-entitlements-for-unmatched-users, --remove-unmatched-users, or --delete-unmatched users. (Note that there is still some debate about this renaming, so it's possible the arg names will go back to what they were in the GM build.)
• We used to have separate arguments for outputting unmatched users to or inputting unmatched users from a file, one for each kind of processing (remove-entitlements vs remove vs delete). These have been collapsed into just two: they are now --output-unmatched-users (to write the file) and --input-unmatched-users (to read the file).
• The limits settings on processing unmatched users have changed: they are now max_unmatched_users (used to be max_missing_users) and max_removed_users (used to be max_deletions_per_run).

A lot of the underlying processing related to the various removal options for users has been overhauled and made way more consistent and efficient, especially in those cases where you have accessor orgs as well as an owning organization. In all cases, the code now assumes that only those users in the owning organization are to be matched against customer users (and controlled by the exclude settings), and the accessor orgs are never used except to update group mappings (or do org removal). The attributes in accessor orgs are never consulted or updated, and we never consider or touch users in those orgs other than the ones that are also in the owning org.

Unless we find problems between now and end-of-day Monday 27 March, expect the final release to come Tuesday morning, 28 March.