You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
%last_execution% : last execution date (format : Y-m-d H:i:s). Available for arguments and options
%log_file% : output file. Available for arguments and options
%last_return_code% : last return code. ONLY available for options (possible value -1 is not working for Argument)
I think it is cool to have these values.
For example, one command send emails 1 time per day to concerned users to inform something to have update.
So :
User 1 have an update of Day 1 -> send
User 1 doesn't have an update of Day 2 -> don't send
If Command doesn't have the last execution, we need to be set the interval on Command to search with a Query, and we need to be having the same frequency at cron_expression. But if we can have a parameter on the Command to know "start period" (last_execution) to use them in a Query, we are always sync. And not a problem to change frequency with cron_expression.
The text was updated successfully, but these errors were encountered:
Zul3s
added a commit
to Zul3s/CommandSchedulerBundle
that referenced
this issue
Jan 16, 2021
Hi,
What do you think about dynamic parameters :
I think it is cool to have these values.
For example, one command send emails 1 time per day to concerned users to inform something to have update.
So :
User 1 have an update of Day 1 -> send
User 1 doesn't have an update of Day 2 -> don't send
If Command doesn't have the last execution, we need to be set the interval on Command to search with a Query, and we need to be having the same frequency at cron_expression. But if we can have a parameter on the Command to know "start period" (last_execution) to use them in a Query, we are always sync. And not a problem to change frequency with cron_expression.
The text was updated successfully, but these errors were encountered: