This switch is not what puts a job into service. An upstream-triggered run starts only if the job is activated (an approved activation request, made from the job page) and this switch lets the upstream job through. Unchecking it on a job that is not activated changes nothing. A job created while run control is on starts not activated, with this switch checked and the allowed-upstream list empty, so it needs its activation requested before any upstream job can start it. Jobs that already existed when run control was turned on were recorded as activated.
A value supplied when the job was created does not survive the creation lock: a
blockUpstream=false in a config.xml POST, a CLI
create-job, a Job DSL seed or the job this one was copied from is overwritten, and
the allowed-upstream list is emptied rather than carried over. While this switch is checked
that list is exactly the set of upstream jobs exempt from the block, so honouring a supplied
one would let whoever creates a job name the pipelines allowed to start it.
A refused upstream run has nobody to show a message to at the time, although the upstream job
reports the failed trigger. Afterwards, the job page says whether the job is activated and,
while this switch is checked, shows a notice naming Block upstream triggers; each refusal
writes a TRIGGER_BLOCKED change record naming what blocked it (at most one per job
and cause kind per hour, listed under Change Records and History and in
changes.csv); and the controller log carries a "Blocked upstream-triggered run of
job" line at most once an hour per job. Unchecking this switch is a recorded configuration
change and, with change control on, needs a permission window.