Guest user is "migrated" to a real user.

[cdamken]

Description:

(Using LDAP as example, but it can be local users or Shibboleth users too)

In this case Real User -> Local, LDAP or Shibboleth User

I have 6 LDAP users:
[email protected] -> member or oCGroup
[email protected] -> member or oCGroup
[email protected]
[email protected]

the LDAP filter only allows users that are allowed in oCGroup = 4 Users

user1 invites user3 as guest user
user2 invites user4 as guest user

After a while, the admin add user 3 and 4 as member of ocGoup..... and

occ user:sync ....

Expected behaivor:

ownCloud will ask if the shares of the guest user should be transferred to the new real user.
which should the behavior in case the shares should not accept? (Remove them?/notify the User that the user now exist to reshare? )

Actual behavior:

Duplicated E-mail to real and guest user
Real user can't log in with the E-mail because the guest user now owns it.

@pmaier1 as discussed.

@PVince81 @cortho

[PVince81]

We'll likely want a new occ command to convert guest users to real users, or somehow "morph" them to whatever LDAP id user has been created for that user. Might be tricky to achieve in a clean way.

[PVince81]

If we had a way to rewire users to older storages, raised here owncloud/core#29502

[PVince81]

In theory the admin could already create the target user in LDAP and then use the transfer ownership feature to transfer the guest user to a real user.

However, received shares aren't transferred. Maybe the transfer ownership feature could be extended with an option --rewrite-received-shares or something alike.

Because whatever we do the functionality will be similar to transfer ownership.

The thing we cannot do is convert a guest user to an LDAP user directly as they come from a different backend and would also require user id renaming, which is currently not possible due to the current DB structure. Ref: owncloud/core#29503

[PVince81]

On the other hand this would change the user login and password as the admin cannot configure a new LDAP account with the same password. Well, with some LDAP attribute trickery they might be able to keep the login name. So whatever we do the guest user would need to reenter their password somewhere to be set to LDAP.