Implementar extension attributes

[barbanet]

Hay que avanzar en la definición de cómo implementar y usar los atributos.
La idea original ha sido Extension Attributes, pero quedan cuestiones por clarificar.

Algunos de los temas mencionados han sido:

• Agregar los atributos para customer
• Agregar los atributos para customer_address (usados para billing y shipping)
• En los 3 casos debe ser por configuración que se soliciten o no los atributos.

[olivertar]

Hice algunas pruebas sobre el codigo. Agregué los dos atributos según las especificaciones a la entidad customer address y una columna por cada atributo en las tablas quote_address y sales_order_address. Actualice las plantillas text y html en el backend e hice las modificaciones necesarias a las plantillas para editar las address desde el user account.

Todo muy lindo (sacando un problemita originado en una diferencia entre los cores 2.2 y 2.3 que casi me decide a abandonar Magento y dedicarme a wordpress o vender repasadores en un semaforo) fue un buen ejercicio para practicar como agregar atributos a las address pero no parece usable.

Pienso, despues de emplear unas cuantas horas, que seria muy bueno que alguien haga los casos de uso.
De esa manera vamos a poder saber como implementarlo.

Si lo que se necesita solo es que estos valores esten en el order (discriminado en shipping y billing) la cosa es simple. Si ademas necesitamos persistir el dato para reciclarlo independientemente del address. Agregar solo los atributos es insuficiente y no tengo idea como deberia verse en el frontend.

Ideas, sugerencias???

[manuelcanepa]

Pensemoslo como el TAX VAT. Que esta tanto en address como en customer. Esta decision, de tenerlo en ambos, fue para abarcar las posibilidades de uso y tener el control del atributo en un mismo modulo. Podria suceder que se necesite identificar al cliente con un documento, y va a necesitarse el documento en la direccion. Al momento de cargar la primer direccion, el documento se completa con ese dato, y luego ya queda ese valor.

[barbanet]

@olivertar Desde que conversamos esto mismo he estado intentando dar con lo que nos llevó a decidirlo así en la grooming.
No recuerdo exactamente los motivos listos (mala no haber anotado mejor eso), pero creo que había un caso más allá de lo que comenta @manuelcanepa .
Si bien el VAT se permite manejar en dos niveles dados los posbiles escenarios claramente identificados (documentación oficial, en el caso del DNI parecería que no.
(Y justo ahora me acabo de acordar un caso que le da sentido).
El usuario es una persona que en su cuenta de usuario figura con DNI, pero quien paga es una empresa (por lo que en el billing address debe llevar el CUIT de la empresa para la factura), y quien recibe es un cliente porque le hiciste un regalo empresarial (el shipping address debe llevar otro CUIT, o quizás otro tipo de documento).
Creo que eso explicaría el por qué. ¿No? (se escuchan alternativas para poder, ahora si, armar los casos si es que tiene sentido)

[manuelcanepa]

Dado que este módulo surgió a partir de la idea de realizar FE, según recuerdo, fueron planteando casos hipotéticos con respecto a la facturación. Se que no aporto nada específico en mi comentario, pero tal vez ayudo a recordar por donde venía la mano.

[olivertar]

@manuelcanepa entiendo lo que tratas de explicarme con el ejemplo del VAT, algo similar hable con @barbanet en privado.

Un poco por duro, otro poco por ser un dev exiliado y tener poca experiencia con implementaciones en Arg es que no entiendo como implementarlo en el frontend.
En realidad, ahora que lo pienso, tampoco me cierra como esta implementado el VAT en Magento... Mhhhh tal vez estemos a punto de revolucionar el mundo de Magento...

En que estamos de acuerdo (pienso yo):

• El shipping address debe incluir la informacion del documento del usuario
• El billing address debe incluir la informacion del documento del usuario
• Los documentos del usuario incluidos en el shipping y en el billing deben ser independientes una vez creada la orden.
• La informacion del documento del user debe estar accesible en el objeto order (getOrder()->getShippingAddress()->getDocumentoBla() y getOrder()->getBillingAddress()->getDocumentoBla())
  La informacion del ducumento del user debe estar disponible cuando se solicita la orden via API

Que es lo que veo mal del ejemplo del VAT:

• El VAT no es solicitado en el checkout ni en shipping ni en billing, incluso aunque lo configuremos como requerido.
• El VAT es parte de customer, asi que solo es requerido en el registro del usuario. Si se permite checkout as guest user, jamas conoceremos el VAT :(
• Si no permitimos checkout as guest user, Magento nos propone (nos obliga) a registrarnos como paso previo al checkout. La verdad que es una opcion berreta y que resta opciones de personalizacion... no vamos a discutir aca las razones de mi afirmacion.

Opciones...
Gestionamos los documentos como atributos de la entidad customer address (es lo que tengo codificado ahora).
En contra, no lo asocia al customer..... ponele que le buscamos la vuelta (y al reves que Magento an Adobe company) tomamos la direccion desde el checkout y se la adherimos al customer si no es guest.
No me quiero meter en este berenjenal de saber cual documento usar si el que uso en el shipping o el del billing (si son distintos) porque esta opcion es una merda y al menos yo dudo que la implemente.
El gran (gran con mayusculas) problema de esta opcion es que el documento queda abroquelado al address y si el usuario quiere reciclar el address pero con otro documento (caso mas probable en el shipping) es imposible salvo que agregue una direccion nueva... creo que no hace falta que explique lo anodino que esto seria.

Que me parece que hay que hacer (y esto si me da un poco de miedo...)
Crear una entidad nueva customer_document y al igual que customer_address tener la opcion shipping y billing.
A nivel checkout frontend podemos incluir el formulario a continuacion de cada address y permitirle al user administrarlo igual que los address: usar el default, seleccionar uno existente en un dropdown, agregar uno nuevo.
A nivel udser dashboard, lo mismo, tendriamos una seccion "mis documentos" (tranquilos Bill Gates no me ha cooptado)
Si es necesario vincularlo al user, asi como hay un check "use for shipping default" podemos poner un check "use as user ID default" (sonó espantoso esto, espero se entienda).
La otra ventaja, pienso yo, seria mucho menos trraumatico manejar las opciones de visualizacion (tipos de doc, mostrar en shipping, mostrar en billing, no mostrar, mostrar ambos, requerido, opcional)

Muy delirante todo esto? Ideas? Aportes!!!