Sealing and approving

Every change goes through two seals: the check, by whoever carries out the change, and the approval, by someone with an approver role. For high-risk changes, the project can also require a prior approval, before the check. All three are done in the issue's "Lacre" panel.

Ticking the checklist

The panel shows the project's checklist. Required items must be ticked before sealing; optional ones are ticked if they were done. Each tick is saved as soon as it is made, with who made it and when: below the item, "Ticked by" appears with the name and the date in UTC. Anyone who opens the issue later sees the same ticks, and if two people change the same item, the last change counts.

Also choose the change risk level: "Low", "Medium" or "High". It is always chosen; there is no default value.

If you cannot tick, the panel says why: you have none of the project roles that tick and seal, Lacre is turned off in the project or the site subscription is not active.

Sealing the check

With the risk chosen and the required items ticked, click "Seal check". If something is missing, the panel says what: "To seal, choose the change risk level." or the list of required items still missing.

The seal stores, in a record that never changes again:

• who signs (their Atlassian account, confirmed with Jira at the moment of sealing) and when, in UTC;
• the checklist as the signer saw it, with each item ticked or not and who ticked each one and when;
• the risk level;
• the state of the issue at that moment: key, project, type, summary, a fingerprint of the description, status, assignee, reporter, priority, resolution, labels, components, fix versions and the custom fields the project has chosen;
• the SHA-256 hash of all of the above and the hash of the issue's previous seal, so that the seals of an issue form a chain.

Lacre also writes a summary of the seal into a property of the issue itself (lacre.seal. followed by the hash), which stays in Jira even if the app is uninstalled. When it finishes, the panel says "Evidence sealed.", the header shows the seal identifier and the ticks move into the seal: the checklist is left unticked for the next check.

If the panel says something else

• "This state was already sealed: no new seal was created.": nothing has changed since the last seal (not the checklist, the risk or the issue), so another one is not needed.
• "The checklist or the risk level changed since the panel loaded": someone else changed them, or an administrator changed the project's checklist. The panel already shows the current state: review it and seal again. Lacre only seals what you had in front of you.
• "Another seal of this issue was stored in the meantime.": someone sealed at the same time. The panel already shows it; seal again only if needed.
• "This issue has moved to another project since the panel was opened.": reload the issue page, to seal with the checklist and roles of its new project.

Sealing again

If the change is redone or the issue is edited after the seal, another check is sealed. The previous one becomes "Superseded" and is kept: Lacre never deletes a seal. The new check needs its own approval, because the approval of the previous one is superseded with it.

Approving

Anyone with one of the project's approver roles sees, below the current check, the "Approval" section with the "Seal approval" button. The approval approves the check as it was sealed: its record copies that check's checklist and risk and stores the state of the issue at the time of approval. If you have several approver roles, choose which one you approve with in "Role you approve with": the role is stored in the seal.

From then on the panel shows "Approved" with who, their role, the date and the approval identifier. A check has a single current approval: if it is already approved, the panel says so and does not create another.

If the project has no approver roles, nobody can approve and the section does not appear. Lacre does not prevent the same person from checking and approving if they have both roles: to keep the duties separate, the administrator gives the sealing roles and the approver roles to different people.

Prior approval for high-risk changes

If the project has "Require prior approval for HIGH risk" ticked and you choose the "High" risk, the check cannot be sealed until someone with an approver role has sealed the prior approval. The panel says so: "HIGH risk: the project requires prior approval from an approver before the check is sealed."

1. Whoever prepares the change ticks what they can and chooses the "High" risk.
2. The approver clicks "Seal prior approval": it approves the change with the checklist as it is at that moment, even if required items are missing (the change has not been carried out yet).
3. The change is carried out, the rest of the checklist is ticked and "Seal check" is clicked, which is now possible.

The prior approval belongs to the next check that is sealed. If any field of the issue changed between the two, the panel shows it: "Between the prior approval and the check, the issue changed in:" and the fields. If the risk is lowered after the prior approval, the check carries it anyway: what was approved was a high-risk change, and that is what the record says.