Issue:
0018661: No se pueden ordenar los campos en los las bandejas de ProcessMaker
Cause:
No se procesa el campo status
Solution:
- Al hacer un request con el campo status, este es validado y procesado
- El ordenamiento de columnas trabaja de manera correcta con el resto de los campos
PM-3713 "0018661: No se pueden ordenar los campos en los..." SOLVED
Issue:
0018661: No se pueden ordenar los campos en los las bandejas de ProcessMaker
Cause:
No se procesa el campo status
Solution:
- Al hacer un request con el campo status, este es validado y procesado
- El ordenamiento de columnas trabaja de manera correcta con el resto de los campos
Causa : Esta "," tal cual se indica aparece en esa poscion debido a que este obedece a una configuracion del ENVIRONMENT; ejemplo (@lastName, @firstName (@userName)), si esta seleccionada esta opcion deberia parecer una coma(,).
Solucion : Sin embargo puede que algunos de estos valores (Firstname o lastanme fuese vacio) en este caso se elimina la coma ",".
Causa : Esta "," tal cual se indica aparece en esa poscion debido a que este obedece a una configuracion del ENVIRONMENT; ejemplo (@lastName, @firstName (@userName)), si esta seleccionada esta opcion deberia parecer una coma(,).
Solucion : Sin embargo puede que algunos de estos valores (Firstname o lastanme fuese vacio) en este caso se elimina la coma ",".
$this->UserConfig = array(); /* Esto no existia en un principio y la logica de funcionamiento era el correcto*/
if (!isset($this->UserConfig)) {
$this->UserConfig = $this->getConfiguration("ENVIRONMENT_SETTINGS", "");
}
Sin enbargo al adicionar esa linea(Motivo Warnings de PHP), el if que se menciona tubo otra logica de trabajo es por eso que no se reflejaba los cambios realizados por el usuario.
SolucióLo que se realizo fue cambiar la instruccion isset por empty, de la siguiente manera.
if (empty($this->UserConfig)) {
$this->UserConfig = $this->getConfiguration("ENVIRONMENT_SETTINGS", "");
}
Con esto fue resuelto el error.
Nota.- A medida que se corrigio este error, tambien fue corregido los Notices PHP generados(Index Indefinido) y asi tener mas limpio el codigo.
Ejem.
Estado Inicial >> $config['format'] = $_POST["userFormat"];
Estado final >> if (isset($_POST["dateFormat"])) {
$config['dateFormat'] = $_POST["dateFormat"];
}
Causa. Esto fue debido a los siguientes motivos.
Inicialmente si funcionaba... se realizo un leve cambio parecida a la siguiente
instrucció
$this->UserConfig = array(); /* Esto no existia en un principio y la logica de funcionamiento era el correcto*/
if (!isset($this->UserConfig)) {
$this->UserConfig = $this->getConfiguration("ENVIRONMENT_SETTINGS", "");
}
Sin enbargo al adicionar esa linea(Motivo Warnings de PHP), el if que se menciona tubo otra logica de trabajo es por eso que no se reflejaba los cambios realizados por el usuario.
Solució Lo que se realizo fue cambiar la instruccion isset por empty, de la siguiente manera.
if (empty($this->UserConfig)) {
$this->UserConfig = $this->getConfiguration("ENVIRONMENT_SETTINGS", "");
}
Con esto fue resuelto el error.
Nota.- A medida que se corrigio este error, tambien fue corregido los Notices PHP generados(Index Indefinido) y asi tener mas limpio el codigo.
Ejem.
Estado Inicial >> $config['format'] = $_POST["userFormat"];
Estado final >> if (isset($_POST["dateFormat"])) {
$config['dateFormat'] = $_POST["dateFormat"];
}
- Cuando se borra un pmtable asociado a un cases list da un error por no encontrar los fields.
- cuando se borra la tabla se procede a poner en default la configuracion del cases list.
La configuracion por defecto de PM en ADMIN > Environment > Cases List > 'Number of Rows per Page' es de 25, pero mientras esta configuracion no es cambiada PM muestra en todos los listados solo 20 filas, lo cual no concuerda con lo seteado por defecto. Esto ocurre ya que la si la variable configurable en ADMIN > Environment no es tocada esta no existe asi que toma un valor por defecto que estaba seteado a 20, el cual se cambio a 25 como deberia estar.
- Date appears incorrect in the Generated Document List and Input Document List
- Bug has been reviewed and has not been able to replicate, it has been
tested on a local installation version 2.0.43 where I verify that the dates are correct
- We found hardcoded code, the same has been corrected
* Available from version ProcessMaker-2.5.2-testing.1
- User not in alfabetical order in Advance Search
- Sorting problem in the dropdown "User", in Advanced Search, this are
ordering by USERS.USR_LASTNAME field, which is incorrect
- Solved problem the ordering, has taken into account the settings
made in ADMIN>Settings>Environment>UserNameDisplayFormat
- The ordering is in ascending
- The "All Users" and "Current User" wildcards will always be the first
- We have defined a new method in the "class.configuration.php" class which
returns the field you should place your order to the users, this according
to the settings made ..in ADMIN>Settings>Environment>UserNameDisplayFormat
* Available from version ProcessMaker-2.5.1-testing.3
Description: ./files directory cannot be up 32000 directories max at ext3 configuration.
Solution : split the uid case directory at 3 level to create a tree structure. Apply this new structure to all PM. Set a upgrade procedure at time to use processmaker upgrade <workspace> commnand as su.
