fix: email not set when user logs in for the first time (#328)

[LeShaunJ]

Description

• Small change, adds $force || to fix AutoProvisioningService, which is currently broken (see Motivation and Context below).
• Corrects unit-test to expect email to be set during auto-provisioning when mode() == 'email'.

Related Issue

• Fixes No email address is returned upon first login #328
• Fixes Auto-Provisioning in email mode doesn't set email, which makes auto-provisioned accounts be created each login #335

Motivation and Context

A change in v2.3.1 made it so when $this->client->mode() == 'email':

• AutoProvisioningService->updateAccountInfo() skips $user->setEMailAddress($currentEmail)
• AutoProvisioningService->createUser() calls updateAccountInfo() in order to hydrate it with the appropriate data.
• So you end up with:
  • A first-time user logs in.
  • $user->setEMailAddress($currentEmail) is skipped; the user is able to use the app.
  • The user logs out; logs back in.
  • The app tries to search for an existing email; finds none (as it was never saved).
  • Creates a new user; rinse and repeat.
• Despite the user seeing that they've successfully logged in, they are unaware that every time they do so, they are actually being binding to a brand new user than the one they were in their previous session. The tip off is that they find they can no longer see file that they themselves created, as said files technically belong to a "different" user.
• Furthermore, this results in a plethora of zombie user accounts.

How Has This Been Tested?

Tested on our client's staging environment.

Part 1: Reproduce

1. Logged in as admin in a primary private browser
2. Created a test user in our staging SSO.
3. Successfully Logged into ownCloud in a secondary private browser. Created a file.
4. As admin, observed the new user and display name.
5. Successfully Logged into ownCloud in a tertiary private browser. Cannot see the file I created.
6. As admin, observed two new users with the same display name.

Part 2: Post-Fix

1. Deleted the previous zombie users.
2. Successfully Logged into ownCloud in a secondary private browser. Created a file.
3. As admin, observed the new user and display name.
4. Successfully Logged into ownCloud in a tertiary private browser. Can see the file I created.
5. As admin, observed no users newer than what was initially observed.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• Code changes

[CLAassistant]

All committers have signed the CLA.

[DeepDiver1975]

Thank you! Please look into the failing unit tests THX

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[LeShaunJ]

@DeepDiver1975, all test passed. Had to fix a unit test, as it was expecting an incorrect outcome:

1. Never set email when mode is email.
2. (email mode) App looks for email of returning user; finds no email (was never set).
3. (email mode) Creates new user whenever a user logs in.

Actual expectation:

1. Set email when $force or mode is userid:
   • $force passed during auto-provision.
   • $force not passed during updates.
2. (email mode) App looks for email of returning user; finds email.

[LeShaunJ]

Hi @DeepDiver1975. Just wondering, is there a release structure that is followed when it comes to these plugins (for example, they follow the core release schedule)?

This is not to rush or anything; it's just that it's a blocker on my end, so I need to temper expectations.

[DeepDiver1975]

also fixes #335

[Kruemmelspalter]

@DeepDiver1975 what needs to happen to get this merged?

[LeShaunJ]

Hi @DeepDiver1975, after 9 months with no activity, is it safe to assume this is low priority for ownCloud?