Filtrar estados de pedido en el desplegable del administrador

[Manuel_GT]

Hola!

Por la personalización del proyecto me veo en la necesidad de ocultar determinados estados de pedido en el combo de cambio de estado. En particular, cuando un pedido es cancelado y pasa a ese estado, no debería poder volver a activarse mediante ese selector.

¿Alguien ha necesitado hacer esto antes? ¿Hay algún hook que permita filtrar u ocultar ese selector?

Además hay varios sitios distintos desde donde puede hacerse esto (yo he contado tres) lo que lo complica aún más.

Si esto es imposible, ¿se podría detener el proceso de cambio de estado mediante un hook? He estado mirando tanto

ActionOrderStatusPostUpdate como actionOrderStatusUpdate pero no parece que haya una forma de parar el proceso si no es lanzando una excepción.

El ideal sería poder comprobar en el hook el estado actual y nuevo y volver con un mensaje en caso de que no se permita el cambio.

[ventura]

Creo que lo mas practico seria hacerlo mediante un módulo con un controller que incluya una funcion ajax para que dependiendo del history del pedido muestre una opciones de selección u otras mediante js

[Manuel_GT]

Gracias @ventura

Si no encuentro nada probaré lo que propones.

Un saludo

[ExpertoPrestaShop]

Puedes intentar hacer una dirección a la misma pagina pero con algún parámetro que indique el mensaje de error.

[Manuel_GT]

Hola!

Bueno, después de mucho buscar, al final he adoptado la solución propuesta por @ventura

No estoy satisfecho porque los estados están definidos a pelo en el javascript y deberían salir de la base de datos pero no he encontrado la forma de inyectar en el javascript la información. Podría hacerlo mediante ajax pero al ser asíncrono, un retraso de red puede dejar actuar al usuario antes de  que se ejecute el script.

Lo que hago es meter mediante el hook ActionAdminControllerSetMedia el js cuando el controller es "AdminOrders" trabajando solo en las páginas de ese controlador. En particular, el listado de pedidos y la página de detalle.

Para el listado inicialmente vacié los combos pues veía un poco complejo el filtrar los estados válidos para cada pedido del mismo, ya que esos desplegables están hechos con botones y NO contienen el Id del estado actual del pedido en cuestión, solo el texto, y no me parecía de recibo crear un array de estados con cadenas de un idioma determinado para comparar y sacar el Id. La chapuza llegó cuando vi que si seleccionamos varios pedidos en "bulk actions" se puede cambiar el estado de estos y eso lo hace mediante una flotante con un desplegable que contiene todos los estados en el idioma con sus ID. Esto, por un lado es un nuevo problema (otro sitio donde se puede cambiar el estado), pero por otro era la solución para poder obtener el Id de los pedidos según el idioma del administrador. Extrayendo estos datos del desplegable ya pude particularizar cada pedido del grid.

La página de detalle tiene la ventaja de referirse a un solo pedido, y además, tiene dos selectores con "options" que si se pueden manipular con facilidad por javascript así que esa parte no dio problemas.

Gracias de nuevo por los aportes. El tiempo dirá si la solución es o no sólida.

Un saludo.

 

[ventura]

En el listado de pedidos puedes obtener el id del pedido  y con ello mediante ajax el estado actual del pedido con el  td data-identifier de cada row. Y el identificador de cada estado del dropdown-menu js-choice-option con el data-value de cada botón.

Para la actualización masiva, haría falta obtener los ids de los pedidos seleccionados con order_orders_bulk y aplicar la lógica en el change_orders_status_new_order_status_id, siempre y cuando todos los seleccionados cumplan el mismo criterio en cuanto a history de pedido.

[Manuel_GT]

Hola @ventura

7 hours ago, ventura said:

En el listado de pedidos puedes obtener el id del pedido  y con ello mediante ajax el estado actual del pedido con el  td data-identifier de cada row. Y el identificador de cada estado del dropdown-menu js-choice-option con el data-value de cada botón.

Es lo que hago pero sin el ajax. Simplemente obtengo todos los valores posibles con sus textos del combo de bulkActions y empleo ese array para todas las filas del Grid. Me ahorro las 50 llamadas ajax asíncronas.

7 hours ago, ventura said:

Para la actualización masiva, haría falta obtener los ids de los pedidos seleccionados con order_orders_bulk y aplicar la lógica en el change_orders_status_new_order_status_id, siempre y cuando todos los seleccionados cumplan el mismo criterio en cuanto a history de pedido

Directamente para las bulk actions solo permito cancelar pedido.

Verás, el tema es que muchos de los estados del pedido se modifican de forma automática dependiendo de los almacenes, transportistas, etc. de manera que me interesa que el administrador pueda modificar manualmente lo menos posible para mantener la coherencia. Es por esto que tengo que cerrar tanto todo y no permitir que un pedido cancelado (que ha implicado su cancelación en almacenes y transportistas en cascada) pueda volver a pasar a otro estado como "en preparación". El lio sería impresionante y el trabajo para mantener la coherencia de todo excesivo.

Gracias. 😉

[ventura]

Hola @Manuel_GT

La idea sería realizar una sola petición asincrona para obtener la información de todos los resultados del listado y aplicar los cambios. Otra cosa será luego ver el funcionamiento compatible con la paginación del listado de pedidos

Tiene todo el sentido lo que indicas. Es un requerimiento de lógica de negocio.

Un saludo