Blog
search
attachments
weblink
advanced
Vista general
Herramientas de contenido
Se ha publicado una nueva actualización de los componentes relacionados con filtros y toolbar, incorporando mejoras visuales, nuevos eventos y ajustes orientados a mejorar la experiencia de usuario y la gestión de filtros activos.
Esta versión mejora la visibilidad y control de filtros activos, simplifica la experiencia de uso en escenarios con pocos chips y continúa la evolución de los componentes STIC hacia una arquitectura más consolidada y mantenible.
✨ Novedades
@sas/wc-stic-filters
Añadido el nuevo evento:
filters:chipChanged
@sas/wc-stic-toolbar-v2
@sas/wc-stic-toolbar-v2-data-heavy
Incorporado un nuevo badge visual que muestra el número de filtros aplicados en tiempo real.
🔄 Cambios
@sas/wc-stic-filters
Cuando
dataSourcecontiene 4 chips o menos, se mostrarán todos automáticamente.
⚠️ Componentes deprecados
@sas/wc-stic-filters-area
Componente marcado como deprecated.
Se recomienda migrar al nuevo componente:
<stic-filters>
@sas/wc-stic-filter-visibility
Componente marcado como deprecated.
📌 Resumen
Esta versión amplía las capacidades del cliente BDU permitiendo la modificación de usuarios vía SOAP, manteniendo la estabilidad del sistema y sin impacto en funcionalidades existentes.
📢 Release
Se ha publicado una nueva versión del componente bduApiClient, disponible tanto para JDK 1.7 como para JDK 21.
Ambas versiones incorporan una mejora que permite la modificación de usuarios en BDU mediante servicios SOAP.
📦 Versiones disponibles
JDK 1.7 →
bduApiClient:2.4.0JDK 21 →
bduApiClient:3.1.0
🔧 Novedades
Se han añadido nuevas capacidades de modificación de usuarios en BDU a través del conector SOA, utilizando el componente BduRepository (BduWriteableRepository):
updatePatientBasicData→ MODUSU01: Modificación de datos personalesupdatePatientAddress→ MODUSU02: Modificación de domicilio y datos de contactoupdatePatientDisplacement→ MODUSU03: Modificación de datos de desplazamientoupdatePatientControlData→ MODUSU04: Modificación de datos de control
✅ Validación
Las versiones han sido verificadas mediante pruebas, superando:
✔ Tests estáticos
✔ Tests de integración
Se ha publicado una nueva versión de la librería .NET EstructuraApiClient, concretamente la versión 1.13.7 en su variante .NET Standard.
🔧 Cambios incluidos
En esta versión se ha realizado la siguiente mejora:
- 🔄 Refactorización de entidades de acceso a datos
Se han adaptado las entidades para alinearlas con los sinónimos de base de datos creados, eliminando así la dependencia directa del esquema.
💡 Impacto
- Mayor desacoplamiento respecto a la estructura física de la BBDD
- Mejora en la mantenibilidad del código
- Preparación para futuros cambios estructurales en base de datos
✅ Recomendación
Se recomienda actualizar a esta versión para beneficiarse de las mejoras introducidas y mantener la compatibilidad con los últimos cambios en la base de datos.
Changelog versión 1.76.0
✨ Novedades
Esta versión introduce mejoras importantes centradas en la flexibilidad de filtrado y configuración:
🔧 Filtros personalizados
Ahora es posible definir filtros adaptados a necesidades específicas.🔄 Ordenación avanzada
Se permite crear filtros de ordenación mediante las propiedadesorderByyorderByChip.⚙️ Nuevas propiedades disponibles
cleanFilterssaveFiltersactionConfigsize
🧩 Nuevos tipos de chip en dataSource
chip-timechip-time-rangechip-number
🐛 Correcciones
Se han solucionado varios problemas para mejorar la estabilidad:
✔️ Visualización de chips
Corregido el error por el cual un chip con valor no se mostraba si no era visible o requerido.✔️ Carga de dataSource desde API
Solucionado un fallo que impedía cargar correctamente eldataSourcecuando provenía de una API.
📌 Resumen
Esta versión mejora significativamente la gestión de filtros y corrige problemas clave de visualización y carga de datos, aportando mayor robustez y flexibilidad al sistema.
Actualización normativa de automatización de pruebas funcionales
Nos complace informarles de la actualización normativa Automatización de pruebas funcionales en su versión PRE-RELEASE que regula la organización y entrega de pruebas automatizadas. Esta actualización sustituirá la versión anterior e introduce cambios relevantes que buscan mejorar la trazabilidad, la alineación con metodologías de desarrollo y la coherencia con la normativa de entregas.
A continuación, destacamos los cambios más relevantes que introduce.
- Directriz 3 y Directriz 12 actualizadas .Se incorpora y actualiza la información relativa a la carpeta Script de datos, alineandola con la estructura del repositorio definida en la normativa de entregas.
- Directriz 13: Entrega de los .features Se redefine el enfoque de entrega de los ficheros
.features, haciéndolo aplicable tanto a proyectos ágiles como a proyectos en cascada, lo que aporta mayor flexibilidad metodológica. - Nueva Directriz 15: Trazabilidad y etiquetado de pruebas Se añade una directriz específica para garantizar la trazabilidad de las pruebas, reforzando la transparencia y el control en la ejecución.
- Eliminación de la antigua Directriz 13: Reporte Se suprime la directriz relativa al informe de resultados de las pruebas automatizadas, ya que esta información queda recogida dentro de los modelos de desarrollo (cascada/ágil) y en la documentación requerida en cada caso.
Las Implicaciones para los equipos de desarrollo y QA
Los equipos que se inician en la automatización de pruebas funcionales, deberán adaptar sus repositorios de pruebas y scripts de datos para cumplir con la nueva estructura de carpetas (“scripts”).
La entrega de los ficheros de pruebas automáticas (.feature) deberá seguir los criterios actualizados, tanto en proyectos ágiles como tradicionales.
Es imprescindible que cada prueba automatizada tenga su etiquetado de trazabilidad, según lo estipulado, para facilitar su seguimiento, filtrado y auditoría.
Ya no se requiere entregar el informe de resultados como directriz separada (“Directriz 13. Reporte”), pero sigue siendo clave que los resultados se documenten dentro del ciclo de entrega del proyecto.
Esta actualización normativa representa un paso adelante, ya que adapta el proceso a diferentes metodologías de trabajo, mejora la trazabilidad de las pruebas y simplifica la documentación, evitando duplicidades innecesarias. Es una oportunidad para que los equipos optimicen sus prácticas de automatización y garanticen mayor calidad y control.
Recomendamos consultar el documento completo de la normativa disponible en el espacio normativo de Confluence PRE-RELEASE: Automatización de pruebas funcionales y pueden contactar con la Oficina de Calidad <oficinadecalidad.sspa@juntadeandalucia.es>para consultar cualquier duda o aclaración que necesiten sobre la misma.
La versión 1.74.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.
Versión Actual Versión: 1.74.0Fecha Publicación: | Próxima Release Versión: 1.75.0Fecha Prevista de Publicación: TBA |
Podréis consultarlos desde el Storybook del SAS.
Otros recursos
Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.
Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible
Se ha liberado la versión 1.74.0.
Esta versión incluye principalmente el empty state, un nuevo componente para mostrar la ausencia del dato.
A continuación, se muestra un resumen de los cambios más importantes.
Nuevos componentes
Añadido wc-stic-empty-state
El empty state es un componente que se utiliza cuando no hay información disponible para mostrar en un componente o sección de la aplicación.
Debe implementarse siempre que la ausencia de datos pueda generar confusión o necesidad de orientación. Su propósito es informar sobre la situación actual y, cuando proceda, ofrecer al usuario los siguientes pasos.
Se puede ver un ejemplo de uno de nuestros empty states en esta imagen:
A su vez, el empty state tiene distintos tipos de especializaciones, dependiendo de si este se muestra por un error ocurrido, por mantenimiento porque no hay datos o porque el dato todavía no ha cargado. La lista completa de empty states disponibles es:
<stic-empty-state-technical-error><stic-empty-state-no-content><stic-empty-state-forbidden><stic-empty-state-suggest><stic-empty-state-welcome><stic-empty-state-no-results><stic-empty-state-job-done><stic-empty-state-loading-error><stic-empty-state-backend-error><stic-empty-state-update-in-progress><stic-empty-state-required-config><stic-empty-state-functional-error><stic-empty-state-fast-loading><stic-empty-state-embedded><stic-empty-state-medium-load><stic-empty-state-slow-load>
También contamos con especializaciones de carga, como por ejemplo el stic-empty-state-fast-loading que muestra también un loader para enseñar el progreso de la carga:
Finalmente contamos con un tipo embebido cuyo espacio es más reducido para integrarlo dentro de componentes ya disponibles:
Añadido wc-stic-illustration
También se ha añadido un componente que puede comunicar una idea por sí solo o reforzar el mensaje textual en otros componentes. Además, este componente contribuye a mantener la coherencia en todo nuestro producto, fortaleciendo así la identidad de nuestra marca. Este componente es usado dentro del mismo empty state para enseñar ilustraciones que acompañan a los mensajes de error. A continuación se pueden ver algunas de nuestras ilustraciones disponibles en este componente:
Cambios en componentes
Cambios en wc-stic-table
Se ha adaptado el componente tabla para que use el empty state con celdas vacías y cuando no hay datos. Por ejemplo puede verse esta tabla que tiene algunos campos sin datos usando el empty state embebido:
A parte de estos cambios se han solucionado errores y mejorado funcionalidades menores, puede ver el registro completo de cambios accediendo a este sitio.
- Impreso por Atlassian Confluence 8.7.2