- Al utilizar solr y ver los listados de casos se podian observar casos repetidos.
- Se produjo un error al momento de actualizar un registro en solr ya que los datos que se tenian habian caracteres extraños los cuales rompian el xml.
- Se valido la formacion del XML añadiendo las etiquetas CDATA y eliminando caracteres extraños, en la class.AppSolr en la funcion buildSearchIndexDocumentPMOS2.
- en el caso especifico de la bbdd se descubrio que en los casos que se reproducia el problema la tareas con las que se ponian no existian debido a que era un proceso antiguo. se recomienda cambiar los uid hacia el nuevo uid de la tarea actual.
- Al utilizar solr y ver los listados de casos se podian observar casos repetidos.
- Se produjo un error al momento de actualizar un registro en solr ya que los datos que se tenian habian caracteres extraños los cuales rompian el xml.
- Se valido la formacion del XML añadiendo las etiquetas CDATA y eliminando caracteres extraños, en la class.AppSolr en la funcion buildSearchIndexDocumentPMOS2.
- en el caso especifico de la bbdd se descubrio que en los casos que se reproducia el problema la tareas con las que se ponian no existian debido a que era un proceso antiguo. se recomienda cambiar los uid hacia el nuevo uid de la tarea actual.
Cuando se crea un nuevo campo en una pmtable del tipo DATETIME, a la hora de editar la misma PMtable Este campo se muestra como TIMESTAMP. Esto ocurre por que la version de propel que usa PM, no genera clases con el campo DATETIME, esto al crear la PMTable, sino en cambio utiliza el tipo de dato TIMESTAMP.
Por lo tanto se agrego una validacion para que a la hora de recuperar los campos a editarse, se muestre el valor correcto, en este caso DATETIME.
Cuando se crea un nuevo campo en una pmtable del tipo DATETIME, a la hora de editar la misma PMtable Este campo se muestra como TIMESTAMP. Esto ocurre por que la version de propel que usa PM, no genera clases con el campo DATETIME, esto al crear la PMTable, sino en cambio utiliza el tipo de dato TIMESTAMP.
Por lo tanto se agrego una validacion para que a la hora de recuperar los campos a editarse, se muestre el valor correcto, en este caso DATETIME.
- Al realizar workspace-restore de un backup el tiempo que toma para restaurarlo es demasiado.
- Al estar realizando el restore se van ejecuantado los scripts de llenado de datos en la funcion "executeSQLScript" no se hacia un adecuado insert de los registros.
- se utiliza la funcion de mysql "START TRANSACTION" y "COMMIT" que son compatibles para MyISAM y InnoDB, y se van insertando los registros "Insert" por lotes.
- No se encontraba implementado.
- Se añadio funcionalidad para los casos pausados agregado el parametro $pausedtUser en las funciones buildSearchIndexDocumentPMOS2 para poder crear el xml y poder ir indexando todos los datos al servidor de solr.
- al sincronizar los datos se crea el campo "APP_PAUSED_USER_DEL_INDEX_" con el cual se podran realizar las busquedas.
- Cuando se recuperan los datos se actualizan los contadores de Paused tambien desde solr.
Se agregaron validaciones en los files: workflow/engine/classes/model/Process.php y workflow/engine/methods/processes/processesList.php para que se realize el ordenamiento ASC y DESC tomando en cuenta si se encuentra o no habilitado el uso de 'memcache' para listar de una forma mas veloz todos los procesos.
- Problemas al instalar el hotfix cuando se tiene instalado processmaker en otra carpeta diferente a "processmaker"
- Problema:
Cuando se instala ProcessMaker, el directorio de instalacion tiene por defecto el nombre de "processmaker", pero
este nombre puede ser cambiado, por ejemplo a "processmaker2"
Cuando se aplica el .tar hotfix en "processmaker2" los directiorios deberian ser reemplazados en "processmaker2";
esto no ocurre, si no que crea un directorio en la misma ruta con el nombre "processmaker" teniendo en el mismo directorio
lo siguiente:
- procemaker
- procemaker2
- Solucion:
Cuando se aplica el .tar hotfix por ejemplo en "processmaker2" los directorios que existe en el hotfix
se aplican en "processmaker2"
Se ha cambiado el PATH_OUTTRUNK, y se ha descartado el metodo extract(); estos son reemplazados de la siguiente manera:
$swTar = $tar->extractModify(PATH_TRUNK, "processmaker");
Se agregaron validaciones en los files: workflow/engine/classes/model/Process.php y workflow/engine/methods/processes/processesList.php para que se realize el ordenamiento ASC y DESC tomando en cuenta si se encuentra o no habilitado el uso de 'memcache' para listar de una forma mas veloz todos los procesos.
Se aniadio la nueva funcionalidad de busqueda en el display de los datos de los PMTables y Report Tables, en ADMIN > Settings > PM Tables > Data, el cual realiza las busquedas por todas las columnas del PM Table o Report Table.
Se corrigio el ordenamiento ASC y DESC.
Se aniadio la nueva funcionalidad de busqueda en el display de los datos de los PMTables y Report Tables, en ADMIN > Settings > PM Tables > Data, el cual realiza las busquedas por todas las columnas del PM Table o Report Table.
Se corrigio el ordenamiento ASC y DESC.
- El problema empieza cuando se quiere hacer un workspace-restore sobre windows no se pueden cambiar los permisos de los files, dando como consecuencia que no se restaure el backup o se hacia parcialmente.
- Se añadio en la class.wstools.php la funcion dirPerms la validacion para permitir cambiar permisos en windows.
- al ejecutar la consola se requiere que este en modo administrador para permitir a "icacls" ejecutarse normalmente.
Se aniadio la nueva funcionalidad de busqueda en el display de los datos de los PMTables y Report Tables, en ADMIN > Settings > PM Tables > Data, el cual realiza las busquedas por todas las columnas del PM Table o Report Table.
Se corrigio el ordenamiento ASC y DESC.
