When the partner already had a user,
checking `in_portal` of this partner and applying
the wizard raised the fact there was already a duplicated
user for this email, even if there wasn't.
This is because the system relied on the fact
the field `user_id` of the `portal.wizard.user`
was automatically filled with the partner user if
there was one, but it was not the case:
This `user_id` field is a simple many2one field,
not computed, and the assignation was done nowhere
when the partner already had a user.
The assignation should be done in the `onchange_portal_id` method
of the `portal.wizard` model, like the other fields
`partner_id`, `email` and `in_portal`,
but if we do it know, as the `user_id` field is not
in the view (not even in `invisible`), the
web client will ignore it even if returned by
this `onchange_portal_id` method. It was therefore pointless
to solve this issue by adding the correct `user_id`
in the `user_ids` returned by this onchange method.
We could add `user_id` in invisible in the view,
but existing databases with the current view
will not benefit of the bug fix without updating the according view.
This revision therefore replaces `wizard.user_id` by
`wizard.partner_ids.user_ids[0]` everywhere where it's needed to
know if the partner already has a user or not.
Besides, it takes care about the fact his user could
be disabled (`active` False).
opw-659339
Denis Ledoux
11911fe057