on scheduled jobs. the backend list displays 'last run time' in GMT. displ local time on form.

[skyrun]

when you click to edit a report, it correctly adjusts and accepts the local/joomla time which is what i would want. but it's confusing to show unadjusted/GMT on the backend joomla list so i would suggest to display the same adjusted time on the backend joomla scheduled task list as is displayed on the form as what i would assume would be a 'simple' fix and one that wouldn't mess too many people up since people don't generally think in terms of GMT.

for example, if i type/pick '2018-01-21 03:00:00' as last run on the form and save the scheduled item, the 'last run' date on the list shows '2018-01-21 10:00:00' (because i am on GMT-7/MT).
------------------
we have also noticed that when you schedule 2 jobs for the same time (at least with the same php script selected) , that only one runs. perhaps should make either both run (if possible) OR make users schedule jobs at different run times by checking for dupes/making the run time unique.

 

[cheesegrits]

Date display should be fixed here (plus updating lastrun when you run it by hand):

https://github.com/Fabrik/fabrik/commit/84599fd70629f150c5f21afe2fdf674e5708affd

Define "when you schedule 2 jobs for the same time". You mean just setting the same interval, or manually setting lastrun to the same date/time, and the same interval?

-- hugh

 

[skyrun]

same time = anything that would cause them to be run at the same time. most commonly, set to run 1x / day, and then set same last run time for 2 jobs so that they both are triggered at 6am. i just know we have had issues when that happens (with run gating turned on or off doesn't seem to matter) so we always set them at least 10 mins apart and they seem to work that way.

and sorry, but i actually prefer it to keep 'last run' as the time the schedule normally runs (6am every day for example). then i can run it manually (to test for example) without accidentally changing the normal report running time. so it was ok the way it was (not updating when manually run) if you can revert that (unless other people prefer it that way).

or ideally if you're looking for design ideas, 'last run' would be the last time it was successfully run and a 2nd field 'run time' is the time to run it normally because i can see a use for both.

 

[cheesegrits]

(unless other people prefer it that way)

Actually it's me that prefers it that way, I have a few sites where I really need to know when it was last run, not just when it was run through the system plugin. I've been meaning to add that to the backend manual run for a while, and happened to be in the code fixing the date stuff. But ... just to be nice, I've added an option that controls whether it reschedules on a manual run or not, which defaults to No, for backward compat.

https://github.com/Fabrik/fabrik/commit/03acd0764bbc63febf95ee9c17167f1750e5dce9

For this ...

we have also noticed that when you schedule 2 jobs for the same time (at least with the same php script selected) , that only one runs. perhaps should make either both run (if possible) OR make users schedule jobs at different run times by checking for dupes/making the run time unique.

... I couldn't replicate it, with two identical PHP cron plugins, till I realized that you are probably directly executing the code inside the included file, like ...

foreach ($data as $group) {
   foreach ($group as $row) {
      // do some cron junk
   }
}

Which won't run more than once, as we do a require_once() on the file, not a require(). What I do is bundle stuff up either in a simple function, or a class, inside the file I am including, then call that from the PHP box ...

So file might contain ...

class HughCronJunk
{
   public static function doCronJunk($data, $listModel)
   {
      foreach ($data as $group) {
         foreach ($group as $row) {
            //do some cron junk
         }
      }
   }
}

... then in the PHP code box (not the setup box) ...

HughCronJunk::doCronJunk($data, $listModel);

-- hugh