Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JobHook Requiring Approval Executes without Approval #3440

Open
Tracked by #765
TwistByrn opened this issue Mar 17, 2023 · 2 comments
Open
Tracked by #765

JobHook Requiring Approval Executes without Approval #3440

TwistByrn opened this issue Mar 17, 2023 · 2 comments
Assignees
Labels
type: feature Introduction of new or enhanced functionality to the application

Comments

@TwistByrn
Copy link

Environment

  • Nautobot version (Docker tag too if applicable): 1.5.5 running on Alma Linux 8.7
  • Python version: 3.8.13
  • Database platform, version: Postgres 10.21
  • Middleware(s): No applications is being used outside of Nautobot with the Job Hook except Requests in Python

Steps to Reproduce

  1. Create a Job with class JobHookReceiver and the following Meta
    commit_default = False
    approval_required = True
    has_sensitive_variables = False

  2. Create Job hook for dcim|device with a Call on Update

  3. Update an existing object in dcim|device

Expected Behavior

When updating an existing dcim|device object the expectation is that before executing the job it would be placed into the approval queue

Observed Behavior

Jobs are executed without any approval when dcim|device is updated

image

image

@glennmatthews glennmatthews added type: bug Something isn't working as expected type: feature Introduction of new or enhanced functionality to the application labels Mar 17, 2023
@bryanculver
Copy link
Member

bryanculver commented Apr 18, 2023

If it's much more than adding some logic here:

JobResult.enqueue_job(
to mimic
if job_model.approval_required or schedule_type in JobExecutionType.SCHEDULE_CHOICES:
crontab = ""
if schedule_type == JobExecutionType.TYPE_IMMEDIATELY:
# The job must be approved.
# If the schedule_type is immediate, we still create the task, but mark it for approval
# as a once in the future task with the due date set to the current time. This means
# when approval is granted, the task is immediately due for execution.
schedule_type = JobExecutionType.TYPE_FUTURE
schedule_datetime = timezone.now()
schedule_name = f"{job_model} - {schedule_datetime}"
else:
schedule_name = schedule_form.cleaned_data["_schedule_name"]
if schedule_type == JobExecutionType.TYPE_CUSTOM:
crontab = schedule_form.cleaned_data["_recurrence_custom_time"]
# doing .get("key", "default") returns None instead of "default" here for some reason
schedule_datetime = schedule_form.cleaned_data.get("_schedule_start_time")
if schedule_datetime is None:
# "_schedule_start_time" is checked against ScheduledJob.earliest_possible_time()
# which returns timezone.now() + timedelta(seconds=15)
schedule_datetime = timezone.now() + timedelta(seconds=20)
else:
schedule_datetime = schedule_form.cleaned_data["_schedule_start_time"]
job_kwargs = {
"data": job_model.job_class.serialize_data(job_form.cleaned_data),
"request": copy_safe_request(request),
"user": request.user.pk,
"commit": commit,
"name": job_model.class_path,
"task_queue": job_form.cleaned_data.get("_task_queue", None),
}
if task_queue:
job_kwargs["celery_kwargs"] = {"queue": task_queue}
scheduled_job = ScheduledJob(
name=schedule_name,
task="nautobot.extras.jobs.scheduled_job_handler",
job_class=job_model.class_path,
job_model=job_model,
start_time=schedule_datetime,
description=f"Nautobot job {schedule_name} scheduled by {request.user} for {schedule_datetime}",
kwargs=job_kwargs,
interval=schedule_type,
one_off=schedule_type == JobExecutionType.TYPE_FUTURE,
queue=task_queue,
user=request.user,
approval_required=job_model.approval_required,
crontab=crontab,
)
we should update the document that this is a limitation for the time being.

@jathanism
Copy link
Contributor

jathanism commented Apr 19, 2023

I have asserted that at this time this is working as intended because we never implemented approval support for Job Hooks and doing so in the tail end of the 1.5 release train is more work than it is worth. So for now we will document that this is working as intended and that setting Meta.approval_required on a JobHookReceiver subclass will be ignored.

We will, however, fix this in Nautbot v2 as we work to bring everything to center as a part of the jobs overhaul work. We’ll be solving it all in one place (around the REST API), so what is now currently three code paths (UI, API, signals) should all be reduced down to one.

@jathanism jathanism removed the type: bug Something isn't working as expected label Apr 19, 2023
@jathanism jathanism removed their assignment Apr 19, 2023
@jathanism jathanism added this to the v2.0.0 milestone Apr 19, 2023
@jathanism jathanism mentioned this issue Apr 19, 2023
9 tasks
@bryanculver bryanculver modified the milestones: v2.0.0, v2.x.0 Jul 10, 2023
@lampwins lampwins removed this from the v2.x.0 milestone Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Introduction of new or enhanced functionality to the application
Projects
No open projects
Archived in project
Development

No branches or pull requests

7 participants