[FIX] portal_backend: let the chatter load followers and attachments - #452
Closed
fw-bot-adhoc wants to merge 1 commit into
Closed
fw-bot-adhoc wants to merge 1 commit into
fw-bot-adhoc wants to merge 1 commit into
Conversation
The core /mail/thread/data controller empties request_list when the user is not internal, so the response carries neither followersCount nor attachments. The chatter keeps its spinner while followersCount is undefined and the attachments are not loaded, so both counters spin forever for a portal backend user. The cut happens before any permission check, so it is not an ACL issue. Override the controller to set portal_bypass for portal backend users, which is the context this module already uses to make _is_internal return True. Core still checks read access on the record before answering, so a portal backend user without access to the record gets nothing, and plain portal users are unaffected. Also drop the _get_mail_thread_data override: that method no longer exists in Odoo 18, where _thread_to_store replaced it. It was dead code left over from the migration, and it used to strip "followers" to dodge an error on records followed by an internal user. That error does not show up anymore. X-original-commit: 275d488
Contributor
|
|
Contributor
Author
|
@lef-adhoc @gal-adhoc this PR targets 19.0 and is the last of the forward-port chain. To merge the full chain, use
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
Contributor
Author
|
@lef-adhoc @gal-adhoc ci/runbot-modified-modules failed on this forward-port PR |
Contributor
|
No es necesario |
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
3 participants
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.
Ticket: https://www.adhoc.inc/odoo/helpdesk.ticket/128749
Qué duele
Un usuario portal backend abre un registro con chatter (una venta, por ejemplo) y los íconos de Seguidores y Adjuntos quedan en "Cargando..." para siempre.
El controlador del core
/mail/thread/datavacía elrequest_listcuando el usuario no es interno, así que la respuesta no traefollowersCountniattachments. El chatter muestra el spinner justamente mientrasfollowersCount === undefinedy los adjuntos no cargaron, así que nunca deja de girar. El corte pasa antes de mirar permisos: no es un problema de ACL.Qué cambia
/mail/thread/datapara setearportal_bypasscuando el usuario es portal backend. Es el mismo contexto que el módulo ya usa para que_is_internal()devuelva True (vermodels/res_users.pyymodels/ir_attachment.py), así que no se introduce un mecanismo nuevo. El core sigue chequeando acceso de lectura sobre el registro antes de contestar._get_mail_thread_data: ese método no existe más en Odoo 18, donde lo reemplazó_thread_to_store. Era código muerto que quedó de la migración. Sacabafollowerspara esquivar un error cuando un usuario interno seguía el registro; ese error ya no aparece, verificado en pantalla abriendo el desplegable con un interno en la lista.Sin tests: en 18 no los queremos en este módulo.
Cómo se probó
Base 18 local con
sale+portal_backend, sobre una venta con un seguidor interno y un adjunto.En la pantalla (navegador, sesión real del usuario portal backend, mismo registro antes y después, cambiando solo el código):
FollowFollowingAbriendo el desplegable de seguidores se ven los tres, incluido el usuario interno, sin errores en consola.
En el request
/mail/thread/data:followersCountniattachmentsfollowersCount=4, 1 adjuntohasReadAccess=False)hasReadAccess=False)Las dos últimas filas son las que importan del lado de la seguridad: el cambio no alcanza a un registro que el usuario no puede leer, ni a un portal común.
Fuera de alcance
El ticket también pregunta si el portal backend tiene que poder agregar seguidores. No entra acá porque son permisos nuevos, no un bug: hoy falla por dos motivos distintos, y el segundo es una decisión de producto.
O sea: además de la ACL del wizard,
message_subscribepide permiso de escritura sobre el registro. Darle write sobre las ventas a un portal backend es bastante más que destrabar un contador.Queda abierto también qué datos de los seguidores internos puede ver un portal backend. Hoy, con el request destrabado, recibe lo mismo que cualquier usuario que pasa ese gate: nombre, avatar y email del seguidor. El core oculta el email a los no internos en
res.partner._to_store, pero lo publica igual enmail.followers._to_store, que no tiene ese gate. Filtrar solo una de las dos vías daba una falsa sensación de control, así que no se filtró nada: si hay que limitar campos, es una decisión de producto y va en un cambio aparte.Nota aparte, para quien revise
Con
portal_backendsolo, un usuario portal backend no llega a abrir el form de una venta: elweb_readcorta conAccessErroren modelos auxiliares de la vista (sale.order.option,product.pricelist,product.attribute.custom.value, …), antes de cualquier tema de chatter. Para poder mirar el chatter en pantalla hubo que darle lectura sobre esos modelos en la base de prueba. Es ruido ambiental para este PR —no toca el gate de_is_internal, que es donde está el bug— pero sugiere que donde se reportó el problema hay algo más que ya le da esos accesos.bump
Forward-Port-Of: #449