Please note that VisualCron support is not actively monitoring this community forum. Please use our contact page for contacting the VisualCron support directly.


anhe
  •  anhe
  • Paid support Topic Starter
2023-10-31T09:56:30Z
When configuring jobs (and/or tasks) we often need to register some metadata about the job. That could be who is the owner, contact email for notifications, path of data files, etc. This could be obtained by a new metadata feature or simply by allowing to create "Job local" variables, that can then be accessed from all tasks in the job and global notifications too.

The information should be easy accessibly like

{JOB(Active|Variable|MyJobLocalVariableName)}

or
{JOB(Active|Metadata|MyJobAttributeName)}


Currently there is not easy way to register this (except for in the description, that would then have to be parsed manually). Global variables will not work here, since... well they are global :-)

If a local variable uses the same name as a global variable you could consider whether it should cause an error or simply override the global value for that specific job context.

A simple use case that we really need, is that when a job fails we have a global notification and we need the error log file from the job to be attached and the job contact to be notified. However, there is currently no way of getting the path or any custom attribute data of the failed job. We could create custom notification for every single job in our system, but that does not scale and is not maintainable.

Kind regards,
Anders
Sponsor
Forum information
bweston
2023-11-02T16:04:22Z
I'm a little confused as to whether you are asking for a change to how job variables work, suggesting that custom attributes need to exist alongside them, or just missed their existence somehow.

I will say I think it would be nice if having a global notification refer to a job variable that doesn't exist on a particular job, for example, could fail a little more gracefully - if I remember correctly, the attempt to access it produces an error message when gets used in place of its value, and wrapping that in something else to provide a less confusing fallback is not only a very verbose thing to try to do, but might not always work. I'm not sure; I haven't messed with it in a while.
jdykhuis
2024-04-12T14:46:19Z
I agree with the intent of this request. I often look at VisualCron jobs in the main grid to see who the 'owner' is. The Created By, Modified fields provide insight, but often the owner of the job is neither. We are using the Description field, but it is the second line as we want to see the job's description in the job's row. If you hover over the Description, you do see the entire contents of the field. Also, when migrating a job from a lower environment, the export/import process shows the two fields as Administrator.
Scroll to Top