Sync worker for ODK forms v1 (for TopaDengue ODK form)

[cdparra]

Given a spreadsheet produced by a ODK Entomological Community form, implement a worker that

1. Translates the data in the ODK form into DengueChat CSV
2. Imports the produced CSV into DengueChat, firing the update of charts generation.
3. Marks the data that was already synced in the spreadsheet

TopaDengue Spreadsheet produced by ODK form for TopaDengue (the URL to this spreadsheet should be a parameter)

Obs.: if it is easier to directly upload the data to DengueChat (without first producing the DengueChat CSV and then importing this CSV, let's follow this path instead). See comments for all the details on how to map data into DengueChat (in spanish).

[cdparra]

Se creó una nueva versión del formulario de relevamiento entomológico que permite cargar múltiples visitas y múltiples criaderos por visita. La última versión del spreadsheet donde se carga es la siguiente

SPECS de la planilla resultante de ODK

1. Hoja Sheet 1 = mapear a locations existente

La hoja Sheet 1 contiene la información de la casa. En DC, cada casa es un registro en la tabla locations cuya columna address contiene el ID que utilizamos para identificar a las casas. Todos los IDs tienen la siguiente forma MMMMMCCCT donde MMMMM es un número de 5 cifras que identifica el número de manzana, CCC es el número relativo de la casa en dicha manzana y T es uno o dos caracteres que representan el tipo de ubicación (e.g., V = Vivienda, C = Casa). Esta hoja de la planilla contiene las siguientes columnas: data-metadata_collection_date = fecha de carga del formulario data-metadata_start_time = tiempo de inicio de la carga data-location-location_code = código de barras leído (e.g., 29030001C) data-location_data-location_code_manual = sección del código de barras que corresponde a address en DC data-location_data-location_type = parte del código de barras que corresponde al tipo de location data-location_data-location_coordinates = nuevas coordenadas (lat,lon) registradas (por ahora no usamos, hay que definir una estrategia para decidir cuando reemplazar las coordenadas previamente establecidas) data-location_data-location_coordinates-altitude = nuevas coordenadas (altitud) registradas (por ahora no usamos, hay que definir una estrategia para decidir cuando reemplazar las coordenadas previamente establecidas) data-location_data-location_coordinates-accuracy = nuevas coordenadas (precisión) registradas (por ahora no usamos, hay que definir una estrategia para decidir cuando reemplazar las coordenadas previamente establecidas) data-visit_group = enlace a la hoja en la que están registradas las visitas correspondientes a este registro data-metadata_end_time = tiempo en que se finalizó la carga data-metadata_device_id = ID del dispositivo desde donde se cargó KEY = identificador único de este registro de location para la carga de la fecha

2. Hoja data-visit_group = crear nuevo registro en visits

La hoja data-visit_group contiene la información cada visita registrada para cada location que se cargó en Sheet 1. Las visitas se guardan en la tabla visit de DC, que se asocia a a un location por medio del location_id. Contiene las siguientes columnas: data-visit_group-visit_date = fecha de la visita (mapear a columna visited_at de tabla visit de DC) data-visit_group-location_status = estado de la casa. Si es C (cerrada) o R (rechazada) no se realizó la visita y no se important los datos data-visit_group-visit_form-visit-visit_host_gender = sexo de la persona que recibió a los voluntarios data-visit_group-visit_form-visit-visit_host_age = edad de la persona que recibió a los voluntarios data-visit_group-visit_form-visit-services_fumigation = si senepa visitó la casa para fumigar en los últimos 15 días data-visit_group-visit_form-visit-services_larvicide = si senepa visitó la casa para aplicar larvicidas en los últimos 15 días data-visit_group-visit_form-visit-visit_obs = otras observaciones de la visita data-visit_group-visit_form-autoreporte = si es 1, la persona reporta que hubieron casos de dengue, zika o chik en esta casa data-visit_group-visit_form-auto_report_numbers-auto_report_number_dengue = número de casos de dengue reportados data-visit_group-visit_form-auto_report_numbers-auto_report_number_chik = número de casos de chikungunya reportados data-visit_group-visit_form-auto_report_numbers-auto_reporte_number_zika = número de casos de zika reportados data-visit_group-visit_form-auto_report_numbers-auto_report_zika_number_pregnant = número de embarazadas con zika reportados data-visit_group-visit_form-symptoms = si es 1, existe alguien con síntomas en la casa data-visit_group-visit_form-symptoms_report-symptoms_gender = sexo de la persona con síntomas data-visit_group-visit_form-symptoms_report-symptom_list = síntomas que se reportan (números que corresponden a una lista presentada en el formulario) data-visit_group-inspection = enlace a la hoja en la que están registradas las inspecciones correspondientes a esta visita PARENT_KEY = id del location en el Sheet 1 al que corresponde esta visita KEY = ID único de este registro en el formulario

Observaciones: para cada visita, los datos adicionales que aquí se registran se guardarán en la columan questions en formato JSON siguiendo el siguiente formato:

[
    {
        "code":"[nombre del campo en spreadsheet, e.g., data-visit_group-visit_form-visit-visit_host_age]",
        "body": "[texto de la pregunta, si está disponible, esto está en nuestro formulario ODK]"
        "answer":"[valor de la respuesta]"
    }
]

Para los datos de casos de dengue, zika o chikungunya reportado, usar la siguiente fórmula para poner el dato en la columna health_reports de la tabla visits: nDmClZ donde n es el número de casos de dengue, m es el número de casos de Chikungunya, y l es el número de casos de Zika. Por ejemplo, una casa que reportó 1 caso de dengue entonces tendría 1D en esta columna (omitimos los 0).

En la columna source de visits, usemos la fórmula ODK_build_DengueChat-Ento-Form_1536101844 (este nombre debería ser configurable para identificar al formulario ODK desde el que se cargó).

En csv_id se hace referencia a la tabla csvs. En esta tabla se crea un registro cuando se importan CSVs (archivos en excel en formato de DC) a través de la web app de DC. Hay que ver si es necesario crear o no este registro para asegurar que se ejecuten los workers que generan los charts.

Para referencia, la lista de síntomas es la siguiente:

    1. Fiebre
    2. Malestar
    3. Dolor muscular
    4. Dolor articular
    5. Dolor abdominal
    6. Brote de color rojo en el cuerpo
    7. Conjunctivitis
    8. Dolor de cabeza
    9. Otro

3. Hoja data-visit_group-inspection = crear nuevo registro en inspections

La hoja data-visit_group-inspection contiene la información cada criadero registrado en la visita correspondiente, identificada por la columna PARENT_KEY en la hoja data-visit_group. Las inspecciones se guardan en la tabla inspections de DC, que se asocia a a una visita por medio del visit_id. Contiene las siguientes columnas: data-visit_group-inspection-breeding_site_code = código del criadero que identifica a un tipo de criadero según la lista de la tabla breeding_sites cuya columna code se iguala a este código. data-visit_group-inspection-breeding_site_amount = cantidad de criaderos del tipo identificados, implica crear múltiples inspections del mismo tipo y con el mismo estado data-visit_group-inspection-br_protected = si está protegido, mapea a columna protected que es booleano data-visit_group-inspection-br_larvae = si tenía larvas, mapea a columna larvae que es booleano data-visit_group-inspection-br_pupae = si tenía pupas, mapea a columna pupae que es booleano data-visit_group-inspection-breeding_site_description = observación adicional, mapea a columna description data-visit_group-inspection-br_picture = enlace a una imagen, se debe subir según el servicio de file upload de DC y luego completar before_photo_file_name y before_photo_content_type data-visit_group-inspection-br_elimination_date = eliminated_at data-visit_group-inspection-br_elimination_picture = enlace a una imagen de la eliminación, se debe subir según el servicio de file upload de DC y luego completar after_photo_file_name y after_photo_content_type PARENT_KEY = id del visit en el data-visit_group al que corresponde esta visita KEY = ID único de este registro en el formulario

la fecha de la visita se debe usar para la columna inspected_at

Observaciones: para cada visita, los datos adicionales que aquí se registran se guardarán en la columan questions en formato JSON siguiendo el siguiente formato:

[
    {
        "code":"[nombre del campo en spreadsheet, e.g., data-visit_group-visit_form-visit-visit_host_age]",
        "body": "[texto de la pregunta, si está disponible, esto está en nuestro formulario ODK]"
        "answer":"[valor de la respuesta]"
    }
]

[cdparra]

Si se usa el import de DC, el import de DC espera un archivo .xls como este. El método de import a usar es el mismo que está disponible en esta ruta de DC: https://www.denguechat.org/csv_reports/batch que se usa para hacer import de CSVs con datos correspondientes a locations que ya existen.

Verificar según los SPECs del comentario anterior para entender como mapear a este spreadsheet. Lo importante es que el archivo .xls tenga como nombre de archivo el nombre (i.e., address) del location (e.g., 29030001.xls). Las columnas de esta planilla son las siguientes:

Fecha de visita (YYYY-MM-DD) = contiene fechas de visitas Auto-reporte dengue/chik = lo mismo que health_reports de visits Tipo de criadero = código de criadero seguido del número (e.g., B4) Localización = no usamos ¿Protegido? = protected ¿Abatizado? = o usamos ¿Larvas? = larvas ¿Pupas? = pupas ¿Foto de criadero? = solo indica si hay o no foto Fecha de eliminación (YYYY-MM-DD) = eliminated_at ¿Foto de eliminación? = solo indica si hay o no foto de eliminación Comentarios sobre tipo y/o eliminación = description de eliminación

[cdparra]

@vanecanhete @morozevich si no pueden levantar denguetorpedo localmente, usen directamente la instancia de testing (@morozevich puede agregar public keys para acceso ssh y también @yolile puede hacerlo)

[cdparra]

@ricpar11 below requested changes:

• [x] The same spreadsheet will be used multiple times, so make sure the worker knows what was the last row that was processed. Restart this number only if the URLs to the spreadsheet change.
• [x] Make sure duplicates are not processed. Rows might get duplicated in each CSV. The column to control for this in each CSV is always KEY (this applies to all three CSVs: locations, visits, inspections). If a row with KEY x was already processed, there is no need to process it again should you enconter it again. Notice that in the visits CSV, the key is equal to location KEY/visit_group[N], where N = 1...N. Similarly, in inspections it is `location KEY/visit_group[N]/inspection_group[M] where M = 1...M. - We need to store what keys were already processed somewhere.
• [x] Use column names instead of numbers for matching: the first row in the spreadsheet contains the column names (which match the name of the fields in the xml_form). You can read this row at the beginning to decide what column number matches each different model and field in DC.
• [x] Location address: use data-location-location_code. Notice that it will contain the location code + the type of location (i.e., 29000001V), therefore, use only the first 8 characters that correspond to the location number (i.e., 29000001, without the V). If this is an empty string (could sometimes contain spaces, so trim it), look in data-location-location_code_manual. If this is also empty, use data-location_data-location_code_manual (that's from version 1 of the form). Always use only the first 8 chars.
• [x] Visit fields: in some rows, the field names from an old version of the form is used. Below is the mapping from the current field names to the old ones. The logic here is the same as with location: if the current field is empty (considering also as empty a string with spaces, check if the alternative field contains the data. Notice that in all of the alternatives, the difference is just an extra -visit before after visit_form. CURRENT FIELD NAME => ALTERNATIVE FIELD NAME (from old form) data-visit_group-visit_date => NO ALTERNATIVE data-visit_group-location_status => NO ALTERNATIVE data-visit_group-visit_form-visit-visit_host_gender => NO ALTERNATIVE data-visit_group-visit_form-visit-visit_host_age => NO ALTERNATIVE data-visit_group-visit_form-visit_obs => data-visit_group-visit_form-visit-visit_obs data-visit_group-visit_form-autoreporte => data-visit_group-visit_form-visit-autoreporte data-visit_group-visit_form-auto_report_numbers-auto_report_number_dengue => data-visit_group-visit_form-visit-auto_report_numbers-auto_report_number_dengue data-visit_group-visit_form-auto_report_numbers-auto_report_number_chik => data-visit_group-visit_form-visit-auto_report_numbers-auto_report_number_chik data-visit_group-visit_form-auto_report_numbers-auto_reporte_number_zika => data-visit_group-visit_form-visit-auto_report_numbers-auto_reporte_number_zika data-visit_group-visit_form-auto_report_numbers-auto_report_zika_number_pregnant => data-visit_group-visit_form-visit-auto_report_numbers-auto_report_zika_number_pregnant data-visit_group-visit_form-symptoms => data-visit_group-visit_form-visit-symptoms data-visit_group-visit_form-symptoms_report-symptoms_gender => data-visit_group-visit_form-visit-symptoms_report-symptoms_gender data-visit_group-visit_form-symptoms_report-symptom_list => data-visit_group-visit_form-visit-symptoms_report-symptom_list data-visit_group-visit_form-services_larvicide => data-visit_group-visit_form-visit-services_larvicide data-visit_group-visit_form-services_fumigation => data-visit_group-visit_form-visit-services_fumigation
• [x] Username: in some rows, a username will be provided in data-user_denguechat (as part of the location csv). Let's use it to associate data to username in DC (if the username exisits)
• Form metadata: let's save somewhere (perhaps in the questions field) the metadata of the form, located in the locations CSV. The following metadata would be interesting to save: data-metadata_device_id and KEY.

[cdparra]

Done on PR #858