Cambios en la API pública de Crehana.
Nuevo reporte: resultados de competencias de Talent
GET /api/v5/rest/org/{organization_slug}/reports/talent/competences-results/
devuelve el resultado de la evaluación de competencias de cada colaborador, con
una fila por colaborador y proceso de competencias. Es el mismo dato que el
admin ve en Talent una vez aplicada la escala de resultados del proceso, sin
tener que descargar el Excel de “Respuestas cuestionarios finalizados”.
Cada fila trae el proceso (evaluation_id, process_id, process_name,
process_status, process_end_date, max_scale), el colaborador
(employee_id, centralized_user_id, nombre, correo, documento, estado,
departamento, área, cargo, sede, nivel y correo del jefe) y el resultado:
configured_scale_result (en la escala del proceso, ver max_scale),
configured_percentage_result (normalmente 0–100), configured_label y
configured_semaphore_color (el nivel del semáforo tal como lo resolvió Talent)
y updated_at.
Filtros opcionales: evaluation_id (el número de la evaluación que ve el admin
en Talent) y centralized_user_id. Sin filtros recibís todos los procesos de
competencias de la organización. La paginación es por cursor, como en los
reportes de marcas: pedís limit (de 1 a 500, por defecto 100) y, para la
página siguiente, reenviás next_cursor en cursor tal cual, sin
interpretarlo; has_next_page te dice si queda algo por recorrer. Las filas
vienen ordenadas por proceso y colaborador, así que el recorrido es estable y
cada página cuesta lo mismo sin importar cuán adentro estés.
configured_percentage_result viaja tal como lo calcula Talent. En casos
puntuales, por configuraciones de escala atípicas, puede superar 100; si vas a
promediarlo, acotalo a [0, 100] antes. Un colaborador que todavía no tiene
resultado llega con esos campos en null, no en cero.
Sólo se listan resultados de la organización de la api-key: pedir el slug de
otra organización responde con error, no con datos. Un limit fuera de rango o
un evaluation_id que no sea un entero positivo responden 422.
Asistencia: centralized_user_id tiene que ser un entero positivo
En los reportes de asistencia que filtran por colaborador
(/reports/attendance/shifts-schedule/, /reports/attendance/marks/ y
/reports/attendance/daily-management/), centralized_user_id=0 ahora responde
422. Antes se ignoraba en silencio y devolvía la organización completa con
200, como si no hubieras filtrado. Si tu integración mandaba 0 para decir
“sin filtro”, omití el parámetro.
