> 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.
- Nuevo feature
- Funcionalidad para la instalacion de hotfixes
- Nuevo feature implementado, se ha adicionado una nueva opcion al comando ./processmaker
Esta nueva opcion trabaja de la siguiente manera:
Caso 1 - ./processmaker hotfix-install MyHotfix.tar
Caso 2 - ./processmaker hotfix-install path_to_hotfix/MyHotfix.tar
Para el caso 1, el archivo tar debe estar fisicamente en la ruta:
path_to_processmaker/shared/hotfixes (si no existe el directorio "hotfixes", crearlo y darle todos los permisos)
Para el caso 2, el archivo debe existir en la ruta que se especifica
* Available from version ProcessMaker-2.5.1-testing.3
- Nuevo feature
- Funcionalidad para la instalacion de hotfixes
- Nuevo feature implementado, se ha adicionado una nueva opcion al comando ./processmaker
Esta nueva opcion trabaja de la siguiente manera:
Caso 1 - ./processmaker hotfix-install MyHotfix.tar
Caso 2 - ./processmaker hotfix-install path_to_hotfix/MyHotfix.tar
Para el caso 1, el archivo tar debe estar fisicamente en la ruta:
path_to_processmaker/shared/hotfixes (si no existe el directorio "hotfixes", crearlo y darle todos los permisos)
Para el caso 2, el archivo debe existir en la ruta que se especifica
* Available from version ProcessMaker-2.5.1-testing.3
- Nuevo feature
- Funcionalidad para la instalacion de parches
- Nuevo feature implementado, se ha adicionado una nueva opcion al comando ./processmaker
Esta nueva opcion trabaja de la siguiente manera:
Caso 1 - ./processmaker patch-install MyPatch.tar
Caso 2 - ./processmaker patch-install path_to_patch/MyPatch.tar
Para el caso 1, el archivo tar debe estar fisicamente en la ruta:
path_to_processmaker/shared/patchs (si no existe el directorio "patchs", crearlo y darle todos los permisos)
Para el caso 2, el archivo debe existir en la ruta que se especifica
* Available from version ProcessMaker-2.5.1-testing.3
- No se modificaba la estructura porque no se tenia seteado la variable ENVIRONMENT_SETTINGS.
- Se modifico la funcion upgradeCasesDirectoryStructure para que cree la variable si no existe.
- Se movio la funcion upgradeCasesDirectoryStructure para que sea independiente al realizar el upgrade.
- se creo la funcion update-structure-directories para ejecutar por consola teniendo como parametro el workspace.
- No se modificaba la estructura porque no se tenia seteado la variable ENVIRONMENT_SETTINGS.
- Se modifico la funcion upgradeCasesDirectoryStructure para que cree la variable si no existe.
- Se movio la funcion upgradeCasesDirectoryStructure para que sea independiente al realizar el upgrade.
- se creo la funcion update-structure-directories para ejecutar por consola teniendo como parametro el workspace.
- New feature
- Safe upgrade for JavaScript files
- Added new feature,
- This new feature is activated when you run one of the following commands:
$ ./processmaker upgrade
$ ./processmaker build-js
$ ./processmaker browser-cache-files-upgrade
- The new feature creates an attribute in the file "processmaker/workflow/engine/config/env.ini"
Example:
browser_cache_files_uid = "xxxxxxxxxxyyyyyyyyyyzzzzzzzzzzaa"
- After running the command, the browser should automatically cache the new files
* Available from version ProcessMaker-2.5
When restoring a workspace, there is an error message: 'Could not create the directory....' that truncates the restore. So a validation was added to create the folder that was not finding when doing the restore.
When restoring a workspace, there is an error message: 'Could not create the directory....' that truncates the restore. So a validation was added to create the folder that was not finding when doing the restore.
