After updating magento to 2.4.4 and PHP to 8.1, the module is unusable. When trying to run from the admin panel of the action 'Dispatch' or using the command 'cronmanager: runjob', errors related to 'Deprecated functionality' appear.

This function is used several times in the module.

Environment

• Cron Job Manager Version 1.3.1
• Magento Version 2.4.4
• PHP Version 8.1

We are working in 2.4 for current and future projects and had to fork this repo to get this module in. Would love to see 2.4 support.

Describe the solution you'd like We have installed this locally on a 2.4 instance and don't see any issues. To add support, it's likely as simple as adding ~104.0.0 to the magento/framework requirement.

Describe alternatives you've considered Another option would be to open up the magento/framework requirement to *.

The timeline seems to slow down after hitting around 2k records in cron_schedule.

Wild guess: This is likely due to all the subscribers KO has for each binding

The goal of this Issue is to resolve problems with speed, and the amount of records we can handle in the timeline.

There should be a "max" number of records we support because there's an argument that you shouldn't have over a certain amount of records stored in cron_schedule. We'll definitely want to get a specific number for this

This is a follow up issue that was derived from issue #50

On magento 2.2.3 when clicking on Job Configuration or Select > edit I get the below error:

1 exception(s):
Exception #0 (Exception): Notice: Undefined index: name in [store_path]/vendor/ethanyehuda/magento2-cronjobmanager/Model/Schedule/Source/Schedule.php on line 32

Objective:

Rebrand existing "timeline" as visualizer and create a new Timeline based on something like Google charts api

The goal is to have a higher level perspective, over the visualizer, to gather a more granular view of cron jobs and where they are running.

When running bin/magento cronmanager:runjob no_such_job the following error is encountered:

Fatal error: Uncaught TypeError: Return value of EthanYehuda\CronjobManager\Model\ScheduleManagement::getGroupId() must be of the type string, null returned in /var/www/html/vendor/ethanyehuda/magento2-cronjobmanager/Model/ScheduleManagement.php:112

This is because the return type declaration for EthanYehuda\CronjobManager\Model\ScheduleManagement::getGroupId() does not permit null to be returned. This pull request replaces the invalid return with an exception which can be caught as needed.

Hi Ethen The module looks great!!

I get this issue: After installation, the static files are not being built correctly. Its building: pub/static/adminhtml/Magento/backend/en_US/EthanYehuda_CronjobManager/template.. and looking for: pub/static/adminhtml/Magento/backend/en_US/cronjobManager/template..

I get 404 on the html requests

Integration tests are currently failing because email content hasn't been decoded before it is compared to the expected output. This pull request solves that problem by adjusting the test.

This pull request also updates the branch names & PHP versions for Magento, and enables support for coveralls.io to help track unit test code coverage going forward.

Is your feature request related to a problem? Please describe. I want to see if a "running" cronjob is actually still running or has crashed

Describe the solution you'd like

• Show process id in grid
• Regularly check if processes are still running, show "last seen" timestamp in grid
• Add "kill" action

Code

Solves one requirement of https://github.com/Ethan3600/magento2-CronjobManager/issues/19 (Track PID of each cron job).

Also adds another feature, cleaning of jobs in cron_schedude table that has status "running", but the process is missing from the current system. There is a system config to disable this behavior in admin.

Seeing that this is a new feature added, I bumped the version to 1.6.0. I am fine with changing this if you wish.

Background

In our environment the cron process runs on a node that can be shut down and moved quite randomly, causing jobs to die mid-way through. This leaves a process in "running" status forever. It also stops any following jobs from running, except the scheduler. So that keeps adding all future jobs to the list, a few thousand per day. And that in turn puts enormous load on our DB server.

I hope you'll accept this pull request, even though we did not discuss it first, I simply needed our issue solved right away, and seeing that this was on the roadmap anyway it seemed wrong to put it in it's own module.

//Andre Klang PS: Thanks for your great module!

Using version 0.4.0 on Magento 2.1.10 in production mode i get this error:

[Tue May 01 15:11:14.275469 2018] [proxy_fcgi:error] [pid 3946] [client 87.213.39.106:16732] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: Argument 1 passed to EthanYehuda\\CronjobManager\\Controller\\Adminhtml\\Config\\Job\\MassScheduleNow::__construct() must be an instance of Magento\\Framework\\View\\Result\\PageFactory, instance of Magento\\Framework\\ObjectManager\\ObjectManager given, called in /var/www/vhosts/score/httpdocs/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php on line 93 and defined in /var/www/vhosts/score/httpdocs/vendor/ethanyehuda/magento2-cronjobmanager/Controller/Adminhtml/Config/job/MassScheduleNow.php:19\nStack trace:\n #0 /var/www/vhosts/score/httpdocs/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(93): EthanYehuda\\CronjobManager\\Controller\\Adminhtml\\Config\\Job\\MassScheduleNow->__construct(Object(Magento\\Framework\\ObjectManager\\ObjectManager))\n #1 /var/www/vhosts/score/httpdocs/vendor/magento/framework/ObjectManager/Factory/Compiled.php(88): Magento\\Framework\\ObjectManager\\Factory\\AbstractFactory->createObject('EthanYehuda\\\\Cro...', Array)\n #2 ...\n', referer: https://support-score.itnova.nl/sitemanager_53RfIfauG6CnZGS/cronjobmanager/config/index/key/dd48cb763ad077fb2bf32652df3d040976b30970adfea962d9290b31a0943746/

