Depends on (merged to dev first): AP-2450 (the "Web API decisions" definition setting in item 4), AP-2380 (Rovo starts in item 3).

Problem

1. Validity expiration steps ignore their label condition. A step added under "Run validity expiration steps" can have a label condition, but the labels of the work item or page are read at the start only when the start condition or a main, rejection or success step uses labels. Otherwise the expiration step runs on expiry whatever the labels are. When the labels are read, the expiration step is checked against the labels at the start, not at expiry. Applies to Jira and Confluence.

2. Expiration steps are not checked when a definition is saved from the definition form. The server checks main, rejection and success steps only, so an expiration step is saved with:

   • a webhook URL that is not a valid address, does not start with http:// or https://, or points to localhost (the webhook dialog checks only that the URL is not empty);

   • when the save request is sent without the form (the step dialogs check these): an automation step without the values its action needs (status, user field, comment, labels, entity property), or an AI Prompt step with an empty name or body, or one over the length limits. Such a step fails or does nothing when the approval expires. The Web API checks expiration steps itself (except the AI Prompt name length), but its error messages call every rejection and expiration step a "Success step". Applies to Jira and Confluence.

3. Archiving a condition breaks every definition that uses it as its start condition (Jira).

   • The New tab hides such a definition. Rovo, asked for it by name, says only that "its start condition is archived", without naming the condition. The Web API refuses the start with "Definition not found". A workflow post-function that starts it does nothing; only a warning is logged. A validity relaunch fails: the approval expires without a new one and without the expiry notification; only an error is logged. When the condition is archived between Rovo's prepare and submit, Rovo says that the definition or the work item changed since.

   • The definition form shows an empty "Add condition" field, and saving the form keeps the archived condition, so the user cannot see why the definition does not start or disappeared from the New tab.

   • A step whose condition is archived is left out of every new approval without any message. If all main steps are left out, the start fails.

   • The archive dialog says only that archiving "will deactivate the condition" and that it cannot be modified afterwards; it does not mention the definitions using it. Archiving cannot be undone.

4. POST /definition/{id}/duplicate is not used: the "Duplicate" action opens the definition form with a copy, and the e2e test uses the form too. The request copies only part of a definition (no expiration steps, label condition, page version settings, work item types, parallel groups, Slack channel or "Web API decisions" setting) and skips the definition checks. Applies to Jira and Confluence.

5. Saving from the definition form does not check that the start condition and the step conditions belong to the site, so a changed save request can link a definition to a condition of another site, whose settings then show in that definition. The Web API checks this. Jira.

Change

1. When label conditions are on, the labels are read whenever any step, the expiration steps included, or the start condition uses labels. An expiration step's label condition is checked at the start, against the labels read then (decision 1).

2. Saving from the definition form checks expiration steps like the other steps whenever they are saved (on-expire action "Run validity expiration steps"). Expiration steps that are not saved are not checked at all, so they no longer count, for example, as a duplicate AI Prompt step name. The Web API error messages name the step list that failed (for example "Expiration step[0]").

3. Archived conditions follow decision 2 (option a):

   • Archiving a condition, from the conditions list or through the Web API, is refused while the latest version of any definition uses it as its start condition or in a step. The message names up to 10 of those definitions; for a project's condition it names only definitions of that project and global ones and counts the others. The archive dialog says that conditions used by definitions cannot be archived. Archiving a condition and saving a definition that uses it at the same moment cannot both succeed.

   • A definition already linked to an archived condition (archived before this change, or still used by an older definition version) is no longer hidden: it shows in the New tab and in Rovo's list. JSM customers do not see it (customer portal, Rovo for customers), because they cannot change the definition. Every start of it (New tab, Web API, workflow post-function, Rovo's prepare and submit, rerun, validity relaunch) is refused with a message that names the archived conditions. A refused validity relaunch still sends the expiry notification.

   • The definition form shows an archived start or step condition by its name with an "Archived" tag and lets the user clear or replace it. Saving a definition that still uses an archived condition is refused with a message that names it.

4. The duplicate request and its unused frontend client code are removed. The "Duplicate" action keeps using the form.

5. Saving a definition, from the form or the Web API, refuses start and step conditions that do not belong to the site.

Decisions

1. An expiration step's label condition is checked at the start, like the other steps and step conditions, against the labels read then. Checking at expiry would cost one more Atlassian call per expiring approval with such a step.

