- Pmtables: Problema al importar la data de tipo Autoincrementable
- Problema resuelto, el problema que se tenia era por los archivos que crea propel especificamente los archivos Peer,
al momento de hacer la insercióe los campos se eliminaba la columna donde se tenia los Primary Key ocasionando que
se cree nuevamente. Se valida la importacion de los pmTables cuando son de tipo Autoincrementable logrando a que
cuando se importe un pmTable mantenga los íices que se tenia al momento de exportarlos.
- When creating a dynaform with the character "&", the field handlers not working.
- Problema resuelto, el problema que se teníera lo siguiente cuando se utiliza el "&" en el tílo de un dynaform,
cuando se enviaba los datos via GET, el "&" lo interpretaba como un separador de variables y esto ocasionaba la
division de los datos que se enviaba. Se valida los datos enviados via GET codificáolos y al recibir estos datos
se los decodifica.
- Al editar el nombre de un proceso este permite ingresar el
nombre de uno ya existente
- El problema no esta al editar el proceso (esto cuando se ingresa
a "Edit process"), sino cuando el ProcessMap hace el "auto-save",
ahi si guarda el titulo del proceso
- Se ha agregado validacion cuando se actualizen los datos mediante
el "auto-save" (esto se aplica solo para los datos del proceso)
- En el lado Frontend se esta enviando los datos del proceso
(title, description) de manera continua con el "auto-save"
para su actualizacion, pero como ya existe la validacion, ahora
sale un ERROR. Esto debera ser revisado en el lado Frontend
- Pmtables: Problema al importar la data de tipo Autoincrementable
- Problema resuelto, el problema que se tenia era por los archivos que crea propel especificamente los archivos Peer,
al momento de hacer la insercióe los campos se eliminaba la columna donde se tenia los Primary Key ocasionando que
se cree nuevamente. Se valida la importacion de los pmTables cuando son de tipo Autoincrementable logrando a que
cuando se importe un pmTable mantenga los íices que se tenia al momento de exportarlos.
Problem:
Case 1: The same user 'A', creates and imports the process, using the option: "Update the current process...".
Result: The user that created the process, user A in the example, is allways the User Owner of the process.
Case 2: User 'A' creates the process, and user 'B' imports the process, using the option: "Update the current process...".
Result: The user that created the process, user A in the example, is allways the User Owner of the process.
Case 3: User 'A' creates the process, then this user 'A' is deleted, and user 'B' imports the process, using the option: "Update the current process...".
Result: The User Owner is showed empty.
Razon: When the user 'A' (the one that created the process) is deleted, the delete is only logical not physical in the db, and it is updated with the Status 'CLOSED' and the username of this user is changed to an empty string " ". So, when the process is updated the username is copy like it is in the db, and copy into the User Owner field, showing the empty string " ".
Solution:
A validation was added asking if the user exist, if this dosen't the User Owner is changed to the current user logged, and the same if the user exist but his status is CLOSED.
- PHPUnit for processmaker/workflow/engine/src/ProcessMaker/BusinessModel/Role.php
- PHPUnit for processmaker/workflow/engine/src/ProcessMaker/BusinessModel/Role/Permission.php
- PHPUnit for processmaker/workflow/engine/src/ProcessMaker/BusinessModel/Role/User.php
- When creating a dynaform with the character "&", the field handlers not working.
- Problema resuelto, el problema que se teníera lo siguiente cuando se utiliza el "&" en el tílo de un dynaform,
cuando se enviaba los datos via GET, el "&" lo interpretaba como un separador de variables y esto ocasionaba la
division de los datos que se enviaba. Se valida los datos enviados via GET codificáolos y al recibir estos datos
se los decodifica
The validation for the not required parameter "unpauseDate" was wrong. When this parameter was empty the validation was taking this like this has a date, so it was trying to check the date format, and this was giving an error.
The validation was changed to only let strings of 10 or more characters go into the next validation where the format of the date is checked.
- Se han implementado los siguientes Endpoints:
GET /api/1.0/{workspace}/role/{rol_uid}/permissions?filter={filter}&start={start}&limit={limit}
GET /api/1.0/{workspace}/role/{rol_uid}/available-permissions?filter={filter}&start={start}&limit={limit}
POST /api/1.0/{workspace}/role/{rol_uid}/permission
DELETE /api/1.0/{workspace}/role/{rol_uid}/permission/{per_uid}
