Operational Dashboard - Cambios y Soluciones

Esta página cubre los cambios y correcciones proporcionados a Operational Dashboard para la versión 2025.1.0 de IPF

Nuevo

Encabezado de Seguridad de Transporte Estricto Enviado Con Cada HTTP Respuesta

  • El encabezado de Seguridad de Transporte Estricto está configurado para aplicarse a todas las solicitudes y todos los subdominios, asegurando que todo el tráfico se sirva de manera segura a través de HTTPS.

  • La directiva de precarga está habilitada, lo que permite que el dominio sea añadido a la lista de precarga HSTS para una mayor seguridad. (Nota: Este atributo no tiene efecto a menos que el dominio sea añadido con éxito a la lista de precarga.)

  • El atributo max-age es configurable a través del hsts-max-age ajuste.

El hsts-max-age El valor debe ser incrementado

  • Por defecto, max-age está configurado en 300 segundos (5 minutos). El mínimo recomendado es 31536000 segundos (1 año), pero se aconseja aumentar este valor de manera incremental durante el despliegue.

  • Un valor predeterminado más bajo proporciona un período de gracia para las pruebas. Una vez que un navegador aplica HSTS para un dominio, recuerda la política hasta que expire el max-age. Aumentar el max-age es sencillo, pero reducirlo puede ser un desafío debido a la aplicación por parte del navegador.

  • La mejor práctica es comenzar con un valor bajo, probar exhaustivamente y aumentar gradualmente hasta un valor seguro a largo plazo. Puede encontrar más información aquí:https://hstspreload.org/

Funcionalidad para cancelar pagos programados a futuro

  • Se ha añadido la funcionalidad para cancelar pagos programados en el futuro a la ODS Pantalla de resumen de pagos. Esto permite a los usuarios cancelar pagos que tienen un estado global en SCHEDULED o categorías PENDIENTES.

  • Para acceder a esta nueva función, usted debe tener el siguiente permiso: ROLE_PAYMENT_CANCEL

  • El botón de reparación solo estará habilitado si el estado global del pago se encuentra en una de las dos categorías mencionadas anteriormente. El botón de reparación no estará habilitado si el estado global del pago se encuentra en cualquier otra categoría o en el Recall y Bulk páginas de resumen.

  • Los cambios en la configuración del estado global y la introducción de categorías se han explicado en la sección Cambiado a continuación.

    NOTA: La funcionalidad de cancelación solo se ha añadido en el frontend, es necesario implementar una solución en el backend para que esto funcione, la cual estará disponible en un futuro cercano.

  • La duración de cuánto tiempo un JSON El token web, así como la cookie, es válido desde el momento del inicio de sesión y puede ser configurado a través de ipf.business-operations.auth.jwt.expiry.

  • El usuario puede proporcionar este valor en segundos, minutos, horas y días. El valor de la duración establecida debe estar entre 1 minuto y 7 días. Si este valor está mal configurado, la aplicación no se iniciará.

  • La configuración predeterminada para esta propiedad es de 1 hora.

Algoritmo de Firma Configurable para JSON Token Web

  • El algoritmo de firma puede ser configurado a través de la configuración ipf.business-operations.auth.jwt.signature-algorithm junto con las propiedades adicionales requeridas para que el algoritmo elegido funcione correctamente.

  • Los algoritmos soportados son HS512 y ES512.

  • ipf.business-operations.auth.jwt.secret debe ser definido cuando se elija HS512 como algoritmo de firma.

  • ipf.business-operations.auth.jwt.path-private-key y ipf.business-operations.auth.jwt.path-public-key deben ser definidos cuando se elija ES512 como algoritmo de firma.

Protocolo de Permisos Granulares introducido y aprovechado por la GUI HTM Módulo

  • El Protocolo de Permisos Granulares ha sido creado, el cual es utilizado por el HTM puntos finales en el Panel de control.

  • Los permisos basados en roles actuales siguen en uso para los puntos finales de los demás módulos de la interfaz gráfica de usuario.

  • ipf.authorisation.conf tiene que ser anulado con custom grupos, roles y HTM contextos específicos para aprovechar la autorización granular para usuarios seleccionados para el acceso a HTM tareas.

  • Configuración predeterminada incluida en ipf.authorisation.conf reutiliza roles heredados, como ROLE_HTM_VIEWER, ROLE_HTM_EXECUTE, etc., con ámbitos de permiso que replican respectivamente el ámbito de autorización tal como se utilizaban en el protocolo basado en roles.

  • El nuevo protocolo viene con su propia terminología y para configurar correctamente los ámbitos de autorización para HTM Módulo GUI, se recomienda estudiar la documentación publicada en detalle:Autorización Granular

Cambiado

La autenticación básica ahora está deshabilitada por defecto

  • La autenticación básica no debe ser utilizada en producción y está desactivada por defecto. Está destinada únicamente para fines de desarrollo y pruebas. Actívela con:

    • ipf.business-operations.auth.basic-auth.enabled = true

Cambios en la Configuración del Estado Global

  • La configuración del estado global ha sido cambiada de un arreglo de cadenas a un arreglo de objetos. Aquí hay un ejemplo de cómo debería verse ahora:

