Issue:
Analisis de los resultados de escaneo de las funciones en ProcessMaker. Plugin/trigger code scanner.
Cause:
Nueva solicitud de funciones
Solution:
Se ha implementado esta nueva funcionalidad, que consta de lo siguiente:
- Escaneo de codigo al importar un plugin (no se aplica a plugins enterprise)
- Escaneo de codigo al habilitar un plugin (si el plugin ya se encuentra fisicamente en el directorio de los plugins)
- Escaneo de codigo al importar un proceso
- Escaneo de codigo al crear/modificar codigo de un trigger
- Escaneo de codigo al ejecutar un caso que tenga seteados triggers en sus steps (si el trigger tiene codigo
no deseado, no se ejecuta el trigger)
- Se ha agregado la opcion "check-plugin-disabled-code" al comando "./gulliver", el mismo muestra
informacion sobre los plugins con codigo no deseado.
Ej: $ ./gulliver check-plugin-disabled-code [enterprise-plugin|custom-plugin|all|<plugin-name>]
- Se ha agregado la opcion "check-workspace-disabled-code" al comando "./processmaker", el mismo muestra
informacion sobre los workspaces con codigo no deseado en sus triggers.
Ej: $ ./processmaker check-workspace-disabled-code <myWorkspace>
- Por defecto ProcessMaker no realiza el escaneo de codigo, si se desea escanear codigo no deseado, se
debera definir el atributo "enable_blacklist = 1" en el archivo "env.ini", este atributo no se aplica
a las nuevas opciones creadas para los comandos "./gulliver" y "./processmaker"
- Para una configuracion personalizada de codigo no deseado (lista negra), se pueden definir las mismas en
el archivo "path/to/processmaker/workflow/engine/config/blacklist.ini" (si no existe el
archivo se puede crear), o tambien en el atributo "disable_functions" esto en el archivo "php.ini"
Ejemplo de "blacklist.ini":
;Classes
;=======
DashletInterface
;Functions
;=========
eval
exec
;date
;echo
strlen
- Se tienen modos deseguridad que no permiten ejecutar shell_exec.
- ya no se valida por safe_mode pero si se valida que no este entre las funciones restringidas, ademas de probar que se puede ejecutar shell_exec.
PROBLEMA:
Cuando la BD tiene un nombre distinto al WS el unify no funciona bien, creando una nueva bd con el nombre del ws.
SOLUCION:
Se recupera el nombre correcto de la bd y ya no se usa el nombre del ws para hacer el unify, ademas se agrego una validacion en la funcion resetDBInfoCallback() que solo aplica cuando se esta corriendo el unify, para q solo se cambie los prefijos de la configuracion del archivo db.php y nada mas.
Issue:
El CasesList es lento cuando existen casos con tipo de asignacion "Self Service Value Based Assignment"
Cause:
Para todos los casos se esta verificando si su asignacion es de tipo "Self Service Value Based Assignment"
Solution:
- Se ha creado una nueva tabla "APP_ASSIGN_SELF_SERVICE_VALUE", en la misma se registraran los casos
con asignacion "Self Service Value Based Assignment"
- Se ha agregado la opcion "database-generate-self-service-by-value" al comando "./processmaker", para poder
generar los registros de la nueva tabla.
Ej: $ ./processmaker database-generate-self-service-by-value myWorkspace
- al realizar el backup de una version 2.0.45 no se reconocen las licencias activadas.
- Se añade una validacion para redirecionar el path de la licencia ACTIVA.
Los dos primeros errores reportados en el ticket no se pueden replicar.
1er Error. Notice: PHP Notice: Use of undefined constant PATH_PLUGIN - assumed 'PATH_PLUGIN'
Se cambio por la variable correcta que obtiene el path del archivo enterprise.php -> $pathFileEnterprise.
2do Error. Problema con los Indices y 2 tablas q se actualizaban constantemente (PM-81)
- Las 2 tablas q se actualizaban constantemente eran: ADDONS_STORE y LICENSE_MANAGER ya que estas tablas no tenian en el schema.xml en la definicion de su primary_key required="true", por lo tanto se tomaba como required="false" y al comparar con el schema de la BD actual habia una diferencia, la cual se intentaba actualizar.
- Los 15 Indices a aniadirse eran indices de tablas BPMN_XXX en cuales el schema.xml estaba l definido, ya que los indices solo contemplaban el nombre de la columna q se declaraba como indice y nunca se declaro el nombre del indice como tal:
<index>
<index-column name="PAR_UID"/>
</index>
Por lo tanto se comparaba un campo vacio "" nombre del indice segun el nuevo schema y el nombre dado en el schema de la BD, siendo diferentes creaba nuevamente un indice con nombre de la columna por defecto.
Deberia estar asi en el shema.xml:
<index name="BPMN_PARTICIPANT_I_1">
<index-column name="PAR_UID"/>
</index>
El metodo upgradeFilesManager estaba recuperando los workspaces y haciendo la actualizacion de los files correspondientes de los mismos, siendo q se llamaba a este metodo por cada workspace.
La llamada al metodo upgradeFilesManager y el metodo en si se movieron a la clase class.wsTools.php haciendo la llamada a la misma por cada workspace, para que realize la respectiva actualizacion de los files de cada workspace.
When you try to upgrade more than 160 ws in a single PM instalation a TO MANY CONNECTIONS ERROR happens, and this stop the ws upgrade.
When you make the upgrade of many ws, each ws opens a new connection to the DB, and this is closed only at the end of all ws upgrade, so this cause the TO MANY CONNECTIONS error.
To solve the problem I kill the connection to the DB at the end of each ws upgrade.
When you try to upgrade more than 160 ws in a single PM instalation a TO MANY CONNECTIONS ERROR happens, and this stop the ws upgrade.
When you make the upgrade of many ws, each ws opens a new connection to the DB, and this is closed only at the end of all ws upgrade, so this cause the TO MANY CONNECTIONS error.
To solve the problem I kill the connection to the DB at the end of each ws upgrade.
