Pull Request for Issue # .

Summary of Changes

This PR fixes all datetime columns of the com_workflow component's database tables so there will not be any Invalid value '0000-00-00 00:00:00' for datetime error anymore on MySQL 5.7 or later when strict mode is enabled.

In opposite to PR #26372 , this PR here does not depend on PR #26295 , because this one here does not have anything to change in table #__ucm_content.

Following is done for following tables:

• Table #__workflows: The 2 not nullable columns created and modified will be handled like the same columns of the #__banners table in PR #26372 , i.e. they will get no default value. The default value is only used when inserting new records without specifying values for that particular column. Not having a default will enforce to insert new records with values for these columns being provided and throw an SQL error if some of these values is not specified, i.e. such errors will not be hidden anymore.
• Tables #__workflows, #__workflow_stages and #__workflow_transitions: The checked_out_time columns added to these table with PR #24059 are made nullable.

Because com_wokflow and its table have been added in 4.0, there is no update for any old records in any sql update script, and because we are not in Beta phase yet and so don't have to support updates from 4.0-Alpha-x to 4.0-Alpha-y or between nightly builds, we don't need such update statements.

Therefore it is possible just to change the sql update scripts 4.0.0-2018-06-03.sql which add the new table, what this PR does.

PHP code is changed so that the tables #__workflows, #__workflow_stages and #__workflow_transitions support null values.

Finally, this PR fixes a bug in the update sql script 4.0.0-2018-05-15.sql for postgresql, where columns checked_out_time and checked_out missing in the columns list for the insert statements for tables #__workflow_stages and #__workflow_transitions, but the values where in the statement's values list, which would result in an SQL error. The MySQL update sql script was ok regarding this issue.

Testing Instructions

New Installation

1. Apply the patch on a clean 4.0-dev branch using git or merging manually, or apply it on an installation of current 4.0-dev using patchtester.
2. If used patchtester on an existing installation in step 1, delete file configuration.php and delete all Joomla database tables in PhpMyAdmin or PhpPgAdmin (depending on your database type).
3. Do a new installation, login to backend, confirm the statistics dialog, go to global config and set error reporting to maximum or development in server settings.
4. Play around with workflows.
5. After any action, check in your database the relevant datetime/timestamp without timezone columns.

Update from 3.9.12 or staging

1. On a clean staging or 3.9.12, set error reporting to maximum or development in global config server section.
2. Update to 4.0.0-alpha12-dev nightly build plus this PR applied, using the "Upload & Update" tab of the Joomla Update component and the update zip package which you have downloaded from following link before: https://test5.richard-fath.de/Joomla_4.0.0-alpha12-dev-Development-Update_Package_2019-09-29_pr-26428.zip.
3. Watch the PHP error log and the log file of your database server during the update and after.
4. After update, play around with workflows
5. After each activity, check in your database the relevant datetime/timestamp without timezone columns.

Expected result

New Installation

Workflows work as well as without this PR. In a MySQL database there are no columns created or modified or checked_out_time having value '0000-00-00 00:00:00' in any of the tables #__workflows, #__workflow_stages and #__workflow_transitions, and there is no invalid default value anymore in MySQL >= 5.7 with strict mode on.

Update from 3.9.12 or staging

Update works, no errors in SQL or PHP about workflows. Rest see above for new installation.

Actual result

New Installation

Same as expected result, but the default value of these database column is invalid in MySQL >= 5.7 with strict mode on.

Update from 3.9.12 or staging

On MySQL same as expected, on PostgreSQL the update fails due to an SQL error when inserting the standard workflow (fixed here for new installs but not for the update: 81d0526), and later other errors related to workflows appear.

Documentation Changes Required

Maybe core developer docs and extension developer docs should be updated to encourage them not to use '0000-00-00 00:00:00' on MySQL anymore but use real NULL and not abuse '1970-01-01 00:00:00' on PostgreSQL as a speudo null date anymore and use real NULL values also there.