Issue Summary

Unsaved claim settings are applied even user don't save the settings.

System behavior

1. If you select "Automatically claim new accounts" in the claim setting and return to the previous page with back of the browser action without saving, the new account will be create as a Claimed account even original setting is "Manually claim new accounts".
2. then the new account will be added to the default authentication policy.
3. after if you do unclaim the new account , the account disappears in the default authentication policy, but the number of users remains the same, and when you export users of the authentication policy, the CSV file shows the user you just unclaimed.

Steps to Reproduce

1. First make sure you set New accounts setting is "Claim manually"
2. Go to Domain setting, click to your Dmain's (...) > then click "Change claim setting"
3. Click "Automatically claim new account" but don't save
4. Back to previous page by browser action
5. Sign up with new account which has the domain
6. Check audit log. It shows "Claimed account xxxx@test.domain for domain test.domain" and the account added to Authentication policies
7. Go to Domain setting, click to your Dmain's (...) > "Unclaim accounts"
8. Unclaim the created account
9. Check the Authentication policies, it shows number of user but the unclaimed account don't show in the policy and can't delete the account by UI

Expected Results

• It should be keep original settings if an user don't save the settings.
• If an account unclaimed, it should not be counted in the number of people in the authentication policy and should not be output unclaimed user in the CSV file.

Actual Results

• Unsaved claim settings are applied even user don't save the settings.
• Unclaimed account counted in the number of people in the authentication policy and output unclaimed user in the CSV file.

Workaround

• New account became claimed account issue, set again "Manually claim new accounts" in claim setting.
• Authentication policy member issue, Currently there is no known workaround for this behavior. A workaround will be added here when available