2. Archiving is blocked while any definition uses the condition as its start or step condition, and the error lists those definitions. Definitions already linked to an archived condition are refused at start with a message naming the condition until the definition is edited. Treating an archived condition as no condition would silently remove a restriction the admin set up; keeping today's split would leave broken definitions until someone notices.

Out of scope

• Other gaps found in the same review: vote deadlines and group vote counts in AP-2495; watcher and "Required in parallel group" settings of field steps, and the required lock on AI Prompt steps, in AP-2487.

• Reading a definition through GET /definition/{id} with viewOnly: part of AP-2493.

Acceptance criteria

• With label conditions on, an expiration step whose label condition is not met is not run on expiry, also when no other step and no start condition uses labels.

• With label conditions off, expiration steps run as today.

• Saving a definition from the form with an expiration webhook step whose URL is "abc", "ftp://example.com" or "http://localhost" is refused with the same message as for a main step. The same holds for an incomplete automation step and an AI Prompt step without a name sent in the save request without the form.

• Expiration steps are not checked when the on-expire action is not "Run validity expiration steps" (they are not saved then).

• A Web API request with an invalid expiration step names "Expiration step[n]" in the error.

• Archiving a condition that the latest version of a definition uses as its start condition or in a step is refused (409 in the Web API) with a message listing those definitions; an unused condition is archived as before.

• A definition linked to an archived condition shows in the New tab; starting it from the New tab, the workflow post-function, the Web API or Rovo is refused with a message naming the condition. A validity relaunch of it is refused and the expiry notification is still sent.

• A JSM customer is not offered a definition linked to an archived condition in the customer portal.

• A save request sent without the form, with an on-expire action other than "Run validity expiration steps" and an expiration AI Prompt step named like a main AI Prompt step, is saved.

• A save request whose start or step condition belongs to another site is refused.

• The definition form shows an archived start or step condition by name with an "Archived" tag and can clear it; saving the definition while it still uses an archived condition is refused with a message naming it.

• POST /definition/{id}/duplicate returns 404; "Duplicate" in the definitions list still opens the form with a copy and saves it.

Manual tester notes

• Label condition: turn label conditions on. Create a definition with validity expiration (shortest period), on-expire action "Run validity expiration steps", and one webhook step there with "With labels: x". No other step and no start condition uses labels. Start on a work item without the label "x" and let it expire: the webhook is not called. Repeat with the label: it is called. Repeat on a Confluence page.

• Validation: add an expiration webhook step with URL "abc" in the form and save: refused. Repeat with "localhost". Send the form's save request with an incomplete automation expiration step (for example edited in the browser's developer tools): refused.

• Unsaved expiration steps (not possible in the form alone, which refuses a second AI Prompt step with the same name and drops expiration steps when the on-expire action changes): create a definition with an AI Prompt main step named "A", the on-expire action "Run validity expiration steps" and an AI Prompt expiration step named "B", and save it. Send the form's save request again, edited in the browser's developer tools: rename the expiration step "B" to "A" and set the on-expire action to RELAUNCH_SAME_VERSION: saved. Send it with only the rename: refused, naming "A" as a duplicate.

• Archiving a used condition (Jira): create a condition, use it as the start condition of one definition and as a step condition of another. Archive it from the conditions list: the dialog says that used conditions cannot be archived, and the archive is refused with a message naming both definitions. Try the same through the Web API (archive condition): refused, naming both. Remove the condition from both definitions and archive it again: it is archived.

• Relaunch of an older version (Jira): create a definition with a condition as its start condition, validity expiration with the shortest period and the on-expire action "Relaunch approval (same definition version)". Start it on a work item that meets the condition. Edit the definition to remove the condition, then archive the condition. When the approval expires, no new approval is started and the expiry notification still arrives.

• Definitions whose condition was archived earlier (Jira, if QA has any from before this change): they show in the New tab. In the customer portal, as a JSM customer, they are not offered. Starting one from the New tab, a workflow post-function, the Web API or Rovo is refused with a message naming the condition. The definition form shows the condition with an "Archived" tag; saving is refused until it is cleared, and after clearing it the definition starts.

• Duplicate: use "Duplicate" in the global definitions list and in a project (Jira) or space (Confluence) list; the form opens with the copy and saves.