Pide una nueva funcionalidad

se sugiere agregar una etiqueta a los usuarios (similar a utilizada en los ciclos de vida de doc) que sean custom y podamos agruparlos según su puesto dentro de la empresa, de ese modo es mucho mas simple asignar permisos a compañeros del sector o detectar permisos heredados de posiciones anteriores que no debería tener. Seria útil tener una categoria que los agrupe y una etiqueta personal de cada usuario que a simple vista en el listado podamos saber cual es su actividad.

Sistema: Athento Tipo de requerimiento: Funcional Prioridad: Media-Baja (ajustable según necesidad) Descripción de la necesidad Actualmente, el sistema Athento permite el uso de formatos de fecha cortos, tales como: 13/07/2026 07/2026 Formatos numéricos de día y mes Sin embargo, no es posible configurar ni visualizar fechas en formato largo, por ejemplo: 15 de marzo de 2026 Esta limitación afecta la estandarización documental y la presentación formal de documentos administrativos, contractuales y legales, donde el uso de fechas largas es un requisito frecuente. Requerimiento funcional Se solicita que Athento permita: Configurar campos de tipo fecha para que admitan y muestren fechas en formato largo, incluyendo: Día en número Mes en texto Año en número Ejemplo: 15 de marzo de 2026 Definir este formato como: Formato predeterminado del sistema, o Formato configurable a nivel de: Metadato Plantilla documental Tipo documental Alcance esperado La funcionalidad debe aplicar a: Metadatos de tipo fecha Plantillas de documentos Visualización y generación de documentos (descarga, vista previa, impresión) Exportaciones o integraciones donde se refleje la fecha Consideraciones adicionales El formato largo debe respetar el idioma español, particularmente para el nombre del mes. Idealmente, el sistema debería permitir convivencia entre formatos corto y largo, según el contexto de uso. No debe afectar la lógica interna de almacenamiento de fechas ni los filtros por rango de fechas. Beneficio esperado Mejora en la presentación y formalidad de los documentos. Cumplimiento de estándares legales y administrativos. Reducción de ajustes manuales posteriores a la generación documental.

Monitorizar la propia cuenta desde la que se envía el correo para que, en el caso de que llegue algún mail rebotado por no haber podido ser enviado, quede registrado para poder ser explotado como que la notificación no ha llegado.

Teniendo en cuenta que en Colombia se manejan diferentes trámites los cuales cuentan con X cantidad de días para dar respuesta, estos días se manejan en días hábiles o laborales. Así mismo, en Colombia existen diferentes días feriados que pueden hacer que la fecha de vencimiento se tenga que ajustar. Agradecemos entonces, se tenga en cuenta que podamos contar con la configuración de un calendario Colombiano, en el cual podamos hacer los cálculos de las fechas de vencimiento teniendo en cuenta los días hábiles. Muchas gracias.

Que un usuario MultiTeam pueda ver sus pendientes de los Teams al iniciar sesión

Restricción de Visualización en Módulo de Colas Descripción del Problema Actualmente, la interfaz de gestión de colas carece de filtros de seguridad en la vista del usuario. Cuando un colaborador no tiene permisos asignados para ciertas colas, el sistema continúa mostrándolas en el dashboard con un icono de marcador de posición (referenciado como "muñeco con caja en la cabeza"). Esto genera ruido visual, afecta la experiencia de usuario (UX) y expone la estructura de colas a personal que no debería visualizar su existencia. Objetivo Modificar el comportamiento del componente de visualización de colas para que sea excluyente, permitiendo que los usuarios visualicen únicamente aquellas colas para las cuales tienen permisos de acceso explícitos. Requerimientos Funcionales RF1 - Filtrado Lógico de Seguridad: El sistema debe realizar una validación de permisos en el lado del servidor (backend) antes de renderizar la lista de colas en el cliente (frontend). RF2 - Eliminación de Placeholders: Se debe suprimir el icono/estado de "Sin acceso" (muñeco con caja) para colas no permitidas. Si el usuario no tiene permiso, la cola no debe existir en su interfaz. RF3 - Estado Vacío: En caso de que un usuario no tenga permisos en ninguna cola, el sistema debe mostrar un mensaje estándar de "No tiene colas asignadas" en lugar de una lista de elementos bloqueados. RF4 - Responsividad y Autoajuste de Grilla (Layout): Comportamiento dinámico la interfaz debe recalcular el diseño de la cuadrícula o lista automáticamente tras el filtrado de permisos. Eliminación de Espacios en Blanco: El sistema no debe reservar espacios vacíos ni mantener dimensiones fijas para colas ocultas. Si un usuario tiene acceso a 2 de 10 colas, el diseño debe reajustarse (centrarse o alinearse según el estándar de la UI) para ocupar el espacio de manera orgánica. Criterio de Aceptación: Al ocultar las colas sin permiso, los elementos visibles deben reubicarse de forma fluida para llenar los huecos, garantizando que el dashboard se vea completo y profesional independientemente del número de colas permitidas. Criterios de Aceptación Dado que soy un usuario con permisos solo para la "Cola A", cuando acceda al módulo de gestión, entonces solo debo ver la "Cola A" y ninguna otra referencia visual a las colas B, C o D. Dado que un administrador me revoca el permiso de una cola, cuando refresque la vista, entonces dicha cola debe desaparecer automáticamente de mi panel. El sistema no debe cargar en el DOM (código de la página) información de colas restringidas por motivos de seguridad y rendimiento. Detalles Técnicos Sugeridos Impacto en UI/UX: Mejora la limpieza visual y reduce la carga cognitiva del usuario. Seguridad: Implementar la validación desde la consulta a la base de datos (Query) para no traer registros innecesarios al frontend.permiso. Adjunto evidencia:

Habilitar fecha de caducidad para cuando se compartan carpetas o se envien documentos mediante enlace publico. De este modo, llegados a la fecha limite, el usuario dejará de tener acceso a la documentación compartida.

Cuando se configura la op op_intelligent_extract_metadata_v2, el parámetro "Metadata to be extracted" ofrece una lista de metadatos de TODOS los doctypes, sin indicar a qué doctype pertence cada campo, lo cual la vuelve muy poco práctica. Debería tener otro select para elegit el doctype. De paso, que la operación internamente pregunte al inicio si el doctype actual coincide con el indicado. Si no coincide, pues que no siga ejecutando la extracción. Digamos, que además de servir de filtro para la lista de metadatos, el doctype seleccionado funcione como condición de ejecución. Es lo natural, pues una op ejecuta al mismo tiempo sobre un solo doctype. No tiene sentido indicar metadatos de otros doctypes que no sea el actual sobre el que está ejecutando la op.

se solicita que ante un usuario de licencia o inactivo, cuando se lo arrobe en comentarios aparezca un cartel informativo o alguna forma de información (similar al fuera de oficina de los correos).

Se solicita la posibilidad de responder mensajes específicos en el sector de comentarios.