Software Development: Issues, Releases, Customers

The tabs

The Software Development menu in the left sidebar is, plan first: Releases (Planned / Shipped), Issues, Board, Testing. Pages don't repeat it as a row of tabs; the Testing page has its own row inside it (Library, Plans & runs, My tests). An issue and its Board card are one record. The Board shows the open issues (open means not resolved or closed, the same as the Open count on Issues) plus every resolved issue (the Testing column: QA still has to re-test it) and those closed in the last 7 days; its header gives all three numbers. Older closed issues are on Issues (Status: All). There is no separate "Native issues" or "Customers" tab: a workspace's Issues tab shows its own kind of issue (read-only Mantis for SoftInWay, native Otium issues for OtiumWork), and customers are a filter on Issues.

Needs the Software development module. Admins, developers and people with the QA flag can open these pages. For a Mantis workspace, Otium never writes to Mantis: a read-only copy of Mantis arrives on its own; an admin sets it up. Since November 2026 the copy covers every Mantis project the office token sees, with sub-projects, versions and the full issue (status, resolution, severity, priority, reproducibility, reported-in / target / fixed-in version, custom fields, tags, relationships), and it refreshes hourly from 7 AM to 7 PM Eastern. Until that hourly copy is installed, the pages use the older once-a-day copy of the projects that roadmaps name. The date of the last copy shows at the top of each page. If the last update failed, the page says so; tell your admin (admins also see the error). If the copy has not arrived yet, the pages say so in plain words: ask your admin. Issue type is Bug or Feature: Feature when Mantis severity is "feature" or the category is "Feature Request", otherwise Bug.

Issues

Sidebar, Software Development, Issues (/software/issues). One list of your workspace's bugs and features. Where the issues come from depends on the workspace:

• A Mantis workspace (SoftInWay): Mantis is the source of truth. The list is a read-only copy of Mantis: every number opens the issue in Mantis, and Report issue in Mantis opens the Mantis new-issue page. Change issues in Mantis; the copy follows. An issue named by two roadmaps appears once (the newest copy wins).
• A workspace without Mantis (OtiumWork): the issues live in Otium. Report issue opens a form here, and the issue number opens its page, where you can change it. User reports (Report a bug / Suggest a feature) and failed test steps open issues on their own.

Every issue is a Bug or a Feature. In Mantis, an issue with severity "feature" or category "Feature Request" is a Feature; anything else is a Bug.

• Quick filters: Bugs, Features (or both), and My issues (you are the handler), Reported by me, Unassigned, All.
• Counts at the top: open issues by project, status and handler. Click a name to filter.
• Filters: search, status (open by default: not resolved or closed; pick All or one status), project, category, handler, reporter, customer, component, target version. They combine.
• For Mantis, "you" means a handler or reporter that matches your name, your email, or the part of your email before the @. If nobody matches, My issues says so; ask an admin to align your name with your Mantis name.
• Columns: number, type, summary, project (with its parent projects), status and resolution, severity, priority, handler, target version, last update, and the test runs that found the issue. In a window narrower than about 1100 px, priority, target version, last update and test runs are hidden so severity and the handler stay in view.
• The list shows 200 per page.

Native issues (workspaces without Mantis)

An issue has the Mantis fields: type, status (new, feedback, acknowledged, confirmed, assigned, in review, resolved, closed), resolution (open, fixed, reopened, unable to reproduce, not fixable, duplicate, no change required, suspended, won't fix), severity, priority, reproducibility, category, handler, tester, project, reported-in version, target version and fixed-in version, plus a Blocked flag.

• Categories and owners: an admin names categories and their owners at the bottom of the Report issue page. A new issue with no handler goes to its category's owner.
• Moving an issue to closed with an open (or reopened) resolution sets the resolution to fixed and the fixed-in version to the target version, so Releases lists it as shipped. Moving it back from resolved or closed reopens it (resolution reopened, fixed-in version cleared).
• The issue page lists the test runs that found or verify it.

Your issues are your to-dos

The issues you handle (you are the handler) are on your My Tasks board too, as themselves: one record, not a copied task. Moving one there (drag, or its ⋯ menu) moves the issue, the same as on the Board: To do = confirmed, Doing = assigned (an issue in review stays in review), Waiting = flagged Blocked (a resolved issue waits there for its test), Done = closed. The Board's rules decide who may move it. An issue linked to a task that is already on your My Tasks shows once, as that task. Mantis issues you handle show there read-only, with Change in Mantis. A roadmap goal linked to a release shows that release's issues and how many are done.

Releases

Releases has its own page and help: see Software Development: Releases.

In the OtiumWork workspace, Releases → OtiumWork release log lists Otium's own releases. A planned release becomes "ready for prod" only when every item (branch, task, commit, issue) has a passing OtiumWork test run. The same rule applies when a deploy is recorded against a planned release: an AI agent cannot record an unproven planned release as released. It must prove each item first. Only Val can override, with a reason, by marking the release ready on this page. The override is logged and shows under the release.

Customers

Mantis has a Customer field on every issue; it shows in the Issues list and can be filtered. Issue customers (the link in the note at the top of Issues, Mantis workspaces only) lists each value with its issue count, and lets an admin map it to a Salesforce Account Id. Nothing links to Salesforce on its own.

• Suggestions are by name: exact (same name, ignoring case and punctuation) or close (for example "Acme Inc" and "Acme"). They come from the Salesforce accounts Otium already knows (the TPOC import), not a full Salesforce list, so a customer without a suggestion can still be mapped by pasting the Account Id (15 or 18 characters).
• Internal "SiW ..." values are left out.
• Leave the Id empty and Save to clear a mapping.