cambiamos la redireccion en caso de que no se permitan los pesos, para que el pedido se encuentre en la misma pantalla ante error.
solamente el owner puede ir al 'details'.

damos un prefijo condicional ('orders/') si es que estamos en el 'allOrders/' para todos los items de menu (se debe ir si o si a orders/*)
solamente el owner puede ir al 'details'.
las reglas de isOwner, isSuperUser, e isAssistant checkean directamente el valor contra estado de sesion (podrian haber llamado APCRUDUtils para obtener cleinte y asistente, pero estoy contra reloj).

cambiamos las 'x' por 'r' en los rechazos.
en unavailable vamos a allOrders/list si el pedido no nos pertenece.

lo mismo al momento de forwardear y cancelar.

lo mismo al tomar una decision (el pedido ahi siempre sera ajeno asi que nos vamos al list). adicionalmente ahi tenemos que tener en cuenta que teniamos mal una cerradura (para evaluar el cambio de valor la misma debia tomar la decision por referencia) y un 'else' que faltaba me evaluaba en false la condicion de botones si es que no estaba presionado 'rechazar'. finalmente, sobraba un mensaje flash (por lo cual borre el predeterminado) y para rematarla un poco me habia olvidado de cambiar las referencias a las vistas: estaban las de cancelacion en lugar de las de aprobacion y rechazo.
estaba mal peusta una redireccion. debia ser un array. sino se asume que era un ID (no se xq pero es asi).
no permitimos la accion view a los superusuarios
cambiamos el isOwner para que vea si el cliente actual conectado o supercliente, es dueño del pedido
cambiamos la condicion del mail que mandamos: el que se condiciona durante la termianda es el mail de asesor, y no el de cliente. el de cliente se manda siempre.
ajusta precios de los productos a los detalles cuando se aprueba un pedido.
cuando el pedido sea preliminar y se mueva (en este caso es pedido de administrador), o cuando el pedido sea aprobado, se marcan los precios.