Administration

Every project has its Lacre settings page, "Lacre in this project": in the Jira project settings, the "Lacre" entry. It is where you configure how sealing works in the project and get the evidence out for the auditor.

Who can see it

Only project administrators and Jira administrators. Lacre asks Jira, with the account of the person opening the page, every time the page loads and every time it saves; anyone else sees "Only project or Jira administrators can see and change these settings."

On a site on the Jira Free plan, every user administers the projects, so everyone can change the Lacre settings, export the seals and delete the project's data. If that does not suit you, you need a Jira plan with project permissions.

Enabling and disabling

"Lacre enabled in this project" is ticked by default. When disabled, the issue panel does not allow ticking or sealing, but it still shows the existing seals, "Verify" still works and alterations are still recorded, so that there is no gap in the evidence.

Panel language

"Each user's language" (the default) shows the panel in each person's language. With "Spanish" or "English", everyone sees the checklist and seals in that language, and the project's evidence uses only one: each seal stores the checklist texts in the language it was sealed in.

Checklist

The project starts with the default checklist. It can be changed under "Checklist":

• up to 12 items, each with its "Spanish text" and its "English text" (both are needed);
• "Required" ticked or not: required items must be ticked before sealing;
• "Move up" and "Move down" change the order; "Remove" removes the item; "Add an item" adds one at the end;
• "Back to the default list" undoes the changes to the checklist.

Changing the checklist does not change existing seals: each seal keeps the checklist it was made with. What does change is what has not been sealed yet: a new item, or one whose text has been edited, counts as a different item, so any ticks it had on issues not yet sealed are lost and it has to be ticked again. This way a tick never moves to a text the person who ticked it did not read. If someone has the panel open while the checklist changes, sealing tells them the checklist has changed and shows the new one.

Who checks, seals and approves

• "Project roles that check and seal": up to 20 Jira project roles. With none, anyone who can see the issue can check and seal.
• "Project roles that approve": up to 10. With none, nobody approves.
• "Require prior approval for HIGH risk": with high risk, the check cannot be sealed until someone with an approver role has sealed the prior approval (how it works). At least one approver role is needed.

Roles come from Jira: Lacre checks with Jira, on every tick, seal and approval, that the person has one of the chosen roles in the project. Lacre does not prevent the same person from having a sealing role and an approver role: if the duties must be separate, assign them to different people. If a chosen role is deleted in Jira, the page marks it as "no longer in the project".

Custom fields in the seal

By default, the seal stores the issue's system fields (summary, description, status, assignee, priority, fix versions…). Under "Sealed fields" you can add up to 50 custom fields of the project, which become part of what is sealed and, if they change afterwards, mark the seal as altered. Only single-line text, URL, number, date, option and label fields are offered: never people fields or fields that Jira changes on its own. The change applies to seals made from then on.

Saving

"Save" saves all the settings at once, and below it you can see who made the last change and when. If someone else has saved in the meantime, the page does not overwrite their changes: it shows the current ones, keeping what you changed, so you can review them and save again. Every save is recorded in the activity log.

If the saved settings ever cannot be read, Lacre does not use them and, meanwhile, nothing can be ticked or sealed in the project. The page then offers "Restore the default settings": the saved configuration is lost and Lacre stays disabled until you review the checklist, the roles and the fields and enable it. The restore is also recorded in the log.

Export the seals

"Export the seals" prepares a file with the project's seals signed between two days, both included. The days are in UTC: a seal signed on 1 March at 00:30 in Madrid (23:30 UTC on 28 February) falls on 28 February. By default the period offered runs from 1 January of the current year to today.

It includes the seals made in the project, even if its key changed afterwards or the issue is in another project today. Only seals of issues you can see in Jira go into the file; those of issues with a security level you cannot see, or deleted ones, are counted separately and not exported.

There are two formats:

• JSON ("JSON: the full records"): every seal with its full record, its hash, its alteration if it has one and the issue description as it was sealed. It is the one for verification: each seal, saved in its own file, is checked with the Lacre verifier, and the file cites the verification guide.
• CSV ("CSV: one row per seal"): for a spreadsheet, with the identifier, the issue, the type, the risk, the approving role, who signed and when, the status, the altered fields and the hashes.

