Categoría: novedades

Las siguientes pruebas nos servirán para hacer una previa verificación del funcionamiento correcto de las Push Notifications.

Validación de configuración del servidor

• Hay que ubicarnos donde querramos hacer las pruebas, sea en local, dev, etc (si es local debemos asociar nuestro localhost a ngrok por ejemplo y así poder hacer pruebas).
• Una vez dentro, nos dirigimos al archivo de configuración de servidor, que normalmente se encuentra en la siguiente ruta.
  \Clients\Custom_Files\Integration\configuration\production\boldserver\WPServerConfig.ini
• Una vez dentro comprobamos que las URLs de FullWeb apuntan al servidor.

LOCAL:

DEV:

Validación de funcionamiento Firebase a App

• Acceder al messaging de la cuenta firebase haciendo login con la cuenta de soportegpsplan (https://console.firebase.google.com/project/boldapp-prueba2/messaging?hl=es)
• Hacemos click en Experimento nuevo -> Notificaciones.
• Ahora rellenamos los datos siendo conscientes de que depende lo que configuremos, podría llegarle a todos los usuarios que estén usando la versión que indiquemos
  (En este ejemplo usamos la versión TestFlight de IOS para tener una prueba encapsulada).

• En la opción de Variables, bastaría con darle a siguiente.
• En Objetivo elegimos el que queremos analizar, pero si no tenemos ninguno en concreto elegimos la opción «Usuarios que no experimentan fallas».
• Por último programamos nuestra prueba.

Validación desde Apple cloudKit

• Nos conectamos a anyDesk y abrimos un navegador (de preferencia Safari, ya que recuerda las credenciales)
• Nos dirigimos a la herramienta apple para enviar push notifications (https://icloud.developer.apple.com/dashboard/notifications/teams/VK6PRMTH9)
• Elegimos en qué app haremos la prueba, por ejemplo com.gps-plan.BOLD-APP y clickamos la opción send.
• Nombramos el título con algo que nos ayude a identificar la prueba fácilmente.
• Si estamos en local nos será fácil encontrar nuestro deviceToken, sólo bastará con ejecutar la app en xCode y este al iniciar la app nos lo mostrará:

El formulario se vería algo así:

• También podemos modificar el payload:

• Por último enviamos con el botón ubicado en la parte superior derecha:

• La respuesta sería lo siguiente:

Para activar esto hay que hacer lo siguiente:

1. Instalar la última versión del cliente Windows.
2. Copiar la última dll LZ4_32.dll en Prebuild.
3. Añadir en el WPServerCfg.ini en General: DisableLZ4=0.

Atención: La ejecución de lo explicado en este artículo puede generar efectos catastróficos en el servidor LDAP si no se sabe exactamente qué se está haciendo. Ve con sumo cuidado.

$csvPath = "ldap_import.csv"

$csvData = Import-Csv $csvPath

foreach ($entry in $csvData) {
    Set-ADUser -Identity $entry.sAMAccountName -Replace @{employeeID=$entry.DNI;employeeNumber=$entry.Matricula}
    Write-Host $entry.sAMAccountName " " $entry.DNI "  " $entry.Matricula
}

powershell -executionpolicy bypass -File .\ImportCSVData.ps1

Por motivos de seguridad, es necesario modificar las páginas de inicio por defecto de IIS y Tomcat, aplicando redirecciones hacia nuestras aplicaciones.

A continuación, se explica paso a paso el proceso

Aplicando una redirección en el IIS (página de inicio por defecto: gpsnode)

Lo primero que necesitarás saber es en qué ruta está instalado el gpsnode. En entornos de productivo, suele ser en /gpsnode mientras que en entornos de desarrollo, suele ser /gpsnode_dev. Una vez lo tengas claro, sólo debes hacer lo siguiente:

En el IIS, clica sobre el cliente y luego sobre «Redirección HTTP«

Se te abrirá un nuevo panel, en el que deberás activar todos los checkbox y poner la ruta de la instalación de gpsnode, en este ejemplo, pondremos /gpsnode

Si todo ha ido bien, al colocar en el navegador localhost, el nombre de la máquina o la URL base configurada con certificado, ya no debería salirte la página por defecto del IIS, sino la de gpsnode.

Aplicando una redirección en Tomcat (página de inicio por defecto: portal)

Para Tomcat, se recomienda utilizar el método sugerido en la guía de instalación del mismo, sin embargo, es posible que se quiera aplicar una redirección en lugar de simplemente mostrar error.

Desde el Gantt se puede modificar la jornada asignada a un trabajador. Para ello tan sólo se debe seleccionar el día que se quiera modificar e introducir la expresión correspondiente, según se expone a continuación:

Operaciones realizables desde el Gantt:

Para:

• Añadir tiempo al final de la jornada deberemos poner: «+X», donde X son las horas que se quieran añadir. Por ejemplo «+1»
• Sustraer tiempo al final de la jornada deberemos usar «-X», donde X son las horas que se quieran sustraer. Por ejemplo «-1»
• Retrasar el inicio de jornada (no se modifica el final de la misma, tan sólo se altera la hora de inicio) introduciremos «X+», donde X son las horas, por ejemplo «1+»
• Adelantar el inicio de jornada (sin afectar la hora de fin) usaremos «X-«, donde X son las horas. Por ejemplo «1-«
• Añadir un tramo horario con inicio y fin, por ejemplo un trabajador que tiene turno de mañanas y le queremos añadir unas horas por la tarde, usaremos «+X-Y», donde X es la hora de entrada e Y la hora de salida del nuevo tramo horario. Por ejemplo «+14-20» o «+15:30-19:45»
• Sustituir la jornada actual con la propuesta, añadiremos la definición de la nueva jornada con el formato X-Y, donde X es la hora de entrada e Y la hora de salida, por ejemplo «08:30-15:00»

Descripción

A continuación se describen como funciona el enroutamiento en la aplicación web, utilizando el router de vue, y como se consigue hacer persistir el estado de la aplicación cuando se realiza un refresco en el navegador(F5) con la clase PersistentStateController. Se explican las dos funcionalidades en el mismo documento ya que están relacionadas.

Enrutamiento

El componente que se encarga de decidir la URL en la que estamos en la SPA(Single Page Application) es el vue-router.

Se trata de una parte muy sencilla del código que realiza las siguientes funcionalidades: permitir o no acceder a una ruta, redirigir a otra ruta en función de una lógica, decidir el componente vue que se renderiza en la ruta y actualizar la ruta en el navegador(window.location.href).

La instanciación del router está en el fichero src/router/index.js. Básicamente, al instanciarse se le pasa un array con todas las rutas, donde cada ruta contiene la siguiente información:

• path: será la URL que aparecerá en el navegador.
• name: nombre de la ruta.
• component: componente vue que se renderiza al acceder a la ruta.
• beforeEnter: callback que se llama previamente al acceso a la ruta donde se puede hacer un control de los permisos de acceso y de las redirecciones a otra ruta. En este callback se llama a la función validateAccessRoute para controlar si la ruta está permitida. También se llama a la función validateAccesMainRoute para controlar si estamos en modo vista de empleado y no permitir acceder a otras rutas. Estas dos funciones se explican a continuación. Otra función que se suele utilizar aquí es changeLanguage que indicar en que lengua debemos renderizar la página. El callback beforeEnter permite llamar de forma concatenada a varias de estas funciones formándose una cadena de validación de ruta. Por ejemplo, al acceder al asistente en la ruta de empleados en la URL tendremos wizard/workers. Para comprobar esta ruta, primero se llamará a validateAccessRoute que mira si la ruta es accesible y luego se comprueba con validateAccessMainRoute si el usuario es empleado o no y tiene acceso a esa ruta. Esa decir, se hacen las dos comprobaciones.

La función validateAccessRoute

Permite controlar mediante TBoldActiosn si una ruta es accesible. En concreto las TBoldActions controlan el acceso a las partes del asistente y a los maestros. En caso de que la TBoldAction no permita el acceso a estas rutas se muestra un mensaje al usuario indicándoselo.

La función validateAccessMainRoute

En caso de que el usuario conectado sea de tipo Empleado sólo podrá acceder a la página que le muestra la ficha del empleado. Esta función se encarga de comprobar que no puede acceder a ninguna otra ruta. En caso de que lo intente será redirigido a la pantalla de Login.

La clase PersistentStateController

Esta clase sirve para que ante un refresco de la página del navegador el estado de la aplicación permanezca.

La idea principal es muy simple. Cada vez que se renderiza una página, con su componente vue, pueden pasar dos cosas: que sea una inicialización o que sea un refresco. En caso de inicialización tendremos el estado «reseteado», es decir, sin inicializar y a medida que se carga la página lo iremos completando hasta el final. Entonces es cuando guardaremos ese estado. En caso de refresco tendremos que recuperar el último estado guardado y «setearlo» de tal manera que nos aparezca la misma información previa al refresco en la página.

La información de estado se guarda en el localStorage. Hay dos funciones principales: validateState y setActualState. La función validateState se utiliza al principio de la carga de la página. La función setActualState graba el estado al final. validateState detecta si hay una inicialización o un refresco. En caso de inicialización no hace nada. En caso de refresco recupera el estado de la úlitma vez que setActualState lo grabo.

Diferencias entre el localStorage y el sessionStorage

La URL para acceder a la documentación de los Webservices es: URLBASE/docs/

El contendió será: