Skip to main content

Issues

An issue is something someone wants looked at: a fault, a change, new kit, something lost. Most are about an asset, and the asset's page shows its issues alongside its history. It is free on every plan.

Tagaris is an asset register, and issues are kept deliberately small: a status, a category, a priority, an assignee and a thread of notes. There are no SLAs, queues, approvals or email-to-issue. If you run a service desk already, keep it, and link its tickets from the asset page (see Ticketing).

Reporting an issue​

Reporting needs the "Report issues and add notes" permission. Editors and administrators have it. View only means exactly that, so to let a view-only person report, put them in an access group that has it. People with no sign-in at all use the staff form below.

  • From an asset: the Issues card on the asset page has Report an issue, with the asset already chosen.
  • From the Issues page (Tools, Issues), for something that is not about an asset, such as a request for new equipment.
  • From the mobile app: scan the asset, then Report an issue on its screen.

People who may triage issues (Editors, administrators, and anyone an access group gives "Triage and resolve issues") can also set a priority, assign it to a user, and tick "Set the asset to Repair". That changes the asset's status now; resolving the issue later offers to put it back.

Working an issue​

On the issue's page, people who may triage issues can change the status (Open, In progress), priority, category and assignee. Each saves as you pick it. Anyone who may report issues can add a note.

Resolving asks how it was resolved, and offers two things when the issue has an asset:

  • Put the asset back to the status it had before the issue set it to Repair. This is only offered while the asset is still in Repair, so it never undoes a change someone made since.
  • Log this as a repair on the asset, with an optional cost and supplier. It appears in the asset's maintenance records and its total maintenance cost.

A resolved issue can be reopened. Reopening clears the resolution, so the issue does not carry a stale outcome. Administrators can delete an issue, which is recorded in the audit log.

Every step is written to the asset's history: reported, resolved, reopened.

Categories​

Categories are yours to define, under Settings, Issues. A new organisation starts with Fault, Change request, New equipment, Lost or stolen and Other. Each has a colour and a switch for whether staff can pick it on the staff form. Deleting a category leaves its issues in place without a category.

The staff form​

Most people who notice a fault do not have a Tagaris login and should not need one. The staff form is a page where anyone with the link can report an issue.

Switch it on under Settings, Issues. You get a long private link to put on your intranet or print as a QR code by the printers. The form can also have an address of its own, such as help.example.com, so people type that instead of following a link; see Its own address. It asks for a name, an email address, what it is about, an optional asset tag, where the item is and what is wrong.

  • Email is required by default. Turn that off where staff have no mailbox; a name is always required.
  • A reporter whose email matches a person in your register is linked to that person.
  • If the asset tag matches, the issue is linked to the asset. If it does not, the issue keeps the tag as typed, shows as "not matched" in the list, and an editor can link it by tag from the issue's page.

Scanning a label without a login​

With the staff form on, someone who scans an asset's QR label and is not signed in sees the usual sign-in page with one addition: "Not in IT? Report an issue with this item". That opens the form with the item already chosen, so every label already on your kit becomes a way to report an issue, with nothing to reprint. IT staff who sign in from the same page land on the asset they scanned.

What the form gives away, and how it resists abuse​

It is the one page in Tagaris that works without a login, so it is built to give nothing away.

  • It shows nothing from your register. Opened from a label it shows that item's asset tag, which is printed on the label the person is holding, and nothing else.
  • It says the same thank-you whether or not the asset tag matched, so it cannot be used to find out what you own.
  • The link is unguessable, and "Make a new link" retires every copy of the old one at once. That is the way to stop misuse.
  • One address can send five reports in ten minutes, and the form accepts 200 a day per organisation. A hidden field catches scripts. There is no file upload.
  • Nothing is ever emailed to the address typed into the form automatically, so it cannot be used to send mail to strangers. When an administrator resolves a staff report they can choose to email the reporter that it is resolved. That is the only mail a reporter receives.
  • It is switched off on the public demo server.

No third-party service is involved: no CAPTCHA, nothing leaves your server.

Its own address​

An organisation can give its form a hostname of its own, for example help.customer-x.com, and on a server with several organisations each can have one: help.customer-x.com, help.customer-y.com, help.internal.com. Set it under Settings, Issues, "Its own address". Then, in the reverse proxy in front of Tagaris, route that hostname to the same Tagaris container as your main address, with its own certificate. A request for the root of that host gets the form, with the organisation's own name and logo if it has set them (Settings, Branding), and that is all the hostname serves: the sign-in page and the app on it send people to the form, so staff never see an admin address. It is the same form, and the link still works.

The hostname must be different from the address Tagaris itself is on. Tagaris does not need BETTER_AUTH_TRUSTED_ORIGINS for it, because the form involves no sign-in.

Hearing about new issues​

  • The daily digest lists issues raised since the last one, each mentioned once, high priority first. A burst of staff reports arrives as one email the next morning. See Reports and alerts.
  • If you have Slack, Teams or a generic webhook set up, each new issue is posted there as it arrives.

Passing an issue to Jira​

With the Jira integration set up, an issue that is linked to an asset has Raise a Jira ticket. It creates the ticket through the same connector as the asset page, carries the issue's title and details, and shows the Jira ticket on the issue and on the asset's Issues card. Tagaris never changes the ticket afterwards. See Ticketing.

The API​

GET /api/v1/issues lists issues (open by default; status=all, OPEN, IN_PROGRESS or RESOLVED, and assetId= to narrow). GET /api/v1/issues/{id} returns one with its notes. POST /api/v1/issues raises one, with the same fields and validation as the app. See the API reference.

What can go wrong​

  • "That is a lot of reports in a short time": the per-address limit. Behind a reverse proxy that does not pass the visitor's address on (X-Forwarded-For), everyone shares one address and the limit is reached sooner. Configure the proxy to pass it.
  • The staff link shows "not found": the form was switched off, or a new link was made. Copy the current link from Settings, Issues.
  • The "Report an issue with this item" link does not appear after a scan: the staff form is off for that asset's organisation.