[4.0] [com_actionlogs] Fix default value for not nullable datetime column

[richard67]

Pull Request for Issue # .

Summary of Changes

This PR fixes the one and only datetime column log_date of the com_actionlogs database table #__action_logs 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.

The column will be handled like the created column of the #__banners table in PR #26372 , i.e. it will have no default value anymore. This will enforce to insert new records with values for this column being provided and throw an SQL error if some of these values is not specified, i.e. such errors will not be hidden anymore. In the same way as for the created column of the #__banners table in PR #26372 , old data will not be updated. It can be assumed that action logs created by the core don't have value '0000-00-00 00:00:00' for the log_date column.

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.

Finally I have not found anything where the log_date is used in PHP code which requires to be changed for the above database changes.

Note on updating old 4.0 sql update scripts

Since 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 can change the existing 4.0 update scripts (but of course not pre-4.0 scripts). Later when in beta this will not be allowed anymore because we have to support updating from Beta-x to Beta-y (with y > x of course), so now is a good time to fix them.

Furthermore it makes sense to keep the schema updates for the datetime columns of each table together in one script, because on MySQL it might be necessary to combine all changes for a particula table into 1 single ALTER TABLE statement in order to run properly in strict mode (i.e. strict tables enabled). Currently the db checker/fixer can't understand such statements, but it might be necessary to teach that tool soon to do that.

That's why this PR updates the existing sql update script and doesn't create a new one.

Testing Instructions

Testers please report back the database kind (MySQL or PostgreSQL) on which you have tested.

If you have both MySQL and PostgreSQL, please test on both if possible.

Test 1: 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. Perform actions in backend which are logged in the actions logs.
5. Check the log_date column in the #__action_logs table in your database.

Result: See section "Expected result" below.

Test 2: Update sql script

1. Install a clean clean 4.0-dev, login to backend, confirm the statistics dialog, go to global config and set error reporting to maximum or development in server settings.
2. Apply the changes from this PR e.g. manually or with patch tester.
3. Open PhpMyAdmin or PhpPgAdmin (depending on your database type), select your database and then go to the SQL command input.
4. On MySQL copy the first line of file installation/sql/mysql/joomla.sql into the SQL command window but don't execute the commands yet:

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";

This switches off strict mode to the SQL will run on MySQL 5.7 or later.

5. Copy the content of file administrator/components/com_admin/sql/updates/mysql/4.0.0-2019-09-24.sql or administrator/components/com_admin/sql/updates/postgresql/4.0.0-2019-09-24.sql (depending on your database type) into the SQL command window, in case of MySQL below the previously pasted commands, but don't execute the commands yet.
6. Replace #__ by your database prefix in the SQL statements pasted before in the SQL input window.
7. Put the cursor to the beginning of the 1st SQL statement in the SQL input window and now execute all SQL commands.
8. Perform actions in backend which are logged in the actions logs.
9. Check the log_date column in the #__action_logs table in your database.

Result: See section "Expected result" below.

Expected result

Action logs work as well as before. In database there are no columns of type datetime having value '0000-00-00 00:00:00' in a MySQL database, and there is no invalid default value anymore in MySQL >= 5.7 with strict mode on in that kind of database.

Actual result

Action work. In a MySQL database there might be columns of type datetime having value '0000-00-00 00:00:00', and the default value of these database columns 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.

[richard67]

Ready for review and test.
@wilsonge Please review.

[wilsonge]

Thanks!

[richard67]

Thanks, too 😄