Bring Branch up to date. #296
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Doc template update for fixed position nav area
include some more comments for all_users_filter
Wording change for all_users_filter
Update commentary in sample LDAP file to clarify role of the `all_users_filter`.
Fix TOC indent when level drops by more than one level
Update default.html
Escape LDAP special chars.
Now we only import the keyring right where we use it. This will be helpful on Linux servers that don't have keyrings.
prepare for 2.2.2rc1 build
In order to fix #293, the logic around creating Adobe users had to be revamped. The original logic was that all Adobe users would be created in the primary umapi, and when they were created there they would also be created in any secondaries for which they had group mappings. But this fails when secondary group mappings are added *after* the user is created in the primary, as often happens for customers who add Stock consoles. So now things work as follows: * New Adobe users are always created in the primary umapi, which is expected be the org that owns all directories where users are created. * New Adobe users are only created in a secondary umapi if they have groups there. Revamping the logic around creates allowed streamlining and merging the (hitherto separate) code paths for push and sync: * Push and Sync are now identical except for how they choose which Adobe users are new (push says they are all new, sync knows which are new). * All creates in the primary umapi update attributes if requested (because the primary should own the directories); all attributes in secondaries don't update attributes (because the secondaries should trust the directories). As part of the revamp, I found a spot where Adobe ID attributes were not being updated. This was cleaned up in order to fix #286 again. Finally, the order of group operations when users were created had been remove then add, while when a user was being updated it was add then remove. Since there's some small, theoretical chance that product provisioning of configurations that contain two groups might be affected by the order of group operations, both sequences have been updated to use the remove then add ordering. There's no issue for this, because we have no actual evidence that it matters.
The tricky part of this was to separate out which users are being added to the primary *and* the secondary, as opposed to which users are being updated by being added to the secondary. Getting this right meant renaming a lot of the statistics to more clearly say what they are.
Prepare for v2.2.2rc2 build
We aren't pre-building wheels any more for use with pex so we no longer refer to the `wheelhouse` directory, but the script was still removing it. This was actually surfacing on Windows/cygwin as a spurious error in some cases.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.