It always used to be that you could work out whether a job was running via scheduled execution or run via the Admin mode interface by checking within the job whether there was an HttpContext. If there was, then the job was run via Admin mode. If not it was scheduled.
Has this behaviour changed?
I'm on CMS 10.10.1 and HttpContext is always null, so I can't see a way to identify the context in which the job is run. I'm guessing may this changed with some of the improvement work around making jobs stoppable / supporting dependency injection etc. Are jobs run in their own new thread now perhaps?
Does anybody know if this is a deliberate thing?
Can anybody think of a way to work out if the job was manually started?
If memory serves it was a deliberate change to always start it up in their own thread.
I don't recall what version it was, but before the change when a job was started manually and run in the current HttpContext the job would also be aborted if the HttpRequest timed out.
No idea if you can find out if a job was manually started now.
I believe this changed in cms 10.3 so it's a while ago. It doesnt matter anymore if you start it manually or automatically, the job is always run in the same context.
The trigger is set in SchedulerOptions upon execution but I haven't found a way to reach it from within the job. However, the trigger is set in tblScheuledItemLog. It's an int value that corresponds to the enum ScheduledJobTrigger.
Thanks both. Good to know. That has some impact for anything that relies on an HttpContext. Nothing that can't be worked out though!
My exact requirment was to know the context so I could block automatic scheduling of the job (meaning the specific job can only be run by clicking 'start' in Admin mode). You can still do this - though its a bit of a hack. You check the job settings via the ScheduledJobRepository. If it is marked as IsEnabled (meaning it is set in Admin mode to run automatically), then I return from the job. I only allow it to execute if it isn't saved in the database to run on a schedule.
var job = _scheduledJobRepository.List().First(j => j.TypeName == GetType().FullName);
return "Execution of this job is disabled. Please turn off scheduled execution to allow this job to be executed manually";
Is there any consideration that forces it to be a job?
If a schedule isn't wanted I would prefer to add it as a Tool under CMS->Admin.
Good point Erik.
In my exact case, there is a bit more context that forces it to be a job. It should run automatically in the Production environment only, I only want to disable scheduled execution on downstream test environments.
That makes sense. As long as it is only for a test environment hacks are allowed.
Haven't tested this in CMS 11, but I've solved the same issue like this
//is in admin mode
since a scheduled execution is run in an anonymous user context.
Got this tip from Philip