I agree with all this except "Perhaps they can set limits on hooks". That's a programming thing to me, the code should set an appropriate limit and may make assumptions that tampering would break - code overrides would change the code if required. If certain hooks are problematic we should consider making them smarter via code improvements, not configuration.

The reason why I presented a limit on the email hook is because of many web hosts having limits on SMTP.

Ok, in which case I think probably that would be best served with config options.

"They will be able to view a list of CRON hooks in the system and the date/time each one last ran successfully."

This is now achieved through the error log, which is renamed to "Low-level logging". Individual logs, such as the CRON log, can be enabled through here.


"They can enable and disable specific hooks for debugging (disabling means cron_bridge will bypass that hook until it is enabled again)."

It would be cool to do this and I'd like to. That said, it is already pretty easy to move out CRON hooks from sources/hooks/systems/cron temporarily.
So TODO


"They can manually execute hooks from the screen"

That would be cool. Currently you can manually call specific CRON hooks with the 'limit_hook' URL parameter on the cron_bridge script. So this feature would just tie into that.
So TODO


"Have the ability to see errors if the executed hook failed with an error."

You can currently see that in the error log, but it would be nice to see it in the CRON log too.
So TODO (#3316)


"Perhaps they can set limits on hooks. For example, if cron_bridge runs every minute, but I only want my email hook to run every 5 minutes, I can set a limit on that hook. Addons with CRON hooks can also upon installation tell Composr whether each hook should run as Composr's default CRON interval, or to have its own default interval."

Since this post was made we have much better locking support. If a CRON hook takes too long, it's not really a problem because further CRON calls will just bail out. It won't trip over itself. The CRON log can be used to identify which hooks are taking too long, and then they can be isolated. So I think I still don't want to do a time limit option. That said, I will create an option to limit e-mail sending as discussed (v11).


"Maybe have the ability on the screen to set a "password" for cron_bridge. That way, the password needs to be passed to cron_bridge on execution for it to run. Prevents outsiders from overloading your server via. CRON flooding"

Aforementioned locking should prevent this being a real issue.