[FIX] partner_creation_access: no bloquear creaciones en modo superusuario - #146
Closed
ALopez-Adhoc wants to merge 1 commit into
Closed
[FIX] partner_creation_access: no bloquear creaciones en modo superusuario#146ALopez-Adhoc wants to merge 1 commit into
ALopez-Adhoc wants to merge 1 commit into
Conversation
…uario El override de res.partner.create lanzaba UserError para cualquier usuario que no fuera partner manager ni public, incluso cuando la creacion se hacia en modo superusuario (self.env.su). Esto rompia el express checkout de website_sale: al pagar con el proveedor demo, un usuario portal no podia completar el pago porque process_express_checkout crea la direccion de facturacion con res.partner.sudo().create(), y el chequeo miraba self.env.user (portal) ignorando self.env.su. Se agrega el guard "not self.env.su" a la condicion, siguiendo el mismo patron que el core de Odoo (res.partner). Asi los flujos de sistema que elevan privilegios a proposito quedan permitidos, mientras que la creacion interactiva de contactos desde la UI (donde env.su es False) sigue restringida a usuarios con el acceso 'Contact Creation'. Se agregan tests que cubren ambos casos: portal + sudo permitido, portal sin sudo bloqueado.
There was a problem hiding this comment.
Pull request overview
Este PR ajusta el módulo partner_creation_access para que no bloquee creaciones de res.partner cuando el flujo eleva privilegios intencionalmente (modo superusuario), evitando que el express checkout de website_sale falle silenciosamente para usuarios portal.
Changes:
- Se agrega un guard
not self.env.suen el override deres.partner.create()para permitir creaciones bajosudo(). - Se bumpea la versión del módulo.
- Se agregan tests unitarios para cubrir el caso portal con y sin
sudo().
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| partner_creation_access/models/res_partner.py | Ajusta la condición de bloqueo para no aplicar en modo superusuario. |
| partner_creation_access/manifest.py | Bump de versión del módulo. |
| partner_creation_access/tests/init.py | Habilita la carga del paquete de tests. |
| partner_creation_access/tests/test_partner_creation_access.py | Agrega cobertura para creación permitida con sudo() y bloqueo sin sudo(). |
Comments suppressed due to low confidence (1)
partner_creation_access/models/res_partner.py:22
- El mensaje de UserError es texto visible al usuario y ahora mismo no es traducible (no está envuelto en ()/self.env.()). Para que salga en el .pot/.po y pueda traducirse, envolvé el string con self.env._().
raise UserError(
"You don't have access to create contacts. Only users with the 'Contact Creation' access can do it."
)
Contributor
|
@roboadhoc r+ nobump |
|
@ALopez-Adhoc @mav-adhoc linked pull request(s) ingadhoc/website#467 not ready. Linked PRs are not staged until all of them are ready. |
Contributor
|
@roboadhoc r+ nobump |
|
This PR is already reviewed, reviewing it again is useless. |
roboadhoc
pushed a commit
that referenced
this pull request
Jul 24, 2026
…uario El override de res.partner.create lanzaba UserError para cualquier usuario que no fuera partner manager ni public, incluso cuando la creacion se hacia en modo superusuario (self.env.su). Esto rompia el express checkout de website_sale: al pagar con el proveedor demo, un usuario portal no podia completar el pago porque process_express_checkout crea la direccion de facturacion con res.partner.sudo().create(), y el chequeo miraba self.env.user (portal) ignorando self.env.su. Se agrega el guard "not self.env.su" a la condicion, siguiendo el mismo patron que el core de Odoo (res.partner). Asi los flujos de sistema que elevan privilegios a proposito quedan permitidos, mientras que la creacion interactiva de contactos desde la UI (donde env.su es False) sigue restringida a usuarios con el acceso 'Contact Creation'. Se agregan tests que cubren ambos casos: portal + sudo permitido, portal sin sudo bloqueado. closes #146 Signed-off-by: Matias Velazquez <mav@adhoc.com.ar>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problema
En el checkout express de
website_sale, un usuario portal no podía completar el pago con el proveedor demo: al clickear "Pay" el botón no hacía nada. Condebug=assetsaparecía el popup "You don't have access to create contacts. Only users with the 'Contact Creation' access can do it."El JS del proveedor demo envía un billing address, y
website_sale/controllers/main.py::process_express_checkoutcrea la dirección de facturación conrequest.env['res.partner'].sudo().create(...)cuando no matchea ninguna dirección existente del partner.El override de
res.partner.createde este módulo lanzabaUserErrorpara cualquier usuario que no fuerabase.group_partner_managernibase.group_public, incluso bajosudo(), porque la condición mirabaself.env.user(el portal) e ignorabaself.env.su.Sin
debug, el error del frontend lo tragaswallowAllVisitorErrorspara usuarios no internos, así que el síntoma visible era "el botón no hace nada"; elUserErrorigual quedaba en el log del server.Solución
Se agrega el guard
not self.env.sua la condición delcreate(), siguiendo el mismo patrón que el core de Odoo (res.partner). Los flujos de sistema que elevan privilegios a propósito (como el express checkout) quedan permitidos, mientras que la creación interactiva de contactos desde la UI (dondeenv.suesFalse) sigue restringida a usuarios con el acceso 'Contact Creation'.No se suma
group_portala la whitelist: el objetivo del módulo sigue siendo bloquear la creación interactiva de contactos desde la interfaz.Cambios
partner_creation_access/models/res_partner.py: guardnot self.env.suencreate().partner_creation_access/__manifest__.py: bump de versión19.0.1.1.0→19.0.1.1.1.partner_creation_access/tests/: tests nuevos que cubren ambos casos.Test plan
Tests unitarios (
TransactionCase) con un usuario solo del grupo Portal:test_create_partner_portal_with_sudo: crearres.partneren modo sudo → permitido (replica el flujo del express checkout).test_create_partner_portal_without_sudo: crearres.partnercon permisos propios (sin sudo) → sigue lanzandoUserError.Ambos tests pasan (
0 failed, 0 error(s) of 2 tests).