[jezmathers]

I cannot add a new User. This problem seems to have started after upgrading from V2.5 to V 3.1.1 When I try to save a new profile I am getting an error: Undefined value for "USR_DUE_DATE", it is required

I do have a date selected in the "Expiration Date" (which is the only date field on the form)?

Also, I have noticed I can no longer edit the "Expiration Date" on an existing User (it is greyed out).

Help! Thanks!

[mishika]

Hello,

While upgrading ProcessMaker from 2.5 to 3.1.1, did you upgrade PHP and MySQL as well?
Which Operating System are you using?
Please check the system information and confirm the PHP and SQL version you are currently working on.

Best Regards
Mishika

[jezmathers]

I actually moved the databases from a Ubuntu 12 server (running PM v2.5.1) to a Ubuntu 14.0.5 Server (with PM v2.5.1), I then ran the upgrade to PM v3.1.1.

PHP Information is as follows:

PHP recommended version 5.6 or higher (7.0 not supported):
5.5.9-1ubuntu4.20
MySQL Support:
Client API version 5.5.52
cURL Version:
cURL 7.35.0
OpenSSL Version (*):
OpenSSL/1.0.1f
DOM/XML Support:
Enabled
GD Support:
2.1.1-dev
Multibyte Strings Support:
Enabled
Soap Support:
Enabled
Mcrypt Support:
Enabled
LDAP Support (*):
Enabled
Memory Limit >= 80M:
1024M

[amosbatto]

A couple people have reported that they needed to run the upgrade command twice to make the upgrade work. Try doing this:

Code: Select all

cd /opt/processmaker
php processmaker upgrade
php processmaker cacheview-repair
php processmaker browser-cache-files-upgrade
php processmaker migrate-cases-folders
php processmaker migrate-content
php processmaker database-generate-self-service-by-value

[jezmathers]

I have re-ran the upgrade scripts, but that has not made a difference?!

I think this issue is also related to the fact I can no longer (since the upgrade) edit an existing users expiration date (USR_DUE_DATE). As you can see on the attached image the date field is greyed-out. I recently had some users expire and as I could not edit their profile and I had to manually change USR_DUE_DATE in wf_workflow.USERS and rb_workflow.RBAC_USERS (using phpMyAdmin).

I have been using PM 3.1.3 for several months without any other issues? The only other noticeable problem/difference is the "System Information" link is missing in Admin, Settings?

I do have some new users to add, but obviously I am stuck right now!

[jezmathers]

I created a new workspace on the same sever (the new workspace has the unified/single database, my older workspace is still using the 3 database model), and do not have an issue with creating new users, or editing the expiration date for existing users.

[amosbatto]

jezmathers,
Please register a bug report about this at http://bugs.processmaker.com

The Enterprise version has an option to unify the 3 databases into 1, but the community version doesn't have it.

You can manually change the user's expiration date in the wf_{workspace}.USERS.USR_DUE_DATE field in the database after creating the users.

[jezmathers]

Thank you. As you suggest, I can manually change the wf_{workspace}.USERS.USR_DUE_DATE field in the database, to change expiration dates of existing users (I also have to change rb_{workspace}.RBAC_USERS.USR_DUE_DATE), however my main issue is I cannot add a new user!!

Is there any issue/risk, if I manually add a database record into wf_workflow.USERS and rb_workflow_RBAC_users for a new user, using the USR_UID of "00000000000000000000000000000002" (admin user is "00000000000000000000000000000001")? Is there any other tables I would need to update?

I will also register a bug report. Thank you for your help!

[amosbatto]

You can use '00000000000000000000000000000002' or any other ID which doesn't conflict with the current users. If you are adding new users, then you only need to insert them in the wf_{workspace}.USERS.USR_DUE_DATE and rb_{workspace}.RBAC_USERS tables. By the way, do you have turned on PHP error loggging?

Note: To enable PHP logging in Debian, I do this:
Edit: /etc/php5/apache2/php.ini:

Set the following:

Code: Select all

log_errors = On
error_log = /var/log/php-errors.log

Then restart Apache (or reboot) for the changes to go into effect.

Make the log file, and set it to be writable by the Apache user. In Debian:

Code: Select all

touch /var/log/php-errors.log
chown www-data:www-data /var/log/php-errors.log

In Red Hat/CentOS:

Code: Select all

touch /var/log/php-errors.log
chown apache:apache /var/log/php-errors.log

[jezmathers]

PHP log does not show any errors.

I also upgraded a "test" server that still had PM 2.5.1 on it, to PM 3.1.3 and was able to reproduce the issue.

I have logged this a bug...

http://bugs.processmaker.com/view.php?id=22645

[jezmathers]

The development team have not been able to help with the bug that I reported. However, I do seem to have found another option/work-around...

As I do not have this issue with new/unified databases/workspaces, it seems I have found a resolution to my issue by manually "unifying" my database. To do this I created a new server, installing the same version of ProcessMaker (v3.1.3) and then completing the setup to generate the default workspace "workflow" (as this is a new install it creates a unified database).

Next, I restored my "workflow.file" files from a ProcessMaker backup using the TAR command (I kept a backup of db.php, which I restored after to make sure processmaker had the correct passwords) and then reset file/folder permissions.

Next, I imported the backup of wf_workflow.sql from the Processmaker backup. I did not restore the rb_workflow or rp_workflow databases, but instead took the user data from rb_workflow.RBAC_USERS and inserted it into wf_workflow.RBAC.USERS (I did not need to insert the Admin user, as that already existing in the new DB). Next I took the data from rb_workflow.RBAC_USERS_ROLE and inserted it into wf_workflow.RBAC_USERS_ROLE.

It now appears I have a fully functional unified database! Now I can edit users, add new users (the Expiration Date is not greyed out) and I can now see and access "System" and "System information" from Settings!

Is there anything I may have overlooked here, or anything that may be compromised? Everything (in a test environment) seems to be working as expected!

[amosbatto]

I'm glad that you figured out a solution. I can't think of anything else that you need to do. If you create a new Report Table, are you given the option to use the same wf_<WORKSPACE> database or does it only allow you to use the rp_<WORKSPACE> database?

[jezmathers]

It gives me the "workflow" database and the new Report table is created successfully (I tried that for both classic and BPMN processes)!

All my other (existing) report tables, were already in wf_workflow.PMT_<table>

Looks like I am good to go!