[18.0][IMP] delivery_gls_asm: Fine-tuning of cancel_shipment button visibility

[carlos-lopez-tecnativa]

Display this button only when the carrier has the pickup service enabled, according to this feature.

Esto se agrego en el commit c07fdf8 de V14 pero se muestra siempre que sea GLS, mas solo deberia mostrarse cuando este activo el servicio de pickup. Provocando que con modulos como este OCA/delivery-carrier#1070 se vean 2 botones para Cancelar el envio. Esto no evita que cuando sea pickup, igual aparezcan 2 botones si se instalan ambos modulos, pero al menos se minimiza el issue visual
@Tecnativa @pedrobaeza @sergio-teruel pueden darle una mirada a este PR por favor

[OCA-git-bot]

Hi @hildickethan,
some modules you are maintaining are being modified, check this out!

[pedrobaeza]

Me falta algo de contexto. ¿Qué significa pickup service según GLS? Entiendo que es que lo recoja la agencia, ¿pero qué otras formas hay y por qué no se pueden cancelar?

[carlos-lopez-tecnativa]

Me falta algo de contexto. ¿Qué significa pickup service según GLS? Entiendo que es que lo recoja la agencia, ¿pero qué otras formas hay y por qué no se pueden cancelar?

Así es.
Pero Odoo, por lo general, solo muestra el botón cuando el albarán está en estado Hecho, y aquí, agregan un nuevo botón para mostrarlo cuando el picking no está en estado Hecho. Entiendo que el picking en ese caso se puede hacer antes de validarlo (no lo sé, no he probado eso); tampoco estoy muy familiarizado con esa funcionalidad, solo que me encontré que aparecía el botón duplicado con el otro PR que mencioné más arriba y quiero limitar un poco la visibilidad de este botón.
Aparte de este botón, que se muestra en estado diferente de Hecho, ya cuando sean otros carriers u otros servicios, ahí actuaría el botón de Odoo base.

[pedrobaeza]

Vale, voy entendiendo, pero parece que esto es lo mismo que delivery_pre_shipping, pero específico para GLS, y mandando información distinta. Creo que esto habría que luego regularizarlo en el otro módulo, con una API normalizada, y que éste dependería de él e implementara esa API. Es cierto que el caso del pre_shipping para el que se ha implementado es algo especial, y puede no casar 100%.

En fin, como mínimo vendría bien documentar estos pensamientos y roadmaps, que luego todo se olvida.

[carlos-lopez-tecnativa]

Vale, voy entendiendo, pero parece que esto es lo mismo que delivery_pre_shipping, pero específico para GLS, y mandando información distinta. Creo que esto habría que luego regularizarlo en el otro módulo, con una API normalizada, y que éste dependería de él e implementara esa API. Es cierto que el caso del pre_shipping para el que se ha implementado es algo especial, y puede no casar 100%.

En fin, como mínimo vendría bien documentar estos pensamientos y roadmaps, que luego todo se olvida.

La funcionalidad del módulo delivery_pre_shipping es más general e independiente de los carriers. Esta funcionalidad de pickup, entiendo, es específica de GLS; no sé si algún otro carrier tiene algo parecido, pero a simple vista no veo que sean lo mismo o que se puedan unificar.

[hildickethan]

Si no recuerdo mal, el caso de uso del pickup era cuando validas un albarán de devolución usas un transportista diferente de tipo recogida y no querían validar el albarán hasta recibir la devolucón, por lo tanto necesitaba un botón para crear el envío.
Para ese control de botones entiendo que la funcionalidad delivery_pre_shipping debería poder reemplazarlos ya que la idea es la misma

[pedrobaeza]

Al igual que tenemos delivery_state como unificador para tener un framework (voy a llamarlo así para no decir API) para solicitar el estado del envío, se puede tener un framework que defina métodos para "enviar antes". Ese enviar antes puede ser por dos razones:

• Enviarlo como si estuviera terminado, pero sin validar el albarán (el caso que tenemos).
• Solicitar que lo recojan para el envío antes de validar.

Si lo piensas, la diferencia entre ambos es muy pequeña, porque cuando tú envías con el albarán validado, en realidad puedes estar pidiendo que te lo recojan.

[pedrobaeza]

/ocabot merge patch

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 18.0-ocabot-merge-pr-4873-by-pedrobaeza-bump-patch, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 0e5b72b. Thanks a lot for contributing to OCA. ❤️