global-statuses = [
    {
        name: "Pending",
        category: "PENDING"
    },
    {
        name: "Accepted",
        category: "ACCEPTED"
    },
    {
        name: "Completed",
        category: "ACCEPTED"
    },
    {
        name: "Rejected",
        category: "REJECTED"
    },
    {
        name: "Manual Action Required",
        category: "MANUAL_ACTION_REQUIRED"
    },
    {
        name: "Scheduled",
        category: "SCHEDULED"
    },
    {
        name: "Cancelled",
        category: "CANCELLED"
    }
  ]

Este es un cambio importante. Si usted tiene un custom La configuración del estado global, debe actualizarla para que coincida con el nuevo formato. El valor del nombre debe establecerse como lo que desee que sea el estado global, y este es el valor que aparecerá en la interfaz de usuario. Cada estado debe ser asignado a una de 6 categorías que tenga el significado más cercano al nombre del estado global. Solo hay 6 categorías de estado disponibles, y no debe asignar una categoría que no exista en la siguiente lista: PENDIENTE, ACEPTADO, RECHAZADO, SE_REQUIERE_ACCION_MANUAL, SCHEDULED, CANCELADO. Puede haber más de un estado en cada categoría. Se han introducido categorías porque impulsan ciertos comportamientos de la pantalla en la interfaz de usuario; por lo tanto, la interfaz de usuario no funcionará como se espera si la categoría se deja nula.

Eliminación del Servicio de Usuario Activo

  • Tras los cambios de PAY-12897 y PAY-12894, se ha eliminado el servicio de usuario activo.

  • Cualquier referencia a este servicio debe ahora referirse a la tienda ngrx en su lugar como la única fuente de verdad, ya que ya no decodificamos el JWT localmente.

Por ejemplo, si usted utilizó el activeUserService para obtener el usuario que ha iniciado sesión:

this.loggedInUser = activeUserService.getActiveUserInfo();

Esto puede ser reemplazado por

 this.store.select(selectActiveUser).pipe(
    map((username: string) =>
        (this.loggedInUser = username)
    ));

Esto no se recomienda ya que no debemos ser mapping desde el selector

  • En cambio, debemos manejar el loggedInUser como esto

 this.loggedInUser$ = this.store.select(selectActiveUser);

Dónde loggedInUser$ ahora es un Observable<string | undefined>

  • Típicamente, usted no desea hacer referencia al usuario conectado fuera de un efecto a menos que sea con fines de visualización.

Traducciones personalizadas suministradas en la versión

  • Traducciones predeterminadas para el IPF Operational Dashboard se suministran en la construcción.

    • Cada módulo tiene su propio archivo de traducción con alcance, por ejemplo:`i18n/htm/en.json`

    • Además, ahora existe un archivo de traducción global para términos compartidos o reutilizados con frecuencia:`i18n/en.json`

    • En tiempo de ejecución, las traducciones globales se fusionan con las traducciones específicas. Todas las claves del archivo global son accesibles bajo el espacio de nombres específico. Si la misma clave existe tanto en el archivo específico como en el global, la traducción específica tiene prioridad.

  • Se pueden proporcionar traducciones personalizadas en el momento del lanzamiento al agregar un HOCON archivo en la siguiente ubicación:`config/bizops/i18n/{scope}/{lang}.conf`(eg.config/bizops/i18n/htm/en.conf)

    • Este archivo puede incluir todas o solo algunas de las traducciones definidas. No es obligatorio proporcionar ninguna custom traducciones - Si el archivo falta, la aplicación utilizará los valores predeterminados.

Para facilitar esta funcionalidad, todas las traducciones deben agruparse en las siguientes categorías:

  • navigationItem

  • título

  • encabezado

  • texto

  • columnHeader

  • rowHeader

  • formField

  • tooltip

  • tab

  • botón

  • advertencia

  • error

  • metadataField

Además, se deben seguir ciertas mejores prácticas. Por favor, consulte Directrices de Traducción para más detalles.

Cambios en el enrutamiento debido a cambios en las cookies

  • La cookie ahora está httpOnly lo que significa que ya no tenemos acceso a él en el FE

  • Deberá actualizar la configuración de los proveedores para su aplicación a fin de manejar los cambios realizados en el módulo.

*Este es un cambio importante*routerReducer debe ser proporcionado para el módulo de tienda y StoreRouterConnectingModule debe también ser proporcionado

Por ejemplo, debe cambiarse de esto:

 StoreModule.forRoot(
    {},
    {
        runtimeChecks: {
            strictStateImmutability: false,
            strictActionImmutability: false
            }
    }),

A esto:

 StoreModule.forRoot(
    {
        router: routerReducer
    },
    {
        runtimeChecks: {
            strictStateImmutability: false,
            strictActionImmutability: false
            }
    }),
    StoreRouterConnectingModule.forRoot()

También deberá actualizar su enrutamiento para la ruta raíz para que realmente estemos verificando que el usuario esté autenticado y tenga una Entidad de Procesamiento válida.

    {
        path: 'app',
        canActivate: [ProcessingEntityGuard],
        component: AppHomeComponent
    },