Hola @guillermo_lab, @javieradmin y @silvia_iberia.
El problema con los overrides directos como el que intentas en CartControllerCore::processUpdateQty() es que no solo son frágiles, sino que también pueden ser insuficientes porque, como bien señala @javieradmin, no cubren todos los escenarios de actualización del carrito y su integración con el frontend de PrestaShop 1.7 para mostrar errores de forma consistente puede ser compleja.
La mejor forma de abordar esto, si no quieres un módulo, sería a través de un módulo personalizado que implemente un hook más genérico y robusto, como hookActionCartSave o hookActionFrontControllerSetMedia para inyectar JavaScript que valide al cliente. Sin embargo, para una validación en el backend, hookActionCartSave es el camino, o incluso hookActionValidateOrder si la validación es justo antes de crear el pedido.
Aquí tienes un ejemplo de cómo podrías implementar la lógica en un módulo, usando hookActionCartSave para un control más temprano. Este código iría en el archivo .php de tu módulo personalizado:
public function hookActionCartSave($params)
{
if (!isset($params['cart']) || !Validate::isLoadedObject($params['cart'])) {
return;
}
$cart = $params['cart'];
$customer = new Customer($cart->id_customer);
if (!Validate::isLoadedObject($customer)) {
return;
}
Este hook te permite ejecutar lógica cada vez que el carrito se actualiza. La clave es que la validación debe ser robusta y los límites configurables. Mi recomendación para evitar la complejidad de un desarrollo a medida y asegurar la compatibilidad con futuras versiones de PrestaShop sería usar una solución dedicada que ya maneje todos los casos y la interfaz de usuario. Puedes gestionar valor máximo de compra sin tocar el código core con un módulo específico para ello. Este tipo de módulos suelen venir con su propia configuración en el back office para los límites por grupo, lo que simplifica mucho la gestión.