Skip to content

Setting users to a known state shouldn't require fetching Adobe users #236

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
adobeDan opened this issue Jun 16, 2017 · 3 comments
Closed
Assignees
Milestone

Comments

@adobeDan
Copy link
Contributor

If an organization is very, very large, and the customer wants to run a job that creates or updates specific users to have a specific set of known attributes and group memberships (similar to a bulk upload from the admin console), the customer shouldn't have to wait for User Sync to fetch the Adobe-side users (which may take a long time) and to do the sync. Instead, the customer should be able to "directly populate" the users into the org with those attribute values and group memberships, instructing user sync either to create or update each individual user as necessary.

@adobeDan adobeDan added this to the 2.2 milestone Jun 16, 2017
@adobeDan adobeDan self-assigned this Jun 16, 2017
@phil-levy
Copy link
Contributor

Not sure what you are getting at here, but that capability is already present and was designed to support push notifications. You can set a csv file with the users you want to populate and exclude adobe-only users to leave everyone else alone.

@adobeDan
Copy link
Contributor Author

Yes but such a User Sync job will still fetch all the Adobe users, only to exclude them. If your organization is very large then fetching all the Adobe-side users could take a very long time and there's no reason to. This enhancement would be to skip the fetch of the Adobe users completely.

@phil-levy
Copy link
Contributor

Got it. Thanks.

adobeDan added a commit that referenced this issue Jun 19, 2017
Since all the code-level bugs for 2.2 are fixed, and we have all the desired enhancements implemented other than #236, we are ready for an rc1 build and testing by the extended community.
adobeDan added a commit that referenced this issue Jun 19, 2017
Because added users may already be in the org in push mode, we don't just add the mapped groups they should have, we also remove any managed groups they shouldn't have.  This fulfills our promise to process groups even when re-pushing an existing user.
adobeDan added a commit that referenced this issue Jun 19, 2017
There's no point in reporting on the Adobe-side changes when doing a push.
adobeDan added a commit that referenced this issue Jun 20, 2017
fix #236: allow users to be pushed rather than sync'd to Adobe.
adobeDan added a commit that referenced this issue Jun 20, 2017
adobeDan added a commit that referenced this issue Jun 20, 2017
* Changed the fix of #236 so that the semantics of sync is unchanged from before (for better backward compatibility).  Only push does remove of groups, because it's operating in the blind.
* Updated the nosetests so they work in py2 and py3
* Updated the noestests to add testing the rules with push strategy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants