diff options
| author | Denis Ledoux <dle@odoo.com> | 2015-12-14 18:35:30 +0100 |
|---|---|---|
| committer | Denis Ledoux <dle@odoo.com> | 2015-12-14 18:43:56 +0100 |
| commit | 11911fe057f681bbf48f5ab17dc26323d2b4b231 (patch) | |
| tree | 1f47d45fae17883a1e8ea79712162799addec361 /addons/web/static/lib/jquery.mjs.nestedSortable/jquery.mjs.nestedSortable.js | |
| parent | 7a3ad6ba4ccd5a17140a97738a9233fdd61ada1b (diff) | |
[FIX] portal: portal access management for partners having users
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
Diffstat (limited to 'addons/web/static/lib/jquery.mjs.nestedSortable/jquery.mjs.nestedSortable.js')
0 files changed, 0 insertions, 0 deletions
