Sync w/ "--adobe-only-user-action write-file" still removes groups for Adobe-only users

[adorton-adobe]

The documentation states the following about the --adobe-only-user-action write-file command line option (bolding mine):

write-file: the list of user account present on the Adobe side but not in the directory is written to the file indicated. No other account action is taken. You can then pass this file to the --adobe-only-user-list argument in a subsequent run.

What does the doc mean by "no other account action is taken"? When I run sync w/ that option, the sync will not only generate the file I need, but it will also remove mapped groups for Adobe-only users. Should it be doing the latter part, or is that behavior a bug? If it's working as designed, would it be possible to add an option to only do the file generation part and not do anything to Adobe-only users?

[adobeDan]

That's a doc bug; I'm assigning it to @phil-levy. The exact definition of --adobe-only-user-action write-file is that it is identical to the preserve action but additionally writes the users to a file. The preserve activity is governed by the max_adobe_only_users limit, but the writing to the file always occurs regardless of that limit.

[adorton-adobe]

I see, thanks for the explanation and quick attention.

I'd like to be able to support the following use case:

1. Generate list of Adobe-only users but do not remove any of their groups (yet). We still want to add/update group information for non-Adobe-only users.
2. Convert export list to user input list (using an external awk or python script) with one user group assigned to all users (a special user group used to track # of "deprovisioned" users).
3. Sync against input user list to remove mapped groups and put all Adobe-only users into "deprovisioned" group.

The sync tool kind of supports this, but because of that "preserve" behavior you mentioned, Adobe-only users will be removed from their groups, added to deprovisioned, removed from deprovisioned, added back, and so on. That will put the member count of that group in constant flux, which will make it unusable for reporting & auditing.

Do we have a way to support this use case already?

[phil-levy]

Item 1 can be done via
user-sync --users whatever --adobe-only-user-action file to_be_moved.csv

Note omission of --process-groups in this run so that group membership is not updated.

Item 2 could be via a script operating on the file.

Item 3 would be via
user-sync --users file edited_version_of_to_be_removed.csv --process-groups --adobe-only-user-action exclude

This works by using the list of users to be removed as the input list, and all the other users are ignored (hence the exclude action).

This assumes the users file lists the users in the to_be_removed list and puts them in a single group (your deprovisioned group). Since that is the only group listed, they will be removed from all other groups. All the rest of the users who, in this run, are adobe-only users because they are not in the users file, are excluded from the sync process and not modified.

[adorton-adobe]

Item 1 can be done via
user-sync --users whatever --adobe-only-user-action file to_be_moved.csv

Note omission of --process-groups in this run so that group membership is not updated.

See my note about needing to still be able to handle group assignment for users that aren't identified as Adobe-only. Including --process-groups will do group assignment, but also remove entitlements for Adobe-only users by default (which it should be doing). Omitting that option won't remove entitlements, but also won't do any kind of group updates.

I'm wondering if the tool would benefit from a new option that will just write non-Adobe users to a file but not do anything else related to the non-Adobe users. I'll take a look and submit a PR if I come up with anything.

[phil-levy]

It sounds like your 3 items is actually 4. The fourth, process normal updates for users who are in the directory would be done by

user-sync --users whatever --process-groups --adobe-only-user-action exclude

which will do the group updating and new user creation. Then running steps 1-3 above would handle the users to be de-provisioned.

Of course, I'm just answering your questions. The question I would ask is why someone would want to do this in the first place.

thanks
phil