Carlos
700ddafba4
- Sistema de propiedades: tabla, modelo, CRUD API para que el cliente guarde direcciones nombradas - Postulacion renovada: cliente elige propiedad sin precio ni fecha, sube fotos a GCS/S3 - Proveedores ofertan date_1, date_2 y amount al postularse via pivot; sort por fecha/monto/membresia - Contratacion: selected_date recibe date_1 o date_2, amount desde pivot (depreca minimun_fee) - Cancelacion/repostulacion: archive con status=perdido, related_postulation_id para vincular - Chat en contratos activos: tabla contract_comments, controller, rutas web+API, vista panel, notificaciones bilingues - PaymentIntent calcula amount desde pivot en vez de recibirlo del front - getpendingcontracts: sin filtro de tiempo, filtra por status=active, agrega time_created - Expiracion de postulaciones reducida a 1000 min Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.6 KiB
Este documento tiene notas tanto para back como para front. El backend está hecho en Laravel y el front en Ionic, adecua las notas a tu área correspondiente. Los cambios a continuación son bastante radicales, asi que sugiero crear un branch que se llame “betos” para trabajar esto.
Los clientes deben de tener una tabla de propiedades (properties), que guarda las direcciones de sus propiedades (con coordenadas y numero exterior). Esto va a ser un cambio en category.ts, porque ahora donde dice Dirección va a ser Propiedad, con un listbox que se alimente de las propiedades ligadas al usuario de la siguente forma “Nombre de la propiedad: Dirección”, si no hay ninguna o el servicio no es para ninguna de estas, debe de abrirse el modal “Agregar Propiedad”, que pida la dirección (con autocomplete), guarde las coordenadas y el numero exterior (inputs hidden igual que en category.ts), y la guarde con un nombre personalizado asignado por el usuario (E incluso le puede poner un icono para designar si es casa u oficina).
Para las postulaciones vamos a tener cambios radicales; ahora el cliente solo pondrá la categoría, la propiedad y comentarios cuando quiera postular un servicio. Adiós a definir un precio y fecha. También es importante que el cliente pueda adjuntar fotos de lo que necesita que se repare o se instale.
Cuando el proveedor se postula a una postulación, debe definir una fecha en la que puede realizar el servicio y a que costo (ojo, la cuota mínima a nivel sistema se mantiene). Nota para back: eso también quiere decir que ahora ya no debe de haber un mínimum fee en la tabla de suppliers, y que la tabla pivote postulations_suppliers debe de guardar al menos dos fechas tentativas en las que puede dar el servicio y el monto que desea cobrar por el servicio.
En viewsuppliers el cliente debe de poder filtrar a los postulantes por fecha más pronta en la que se puede realizar el servicio, monto más barato y si el proveedor está certificado. Definir si es más fácil hacer estos sorts en front o en back
Una vez que la postulación se vuelva un CurrentContract, debemos de implementar la posibilidad de que el cliente y el proveedor se comuniquen dentro de la app de la misma manera que lo hacen en ReportDiscussion. Nota para back: Hay que agregar un botón en los Contratos Actuales que te permita ver la discusión de cada contrato y los detalles del contrato igual que lo hacemos ya en los Reportes.
Por último, con estos nuevos cambios se vuelve complicado determinar como manejaremos el NoHome, si tienes alguna idea eres libre de comentar. Dime si estoy omitiendo algo que sea importante o nos pueda dar problemas.