SOC 2021: Cronjobs - Week 3
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 theCronOptions
andCronOption
classes, the former of which is currently used as thesubject
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 theonCronOptionsList
event described above as well asonCronRun
event planned to be used when a job is successfully triggered (this event is due a rename toonRunJob
). 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, aCronOptions
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 thesoundex()
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)
- Repostory: Joomla-Projects/soc21_website-cronjob
- Pull Request of the Week: PR#5
- Parent Pull Request: PR#4