Estandarización productos en PO UI (BackOffice)

Todas las leyendas o estatus utilizados en un Browse deben cumplir las siguientes orientaciones:

• Alineación a la izquierda de la tabla.
• Utilizar preferencialmente el formato “labels”.
• Evitar leyendas/estatus largos
  • Utilización de tooltip para detallar el estatus, si es necesario.
• Tamaño del label fijo, considerando el texto de mayor tamaño.

Las columnas de un browse, deben seguir el mismo formateo y nombre del Protheus.

• Títulos de campos utilice del diccionario SX3
• Ordenación, lista de campos de la SX3

Se definió que para la opción de filtro avanzado se debe utilizar el estándar del slide, según el siguiente modelo propuesto:

Para el comportamiento del filtro del Browse en PO UI, se definió que este ocurrirá automáticamente, es decir, cuando el usuario no digite en el campo de búsqueda por un intervalo superior a 3 segundos, se debe ejecutar una nueva búsqueda en el Back-End automáticamente, y se interrumpe si el usuario continua digitando, esperando así un nuevo intervalo sin digitación para que la búsqueda se realice nuevamente. Vea el siguiente ejemplo del comportamiento de búsqueda automática, sin la necesidad de informar el código completo ni activar el botón de búsqueda:

• Los botones de un browser que definen las actividades iniciales, se ubican a la izquierda seguido de un filtro con la opción de búsqueda avanzada.

• Un Browser que no tenga en sus definiciones iniciales botones, pero muestra la opción de Búsqueda y Búsqueda Avanzado, se alinean junto al título.
• Los botones ubicados en el footer (pie de página) se alinean a la derecha, y si hubieran muchas opciones utilice dropdown con acciones de la pantalla en un único lugar, para no perder el dinamismo de la pantalla. 

Referencias:

• https://po-ui.io/documentation/po-page-list
• https://po-ui.io/documentation/po-dropdown

Para rutinas donde haya una mayor necesidad de colores o variaciones de tonalidad, se podrán utilizar los colores estándar en el método GetColorChart de la clase CoreDash, según el detalle de la clase. Si es necesario un número mayor de colores, se deben alinear previamente e incluir los nuevos colores en la siguiente paleta de colores para utilizar todo el BackOffice.

A pesar de las particularidades de cada proyecto, reservamos algunos colores de leyenda que se deben utilizar, siempre y cuando sea necesario representar el estatus atribuido a esta. Los demás estatus que no se definieron en este estándar tendrán sus colores atribuidos por el producto de manera individual, considerando sus necesidades.

Los estatus definidos son:

• "Inhabilitado" o "Finalizado"  - Color rojo (color-10)
• "Habilitado" y "Pendiente"     - Color verde (color-07)

LGPD - Ofuscamiento de los campos

Se definió que el estándar de ofuscamiento de los campos para la LGPD será la presentación de una TAG con la palabra RESTRINGIDO.

Componente: po-tag, color-07, p-inverse=true

Ejemplo de uso:

Acceso por medio del Protheus:

El idioma que se presentará en las rutinas debe ser el mismo seleccionado en el acceso realizado en el SmartClient, según la siguiente imagen:

Acceso por el Mingle:

Al utilizar las rutinas en PO UI por medio del navegador, utilizando el Acceso del Mingle, también se debe presentar el idioma que se seleccionó en el Acceso, de  acuerdo con lo siguiente, aunque el idioma del navegador sea diferente:

OBS: El idioma seleccionado previamente en la pantalla de Acceso del Mingle, debe estar de acuerdo con lo que está configurado en el navegador, si hubiera un idioma traducido equivalente, y si no hubiera traducción para el idioma del navegador, se debe utilizar el estándar Portugués, pero si se modifica manualmente se utilizará el idioma que seleccionó el usuario.

La presentación de campos numéricos y/o monetarios deben seguir el mismo estándar utilizado en aplicaciones del ERP Protheus, es decir, siguiendo las definiciones utilizadas en la configuración de los entornos respectivos por medio de la clave PICTFORMAT, cuando la misma esté configurada como ESTÁNDAR el formato de presentación debe ser ',' (coma) como separador de decimal y '.' (punto) como separador de millar, cuando esté configurado como AMERICAN el formato de presentación debe ser '.' (punto) como separador de decimal y ',' (coma) como separador de millar, aun cuando en el diccionario de datos del campo correspondiente, el picture (X3_PICTURE) esté definido como '@E'.

OBS: Para verificar el contenido de claves del AppServer dentro de las API, se puede utilizar la función GetSrvProfString.

• Al acceder a la aplicación, se debe utilizar la empresa y sucursal registrada como estándar en el TOTVS Mingle.
• La selección o cambio de sucursales debe ocurrir solo después de que el usuario Acceda (Entrar) a la aplicación.
• La opción de Cambio de Sucursales debe ser una opción del Toolbar y debe seguir el siguiente modelo:

Objetivo: Dejar registrado en esta página la documentación oficial y algunas sugerencias para implementar el pipeline-poui.

Documentación completa del equipo de DEVOPS sobre el pileline-poui

https://code.engpro.totvs.com.br/engpro-devops/pipeline-poui

Expedición del .app

• Expedición archivo .app: Expedición THF(.APP)
• Expedición del archivo .app por medio del Spool de compilación: Proceso de expedición de archivos THF(.App) por medio del Spool de compilación
  
  

Ejemplo de generación de una nueva versión estable en el gitea

Ubicado en su repositorio remoto, en la Branch en que se basará su nueva versión, ejecute los siguientes comandos (utilice el terminal git de su preferencia):

Accediendo al repositorio en el gitea, en la solapa Versiones, tendremos una nueva tag con el estatus de versión previa:

Antes de cambiar la versión al estatus de Estable, es importante verificar si todos los pasos del drone se ejecutaron con éxito:

Para cambiar el estatus de la versión a Estable, haga clic en Editar en el título de la versión:

En la pantalla que se presentará, desmarque la opción "Marcar como registro previo":

Después de este último paso, la versión quedará con el estatus de Estable y lista para compilarla en el D-1, si su webhook (consulte la documentación) ya está configurado:

El estándar para la documentación de las API utilizado es el OpenAPI v3.

Para agilizar la documentación tenemos la herramienta de la Ingeniería con interfaz gráfica en el enlace:  OpenAPI-GUI v3

Otra herramienta es la extensión OpenAPI del VSCode. En esta podemos escribir el archivo yml y visualizar utilizando el Swagger UI.

Definición...

Ejemplo:

Vea los siguientes enlaces de acceso a los documentos de las FAQ de Productos del BackOffice, desarrollados en el PO UI con el  público objetivo general, es decir, se destina a Desarrolladores, Soporte Técnico y también a Clientes:

FAQ - Dashboard BackOffice

FAQ - Portal Gestión de Ventas

FAQ - Seguimiento de Costos (OBS: Al final de la página)

Vea los siguientes enlaces de acceso a los documentos de una FAQ destinada al equipo de Soporte Técnico, para apoyo a la atención de tickets de clientes:

PO UI - Documento de apoyo al soporte

Definición...

Ejemplo: