si no se tiene configurado las opciones de email, en consola sale un mensaje de error al ejecutar el cron.
al no ser un bug, lo que se hizo fue agregar un nivel mas de mensaje que es WARNING que se muestra siempre y cuando no exista una coniguracion de email registrada en la base de datos.
si no se tiene configurado las opciones de email, en consola sale un mensaje de error al ejecutar el cron.
al no ser un bug, lo que se hizo fue agregar un nivel mas de mensaje que es WARNING que se muestra siempre y cuando no exista una coniguracion de email registrada en la base de datos.
si no se tiene configurado las opciones de email, en consola sale un mensaje de error al ejecutar el cron.
al no ser un bug, lo que se hizo fue agregar un nivel mas de mensaje que es WARNING que se muestra siempre y cuando no exista una coniguracion de email registrada en la base de datos.
si no se tiene configurado las opciones de email, en consola sale un mensaje de error al ejecutar el cron.
al no ser un bug, lo que se hizo fue agregar un nivel mas de mensaje que es WARNING que se muestra siempre y cuando no exista una coniguracion de email registrada en la base de datos.
> ProcessMaker-MA "Email Server (endpoints)"
- Se han implementado los siguientes Endpoints:
GET /api/1.0/{workspace}/email/paged?filter={filter}&start={start}&limit={limit}
GET /api/1.0/{workspace}/emails?filter={filter}&start={start}&limit={limit}
GET /api/1.0/{workspace}/email/{mess_uid}
POST /api/1.0/{workspace}/email
POST /api/1.0/{workspace}/email/test-connection
PUT /api/1.0/{workspace}/email/{mess_uid}
DELETE /api/1.0/{workspace}/email/{mess_uid}
- Se esta creando un 1er registro en la tabla EMAIL_SERVER, esto al ejecutar el comando "./processmaker upgrade".
- El metodo "System::getEmailConfiguration()" recupera el EMAIL_SERVER por default, caso contrario trabajara como lo
hacia anteriormente.
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
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
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.
- PM-317 Analizar como, que y donde mover los files/code del enterprise.
- PM-318 Enterprise Traducible.
- PM-320 Hacer funcionar el administrador de plugins.
A dropdown was added in the SelfService configuration, this dropdown let you set if the trigger seted in the self service is gonna be executed ONE time or every time that cron is executed.
Some validations where added in the cron_single.php file to save the data in the new table 'APP_TIMEOUT_ACTION_EXECUTED' when the Execution is set in ONCE. If the app_UID is find in this table the trigger will not be executed, if is not find the trigger will be executed.
A dropdown was added in the SelfService configuration, this dropdown let you set if the trigger seted in the self service is gonna be executed ONE time or every time that cron is executed.
Some validations where added in the cron_single.php file to save the data in the new table 'APP_TIMEOUT_ACTION_EXECUTED' when the Execution is set in ONCE. If the app_UID is find in this table the trigger will not be executed, if is not find the trigger will be executed.
Issue:
El script cron.php puede ser ejecutado varias veces
Cause:
El archivo bandera "cron" trabaja bien en Windows y no asi en Linux
Solution:
- Se ha agregado nuevas validaciones para entornos Linux
Ejemplo: ps -fea | grep cron.php | grep -v grep
- Se ha mejorado el codigo
Se aumento 'date' para el registro del log en la clase Logger (class.logger.php) y se quito el date en los mensajes enviados a dicha clase.
Cuando el usuario falla 3 veces consecutivas el logeo, se crea si no existiese, el file shared/log/loginFailed.log y se agrega un nuevo registro con los siguientes datos:
2014-07-02 16:55:22 | Many failed authentication attempts for USER: admin | IP: 192.168.10.109 | WS: dmuz | Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Se aumento 'date' para el registro del log en la clase Logger (class.logger.php) y se quito el date en los mensajes enviados a dicha clase.
Cuando el usuario falla 3 veces consecutivas el logeo, se crea si no existiese, el file shared/log/loginFailed.log y se agrega un nuevo registro con los siguientes datos:
2014-07-02 16:55:22 | Many failed authentication attempts for USER: admin | IP: 192.168.10.109 | WS: dmuz | Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
