New option, disable by default (for now) where the cron listing for Users (and Admin Level -> All User Cron Jobs) is taken directly from the live: /usr/sbin/crontab -u username -l output. This will allow a cron manually by a User in ssh, to be visible in DA, even if the cron was not added through DA. So this is more for advanced Users who do a lot of cron changes with ssh, etc.. This will also be somewhat slower due to a crontab call, instead of a simple file read (only noticeable with Admin Level -> All User Cron Jobs) Internal default: direct_crons=0 =============== ENABLE to enable this feature, add: direct_crons=1 to your directadmin.conf, and restart DirectAdmin =============== IMPORTANT FUNCTIONALITY NOTES for backwards compatibility with editing and deleting crons, the ID method will still be used. However, IDs are assigned all all cron entries from 0 going up at the time of the crontab read. The /usr/local/directadmin/data/users/username/crontab.conf is still written and will still store data, but it's IDs listed cannot be considered synced with what DA is showing. For example, when you delete a cron, that entry is removed, possibly leaving an ID hole in the username/crontab.conf BUT when the User loads the updated page in DirectAdmin, the IDs will be based on the crontab -u username -l output, and not the crontab.conf file. The only thing you really need to consider with this is that if you are manually adding/removing crons with ssh, be sure to have a fresh User Level -> Cronjobs page load before deleting an old cron. If you load the Cronjobs page, then manually delete a cron from ssh, then delete a cron from the page, your IDs will be off, likely deleting crons you didn't intend to delete. The same catch could be argued for the old way of managing the IDs in the crontab.conf file.. for example you have the page loaded on one screen, then add a new cron and delete another on a different page or script, then delete a cron back in your stale load, you could be deleting a cron you didn't want to delete. So just use common sense and note that when using this, be sure you don't have a stale page/id list when deleting a cron from the GUI. This was done for backwards compatibility with the ID method of cron management.