Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[16.0][FIX] l10n_es_aeat_mod347: fix on partner_records' states #3310

Closed

Conversation

ACheung-FactorLibre
Copy link
Contributor

l10n.es.aeat.mod347.partner_record where being marked as sent, when the partner_id related did not have an email configured.

@ACheung-FactorLibre ACheung-FactorLibre force-pushed the 16.0-fix-l10n_es_aeat_mod347 branch from 60589ce to 4e7529b Compare November 15, 2023 14:51
Copy link
Contributor

@aritzolea aritzolea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Como sugerencia controlaría en la función send_email_direct que se haya recibido algún mail para marcarlo como enviado

@ACheung-FactorLibre ACheung-FactorLibre force-pushed the 16.0-fix-l10n_es_aeat_mod347 branch from 4e7529b to edffcde Compare November 16, 2023 12:25
@ACheung-FactorLibre ACheung-FactorLibre marked this pull request as ready for review November 16, 2023 12:45
Copy link

@gerard-vacas gerard-vacas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Corregido el envío individual en el que cuando el contacto no tiene correo, si descartas sin ponerlo, el registro no pasa a enviado

Corregido el envío masivo no poniendo todos como enviado y dejando en pendiente aquellos registros que su contacto no tiene correo

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@pedrobaeza pedrobaeza added this to the 16.0 milestone Nov 24, 2023
self.write({"state": "sent"})
mail_id = template.send_mail(record.id)
if mail_id:
record.write({"state": "sent"})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Acumula todos para escribirlos de un golpe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Listo, gracias!

active_id = self._context.get("active_id")
record = self.env["l10n.es.aeat.mod347.partner_record"].browse(active_id)
if result_message.mail_ids:
record.write({"state": "sent"})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Esto está repetido según veo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, no está repetido, ya que este es el que controla el envío de correo individual, mientras que el otro método es para el envío de correos en masivo (para el botón de enviar correos arriba a la izquierda).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ya, pues habría que unificar código y evitar tantas líneas para una función tan pequeña. Intenta por favor darle una vuelta a ver si ambas cosas pueden funcionar con el mismo código o que no se requiera algo tan abigarrado.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hay dos vias por los que se está enviando el mail.

  1. Envía el mail directamente mediante send_mail del template, y ahí se puede comprobar si se ha enviado el correo, y marcar a sent.
  2. Abre el wizard del composer y se envía desde ahí el correo. Por eso se está tocando la función _action_send_mail de mail.compose.message, porque no vemos otra manera de comprobar si se ha enviado el mail correctamente.

Para unificar los dos casos lo que se nos ocurre es hacer que se envíe el mail siempre directamente sin el wizard de composer. Lo único que esto no permitiría modificar el mensaje que se va a enviar.

A priori no vemos otra forma de comprobar el envío de mail si se envía de manera diferente.

No se que opinas @pedrobaeza

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yo estaba pensando en el mecanismo que utiliza por ejemplo el módulo sale para cambiar de estado al sale.order:

https://github.com/odoo/odoo/blob/3932c46f914c40be4b0629771d1981cdf289df26/addons/sale/models/sale_order.py#L1433

así se unifica venga de dónde venga.

También sería conveniente que el mensaje no se auto-elimine para dejar el rastro y saber cuándo y qué se ha enviado.

@@ -175,7 +176,7 @@ def button_confirm(self):

def button_send_mails(self):
self.partner_record_ids.filtered(
lambda x: x.state == "pending"
lambda x: x.state == "pending" and x.partner_id.email
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Esto no sería correcto, ya que se utiliza la dirección de facturación cuando está disponible.

active_id = self._context.get("active_id")
record = self.env["l10n.es.aeat.mod347.partner_record"].browse(active_id)
if result_message.mail_ids:
record.write({"state": "sent"})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yo estaba pensando en el mecanismo que utiliza por ejemplo el módulo sale para cambiar de estado al sale.order:

https://github.com/odoo/odoo/blob/3932c46f914c40be4b0629771d1981cdf289df26/addons/sale/models/sale_order.py#L1433

así se unifica venga de dónde venga.

También sería conveniente que el mensaje no se auto-elimine para dejar el rastro y saber cuándo y qué se ha enviado.

@aritzolea aritzolea force-pushed the 16.0-fix-l10n_es_aeat_mod347 branch from 570bcd7 to 383d411 Compare March 20, 2024 11:23
@danielduqma danielduqma force-pushed the 16.0-fix-l10n_es_aeat_mod347 branch from 600ac90 to 71db155 Compare May 21, 2024 21:12
@aritzolea aritzolea force-pushed the 16.0-fix-l10n_es_aeat_mod347 branch from 71db155 to 54779b6 Compare May 22, 2024 07:02
@aritzolea aritzolea force-pushed the 16.0-fix-l10n_es_aeat_mod347 branch from 54779b6 to 2922707 Compare May 22, 2024 07:10
Copy link

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Sep 22, 2024
@github-actions github-actions bot closed this Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants