@alikon Besides my review suggestions following is missing:

1. The files of the old "plg_system_updatenotification" plugin have to be deleted in the source code, i.e. in Git/GitHub. This should be done with this PR here. For the lists of deleted files and folders in script.php I will care afterwards with a separate PR.
2. Currently, i.e. without this PR, when you make a new installation, the old "plg_system_updatenotification" plugin is enabled by default. Now with your PR there will not be a task after a new installation. That's a loss of functionality.
   To fix this, it needs to add an insert statement for the task in file "extensions.sql" after the create table #__scheduler_tasks.
   In order not to have all new installations in the world checking for updates at the same time of the day, we could use NOW() and datetime formatting to get the execution hour. I have already ideas and can prepare something in a PR for you.
   The question is if we shall insert the new task with asset_id zero, or if we shall also create an asset for it in base.sql. I think asset_id zero should work so an asset would be created when editing and saving the task parameters in backend.

Point 2 is only needed when the functionality is enabled on a new installation by default, like it is here and for the logrotation. For things which are not enabled by default on a new installation, like e.g. the privacy consents, we would not need that.

The question is if we shall insert the new task with asset_id zero, or if we shall also create an asset for it in base.sql. I think asset_id zero should work so an asset would be created when editing and saving the task parameters in backend.

probably cause i'm quite lazy ?

i'm would like to prefer to let a new installation based upon informed decision to the admin, we can discuss what can be the best "informed decision source"... but i wouldn't like to deal issues if possible ... on a nested table in a future sunny day ?️

@alikon I've allowed myself to update your branch to latest 5.0-dev and fix the conflict. Please pull the changes before you continue to work on your local clone.

@alikon Could you rename the update SQL scripts to something newer than "5.0.0-2023-07-12.sql" (= newest update SQL right now in the 5.0-dev branch), e.g. to "5.0.0-2023-07-26.sql"? Thanks in advance.

@alikon I've again allowed myself to update your branch to latest 5.0-dev and fix the conflict which was caused by the change of the "compat" plugin from system to behavior group. Please pull the changes before you continue to work on your local clone.

Here are some TODOs:

Remove postinstall message

• updatecachetime

Remove language files for new installations

• administrator/language/en-GB/plg_system_updatenotification.ini
• administrator/language/en-GB/plg_system_updatenotification.sys.ini

Remove mail template

• plg_system_updatenotification.mail

Add mail template (for new installations)

• plg_task_updatenotification.mail

@heelc29 Thanks for your reviews so far. Besides this PR here and the other one #41326 which you have reviewd, too, there are a few more by @alikon for migrating cyclic stuff to tasks. Could you review them, too? That would be really great because you see things which I was missing. The other PRs are #40519 , #40553 and #41064 .

Could you review them, too? That would be really great because you see things which I was missing. The other PRs are #40519 , #40553 and #41064 .

@richard67 Yes, if I can find the time ?

@alikon Can you please check alikon#25?

On update I get following php warning (I used prebuilt package from commit 09610f2; drone was not successfull for the latest commit)
Undefined array key "exec-day" in administrator/components/com_scheduler/src/Model/TaskModel.php on line 587

@alikon It needs again to rename the update SQL scripts, this time to something newer than "5.0.0-2023-08-21.sql". I suggest to use "5.0.0-2023-08-24.sql" for this PR here.

done

@alikon I've allowed myself to update the branch and apply some small code style fix. Now I think it needs better testing instructions. I suggest something as follows for this PR here, and will later make suggestions also for the other 4 PRs. Feel free to just copy it and paste into the descriptions of the PRs, or modify them as you want.

Testing Instructions

New installation

Make a new installation with this PR applied.

Check if there is an enabled task scheduler plugin "Task - Joomla! Update Notification".

Check if there is an enabled scheduled task "UpdateNotification" using that plugin.

Check that the new task shall run every 24 hours at the hour when the Joomla installation was made.

Update

On a Joomla 4.4-dev version or 4.4.0 alpha 4, note the endabled status and the configuration parameters of the "System - Joomla! Update Notification" plugin.

Now either disable that plugin or enable it and optionally change some of the configuration parameters to a value different to the default.

Update to the patched package or custom update URL created by Drone for this PR.

Check if the "System - Joomla! Update Notification" plugin has been uninstalled.

Check if there is a task scheduler plugin "Task - Joomla! Update Notification".

Check enabled status and configuration parameters of that plugin.

Check if there is a scheduled task "UpdateNotification" using that plugin. If so, check the configuration parameters, too.

Repeat the previous steps with different endabled status and configuration parameters of the "System - Joomla! Update Notification" plugin.

Actual result BEFORE applying this Pull Request

Notification on available Joomla updates is done with the "System - Joomla! Update Notification" plugin.

Expected result AFTER applying this Pull Request

New installation

The "Task - Joomla! Update Notification" plugin is enabled, and a scheduled task "UpdateNotification" is enabled to run every 24 hours at the hour of the Joomla installation.

Update

The "System - Joomla! Update Notification" plugin has been uninstalled by the update.

A new task scheduler plugin "Task - Joomla! Update Notification" has been created and is enabled.

If the old "System - Joomla! Update Notification" plugin was enabled before the update, a new scheduled task "UpdateNotification" has been created and is enabled.

The configuration parameters "Super User Emails" and "Email Language" of that task are set according to the old system plugin's parameters.

The interval hours is equal to the cache timeout parameter in the configuration option of the "Installer" component (com_installer).

If the old "System - Joomla! Update Notification" plugin was disabled before the update, there is no task for that plugin.

Check that the new task shall run every 24 hours at the hour when the Joomla installation was made.

I'm not sure if the task will be executed...

Check that the new task shall run every 24 hours at the hour when the Joomla installation was made.

I'm not sure if the task will be executed...

@heelc29 Is there something wrong or questionable in the code? Or are you not sure how to test

Is there something wrong or questionable in the code? Or are you not sure how to test

@richard67 Both - I've changed the exec-time of cron_rules in the database since I thought this is the only place with a timestamp for a new installation (and I can't wait 24 hours). But next_execution probably has to be set, but I haven't investigated this further.

@heelc29 The PR is ready for testing. Code style error is not related to the PR but to the current 5.0-dev branch. Could you test again? Testing instructions can be found in the description of this PR. Thanks in advance.

I have tested this item ✅ successfully on c3ff33a

Done all the tests - new install and update - on MySQL 8 and PostgreSQL 14.

thank you all for your help