when i use the "Schedule now" option on from the Job configuration.

i've done some debugging and found out that renaming magento2-cronjobmanager/Controller/Adminhtml/Config/job to magento2-cronjobmanager/Controller/Adminhtml/Config/Job

solves the issue.

Describe the bug The status column in the listing grid doesn't work with magento 2.4.5.

[ERROR] Failed to load the "ui/grid/cells/html" template requested by "cronjobmanager_manage_grid.cronjobmanager_manage_grid.cronjobmanager_manage_columns.status".

To Reproduce

1. open grid in admin

Expected behavior status column should show rendered status html

Environment (please complete the following information):

• magento 2.4.5

Additional context Maybe I'm wrong but I don't see the need for the custom html.js EthanYehuda_CronjobManager/js/grid/columns/html

I changed <item name="component" xsi:type="string">EthanYehuda_CronjobManager/js/grid/columns/html</item> to <item name="bodyTmpl" xsi:type="string">ui/grid/cells/html</item>

and everything seems to work. But I'm not sure I'm considered all use cases.

From what I can tell, view/adminhtml/web/template/visualizer/toolbar.html was a duplicate of https://github.com/magento/magento2/blob/a31f4a35c018ad09654e5bd5871086b73fbd3d2d/app/code/Magento/Ui/view/base/web/templates/grid/toolbar.html with the addition of a columnsProvider. That file (in Magento_Ui) was changed in https://github.com/magento/magento2/commit/5955a29bb38ba6dbcdae51fc2a6fc4f76be8ac57 to properly close the HTML tags. The local copy of the same here hasn't been updated to include this, so the filters aren't working on Magento v2.4.4.

Actually we don't need this duplicate template, as we don't use the columnsProvider functionality, as far as I can tell.

From what I can tell, view/adminhtml/web/js/grid/columns/html.js was a duplicate of https://github.com/magento/magento2/blob/8b57fea479037f56c1d6e1b9ca76f0ebde95d2c9/app/code/Magento/Ui/view/base/web/js/grid/columns/column.js with a different default value for bodyTmpl. That file (in Magento_Ui) was changed in https://github.com/magento/magento2/commit/5955a29bb38ba6dbcdae51fc2a6fc4f76be8ac57 to include a new function. The local copy of the same here hasn't been updated to include this, so the column isn't showing up properly on Magento v2.4.4 (which also breaks the filters).

Actually we don't need this duplicate component, as we can set the value of bodyTmpl for the particular cell that needs it, and use the component that comes with Magento_Ui as-is, which will remain up-to-date with the associated templates as we're not overriding those.

Fixes #186

This is a feature suggestion. When jobs fail or have been detected as 'gone away', it would be helpful to be able to automatically retry these jobs. I've set the default to ignore 'failed' jobs, but to automatically retry 'missing' jobs.

I'm happy to discuss this / receive feedback about this feature.

For M1 we've been using https://github.com/AOEpeople/Aoe_Scheduler. Your extension has proven to be a wonderful successor for us to use in M2.

However, there is one requirement we haven't been able to solve yet.

When a method is run, we'd like to be able to check if it has been executed by a cron job. If yes, we'd like to get the admin user ID of the admin user that initially scheduled the job.

A little background: We've been using this logic for exporting large datasets. An admin user could schedule a custom export of a large dataset (e.g. all orders). This would add an entry into the cron schedule. As soon as the scheduled job has been executed, we'd then send an email to the admin user that initially requested the export.

Here is some pseudo-code showing how we were able to do this in M1:

// In an adminhtml controller, we schedule the job
Mage::getModel('aoe_scheduler/api')->schedule($jobCode);

// This is inside the method that was run by the job
$currentJob = Mage::registry('currently_running_schedule');
if($currentJob && $currentJob->getScheduledBy()) {
    $scheduledBy = $currentJob->getScheduledBy(); // This is the ID of the admin user that initially scheduled the job (see above)
    // Do something with the Admin User ID
}

Is there a proposed solution for this use case using your extension?

Thanks!