Click "Prepare the file" and, when it is ready, "Download". The page reads the seals in pages and shows how many it has read; "Cancel" stops it and, if something fails, "Try again" continues from where it stopped. If the browser cannot put the file together, try a shorter period. Every export is recorded in the activity log.

About the CSV:

• Each signer's name goes in a separate column, "signerName (resolved at export)": it is the name Jira gives at export time, not the one they had when sealing. The seal stores the account identifier, which does not change.
• A cell starting with =, +, - or @ gets an apostrophe in front, so that the spreadsheet reads it as text and not as a formula.
• The special rows go at the end: unreadable, one per seal that could not be read, with its key in the storage, and restricted, one per seal of an issue you cannot see, with no other data.
• The file is UTF-8 and comma-separated. A spreadsheet set up for a language that uses a comma as the decimal separator may open it all in one column on a double click: open it with "Data > From Text/CSV" (or your program's import option) and choose the comma as the separator.

Evidence sheet for a seal

"Evidence sheet for a seal" prepares, for one specific seal, a page to print or save as PDF and hand to the auditor. Enter the "Issue key" (of this project), click "Show the seals" and, on the seal you want, "Prepare the sheet".

The sheet has the seal (issue, type, risk, who and when, position, status and alteration), the sealed checklist with who ticked each item, the issue as it was sealed, the stored description, the verification and the full canonical record.

• The verdict is only green if the seal matches its record and the issue's next seal, if there is one, chains to it. Otherwise it says it cannot be taken as valid, and why.
• "Print or save as PDF" opens the browser's print dialog, in A4 size.
• "Download the seal as JSON" downloads the seal into a file to recompute its hash with the verifier. To recompute it, use that file, not the paper or text copied from the PDF.
• Names are those Jira gives when the sheet is prepared, next to each account identifier.
• Invisible characters and characters that change the writing direction are shown by their code (U+…), so that nothing in the record stays hidden.

Every sheet prepared is recorded in the activity log.

Activity log

"Activity log" shows, with who and when (in UTC), newest first:

• settings changes, with the new values (for the checklist, how many items and how many are required) and restores;
• exports of the seals, with the format and the days;
• evidence sheets prepared, with the issue and the seal;
• exports of the log itself.

Click "Show the log"; entries come fifty at a time ("Show more") and "Read again" refreshes it. Entries store no issue text, and names are those Jira gives when the log is read. Entries about issues you cannot see in Jira are only counted. "Export the log (CSV)" downloads it in full, with the name in a separate column ("actorName (resolved at export)") and with the same care about formulas as the CSV of the seals.

Delete this project's Lacre data

At the bottom of the page, "Delete this project's Lacre data" deletes from the app storage what Lacre keeps about the project. It cannot be undone, so export the seals and the activity log first: after the deletion, those files are the copy that remains.

Deleted:

• the seals made in the project, including those from before a change of its key and those of issues that no longer exist, with their alterations and stored descriptions;
• the state of checklists that were partly ticked;
• the project's activity log.

Kept:

• the seals of issues that are in another project today, because their panel still shows them;
• the seals before a seal of another project in the same issue: an issue has a single chain, and deleting them would break the other project's;
• the copies of each seal in its issues (Jira's lacre.seal properties): they live in your organization's Jira and are deleted from there;
• the seals made in another project, which are not touched.

To confirm, type the project key and click "Delete all of this project's Lacre data". When it starts, Lacre is turned off in the project and its settings go back to the defaults, so that nobody seals while the data is deleted. "Stop" halts the deletion (what was deleted does not come back) and "Continue the deletion" finishes it. At the end, the page says how many seals, states and entries it deleted and how many seals it kept. The deletion is recorded, with who asked for it and when, in the installation log, outside the project. To use Lacre in the project again, turn it on above.

Uninstalling the app

When Lacre is uninstalled, Atlassian deletes the app storage 28 days later. The lasting copies of the evidence are the exports and the lacre.seal properties of each issue, which stay in Jira.

Without an active subscription

The settings page works in full even if the site subscription is not active: you can export, prepare evidence sheets and delete. What stops is ticking, sealing and approving in the panel. A site administrator activates the subscription in Jira's app management.