Current behavior:

• If the "Create job" call does not have "due" metadata, the job inherits the project's due date, across all workflow steps.
  • → If the project does not have a due date, the jobs will do not have a due date as well.
  • → If the project has a due date, the jobs have the same due date as well.

Requested behavior:

• The behavior follows the UI, so if the "Create job" call does not have "due" metadata, it does not inherit the project's due date and thus the job simply does not have a due date.

Use case:

The "Create job" API method applies precisely the same due date for jobs across all workflow steps which does not make much sense, as multi-workflow step projects seldom have the same due date for all steps, and it is also infrequently the project due date. For example, the client usually uses 3- or 4-workflow step templates, which include a quote (no due date needed, jobs are simply analyzed at this step to get a CAT log for client quoting), translation (and possibly editing), which have different due dates for individual workflow steps (and sometimes for individual jobs, if a particular project is, e.g., split between two linguists), and finalization step, which has no due date as well, and serves solely the purpose of downloading the finalized file. In addition, the project due date is usually a couple of hours or days away from the jobs' due date at the last linguist-involving workflow step, so PMs can have some time margin to review the deliverables and download the final files.