By Private Profile 2eff4882 on 2021-07-21 22:14 in Summer 2021 CronJobs

Tasks Completed

  • Implement Part of the Plugin API: Before starting work on the SelectView, the first problem was how com_cronjobs should become aware of jobs offered by plugins. The solution was the Joomla! Event architecture. com_cronjobs now makes use of the OnCronOptionsList Event to allow plugins to advertise the jobs or routines they offer. It was also decided that plugins will be allowed to advertise multiple jobs. To this end, I implemented the CronOptions and CronOption classes, the former of which is currently used as the subject  argument to the options list event and takes care of processing and storing job data into instances of the latter.
  • Design a dummy Job-supporting plugin: To facilitate the testing and development of the plugin API, the testjob plugin was created (yes, due a rename). This plugin subscribes to the onCronOptionsList event described above as well as onCronRun event planned to be used when a job is successfully triggered (this event is due a rename to onRunJob). The plugin supports 2 jobs and passes the job unique identifiers (to be used by plugins to identify jobs internally) along with their language constant prefixes (for job title and description) to the Event's subject argument, a CronOptions instance.
  • Implement SelectView: A new view whch completes the job management workflow, SelectView follows the familiar design and functionality of the SelectView from com_modules, enabling the user to select a (cron) job type from a range of plugin advertised jobs. SelectView implements all the same functionality as the one for modules, and leads the user to the next stage in adding an entry (CronjobView)
  • Integrate CronjobView with SelectView: Although work on this has just started, CronjobView is now aware of SelectView. The MVC finally makes use of state variables to keep track of the user state and the job type is no longer modifiable once on the form view.
  • Bugfixes and more: Fixed a bug with asset tracking, where unneed #__assets entries were created on item creation and never again accessed - com_cronjobs itself and the permissions fields were referring to another entry which was only created on a change to defult permissions. This, as I discovered, was due to a missing _getAssetsName() overload in the Table class. Another minor bugfix was with the default tab for CronjobView which, wasn't hard to fix.
    The most time consuming issue turned out to be with the PostgreSQL DB scripts. As we moved both the language and the SQL files to core locations this week, the tests started failing due to the PostgreSQL scripts. As it turns out, Joomla!'s handling of PostgreSQL is probably not as one would expect. For one, any statements after the soundex() declaration fail to work. Then as it turns out, DO blocks aren't parsed as expected either. So any custom type declaration (we were using them for ENUMs) with exception handling is currently not possible. I've opened a ticket (#6) for the issue on the dev repo and welcome any help or leads from the community.

Screenshots



Links for the Repository and Relevant Pull Request(s)