Pull Request for Issue # .

Summary of Changes

This PR fixes all datetime columns of the com_csp database table #__csp 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.

Currently table #__csp only contains 2 datetime columns, created and modified. Those 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.

Because com_csp 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.

Finally I have not found anything where the created or modified times are used in PHP code, beside when storing the values using the standard table class, so there was no PHP code to be changed by this PR.

Testing Instructions

Can be tested by code review, but in addition you can do a test for new installation as follows:

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. Go to "Content Security Policy" via the System dashboard, open the "Options" and set "Content Security Policy" to "enabled" using the switcher, set mode to "Detect" then save the options.
5. Navigate around in frontend, then check in backend in "Content Security Policy" if some recorded reports exist.
6. Play around with the list, sort, filter, search, publish, unpublish, trash, ... and check that everything works as well as without this PR.

Expected result

"Content Security Policy" works as well as without this PR. In a MySQL database there are no columns created or modified having value '0000-00-00 00:00:00' in table #__csp, and there is no invalid default value anymore in MySQL >= 5.7 with strict mode on.

Actual result

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

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.