Recursos-V2
RECURSOS
Endpoints expuestos
Enterprise module
api_recursos.add_resource(EnterpriseAPI, "/enterprise", "/enterprise/<uuid:enterprise_uuid>")
api_recursos.add_resource(EnterprisePhotoAPI, "/enterprise/image/<uuid:enterprise_uuid>")
api_recursos.add_resource(EnterprisePreventiveUnitsAPI, "/enterprise/prevm")
Staff module
api_recursos.add_resource(StaffAPI, "/staff", "/staff/<uuid:staff_uuid>")
api_recursos.add_resource(StaffRolesAPI, "/staff/roles")
api_recursos.add_resource(StaffApplicationTypeAPI, "/staff/application_type")
api_recursos.add_resource(StaffRelationypeAPI, "/staff/relation_type")
Machine module
api_recursos.add_resource(MachineAPI, "/machine", "/machine/<uuid:machine_uuid>")
api_recursos.add_resource(MachineDocumentsAPI, "/machine/<machine_uuid>/documents", "/machine/<uuid:machine_uuid>/documents/<uuid:document_uuid>")
api_recursos.add_resource(MachineStatusAPI, "/machine/status")
api_recursos.add_resource(MachineTypesAPI, "/machine/type")
api_recursos.add_resource(MachineProperyAPI, "/machine/property")
api_recursos.add_resource(MachinePhotoAPI, "/machine/image/<uuid:machine_uuid>")
MODELOS
Enterprise
{
"id": 1,
"nombre": "Auravant SRL",
"cuit": "20223334441",
"renspa": "R1234",
"rea": "A5678",
"direccion": "Calle 123",
"localidad": "Ciudad 1",
"c_postal": "1234",
"provincia": "Provincia 1",
"tel_fijo": "011-123888",
"tel_movil": "011-98765432",
"e_mail": "empresa1@example.com",
"partido": "Partido 1",
"nota": "Nota 1",
"fecha_ini": "2023-02-23T13:09:20Z",
"fecha_fin": null,
"enterprise_uuid": "ae9d10c7-a0eb-4bf5-9ba4-12bba4855579",
"user_id": 62998,
"farms_id": [55718],
"is_owner": true,
"farms_uuid": ["600a5750-603f-11ed-97b4-4196c331e961"],
"preventive_measures": [3,6],
}
Staff
{
"person_id": 71,
"name": "José Pedro",
"last_name": "Balmaceda Pascal",
"phone_number": "157412",
"user_id": 62998,
"created_at": "2023-03-28T13:35:28Z",
"deleted_at": null,
"staff_uuid": "b7c26058-0793-46cc-af10-470fcc2f2461",
"cuit": "asdfasd1|2312",
"ropo": ",e",
"address": "cambio",
"town": "La matanza avanza cambio ",
"zipcode": "1458",
"province": "d32d",
"representation": null,
"email": "cambiio@pepe.com",
"note": "patch",
"staff_relation_id": 2,
"farms_id": [72560],
"application": [2,4],
"is_owner": false,
"farms_uuid": ["892b4b64-5f6a-4365-8bd6-0e94b01dbae6"],
"rol_id": [1,6,8]
}
Machine
{
"machine_id": 1,
"machine_uuid": "a8fee0e4-91fe-403c-a954-3732709f86d8",
"name": "Máquina 1",
"license": "123ABC",
"brand": "Marca 1",
"model": "Modelo 1",
"fuel_consumption": 10,
"fuel_consumption_unit": "litros/hora",
"note": "Nota 1",
"purchase_date": "2022-01-01",
"purchase_cost": 10000.0,
"purchase_cost_unit": "USD",
"machine_type_id": 1,
"created_at": "2023-03-03T13:32:47Z",
"deleted_at": null,
"roma": null,
"status_id": 1,
"property_id": 1,
"user_id": 62998,
"property_name": "Propia",
"status_name": "Activo",
"is_owner": true,
"farms_id": [72560],
"farms_uuid": ["892b4b64-5f6a-4365-8bd6-0e94b01dbae6"],
}
Info sobre recursos
Todos los recursos tienen una similar estructura pero diferentes atributos. Algo que los tres comparten son campos, es lo unico en comun.
Mas adelante se informara como es la edicion de los campos y que hay que tener en cuenta.
Como hay una interseccion entre todos los recursos que todos contienen el dato FARM esto nos permite relacionarlos entre si, es decir, desde una empresa puedo ver sus maquinarias y personal asociado, ya que todo se relaciona por FARM. (Tambien desde una maquinaria veo que empresa tiene asociada y lo mismo con staff)
APIS
GET
Modelos de personas y maquianria tienen dos caminos y empresas tieene 3. Los tres tienen el camino comun de recibir un uuid y devolver el especifico recurso.
Lo importante de estos metodos es que como no esta implementado el nuevo esquema de permisos usamos la funcion
get_farms_list()
Que es una funcion pseudo get_fields que te devuelve todas los campos que un usuario tiene acceso. Esto se da ya del lado de producto se definio que cualquier persona con acceso a un campo debera poder ver todos los recursos del mismo.
Los usuario veran todas los recursos asociados a campos que tengan acceso Y RECURSOS CREADOS POR ELLOS MISMOS (puede pasar que crees un recurso, sin campo)
Las apis filtran por campo. Si se recibe un campo se usa un bool llamado "farm_filter" esto se usa para eliminar la parte de la query que hace referencia a los recursos de cada usuario particular. Esto es para que cuando filtren por campo SOLO TRAIGA los que cumplan con el criterio de campo asociado y no los que creo.
El get de empresas tambien tiene un 3 camino como se menciono antes. Este camino lo que hace es buscar en la db las empresas y campos del usuario asi pueden usarlo para otro feature de mostrar los campos agrupados por empresa
PERMISOS CREACION/EDICION/ELIMINACION DE RECURSOS
Hay dos validaciones en el momento de como crear/modiificar un recurso en el momento de escritura de esta docu:
- Edicion de datos QUE NO SEAN FARM de un recurso
- Edicion de FARM del recurso.
1. Datos NO FARM
Para poder editar/eliminar un recurso el unico requerimietno en pie es que seas el creador/propietario de este recurso. Nadie mas puede editar/eliminar dicho recurso. Ejemplo, El usuario 1 crea a la empresa "Pepe.SA" SOLO EL USUARIO 1 PUEDE EDITARLA, si el usuario 2 tiene acceso a los campos que la empresa Pepe.SA tiene asociados podra verlo en el listado, pero no podra hacer ninguna accion sobre la misma. (esto es igual para los 3 recursos)
2. Dato FARM
El dato Farm de los recursos tiene un permiso asociado, es el unico dato que hoy en dia tiene una validacion tanto de front como de back para ser modificado. En resumen, el permiso y como funciona es que uno puede asociar y desasociar campos en los cuales tenga roles de administracion u ownership. Esto esta con un permiiso correspondiente en cada recurso:
- 900 → Asociar campo a staff
- 902 → Asociar campo a enterprise
- 903 → Asociar campo a machine
A tener en cuenta:
-
Si se crea un recurso asociando campos de primera y no tiene permisos sobre esos campos el back acepta la request, crea dicho recurso pero no le asigna un campo. El usuario igual seguira podiendo ver dicho recurso en su listado
-
Si se genera una edicion de un recurso y se cambia valores propios del recurso y ademas los campos y no tiene el permiso requerido, los cambios del recurso se ven afectados pero no modificara los campos de dicho recurso
No existe ninguna restriccion en pie de creacion, cualquier usuario puede crear los recursos que quiera
Logica
Como recursos se maneja con modelos, todos tienen sus metodos create,update,delete,list.
List
es un list simple, es un metodo load_from_db() que recibe un uuid y te lo trae, despues tenes un to_dict y pipicucu
Create
Aca entra un poco de logica, minima. Caminos posibles:
- Recurso sin campos asociados
- Recurso con campos asociados.
Sin campos es un simple insert de los datos ingresados. En caso de tener campos se agrega una query extra para ingresar datos en la tabla intermedio entre el recurso-farm
UPDATE
Al tener un modelo que primero lo trae de la base de datos, en caso de ingresar un valor en nulo o un valor no es ingresado no se pisa, siempre se usa el de la db El modelo de recursos cuentan con listas de datos. ejemplo farms, application(staff), rol(stff) etc etc. Estos son listas de uno o mas valores, para actualizarlos se debe recibir la lista entera de datos. El update lo que hace es generar un set con los datos de la db, otro set con lo que ingresa para modificar del recurso
set1 = set(self.farms_id) if self.farms_id else set()
set2 = set(farms)
eliminate = tuple(set1 - set2)
add = list(set2 - set1)
los eliminate seran eliminados del recurso y los add seran agregados (EJEMPLO SOLO DE EMPRESA)
query = ""
if eliminate:
query += """
UPDATE resources_enterprise_farm
SET deleted_at = now() AT time ZONE 'UTC'
WHERE enterprise_id = %(ent_id)s AND farm_id IN %(farms_to_update)s;
"""
if add:
query += """
INSERT INTO resources_enterprise_farm(enterprise_id,farm_id)
VALUES (%(ent_id)s, UNNEST(%(farms_to_insert)s))
"""
if query:
db_query(query, {"ent_id": self.id, "farms_to_insert": add, "farms_to_update": eliminate})
Esto sirve para todos las listas de los recursos pero cada tabla especifica de cada uno
DELETE
Simplemente deletea el recurso
Alguns recursos (por el momento) tienen la opcion de subirles imagenes. Estas iimagenes se suben a s3 con el uuid de la imagen y con directorios correspondientes. Tenes expuesto un get,post y patch.
Para esto priimero si o si se necesita creado el recurso y despues se sube la imagen, el flujo correcto es ese, otro flujo puede generar problemas.