Octbase User Guide

What is Octbase?

Octbase replaces Jira for task, sprint, and board work, includes its own pages, and integrates with GitHub, GitLab, and Bitbucket (it does not host git) — one tool that does the core workflow really well. It is designed for a single team where every user is known and invited by an administrator.

Signing in

Octbase uses invitation-only registration — there is no public sign-up. An Admin or Super Admin invites you by email and you set your own password when accepting the invitation link.

1. Open the app and you will see the sign-in page.
2. Enter your email address and password, then click Sign in.
3. If your account has two-factor authentication enabled, a Two-factor verification step appears — enter the 6-digit code from your authenticator app (or one of your recovery codes) and click Verify.
4. After signing in you land on the Dashboard.

Password requirements

Whenever you set a new password — accepting an invitation, using a reset link, changing it yourself on the Settings page, or when an administrator creates your account — it must be at least 12 characters long, and trivially common passwords (e.g. password1234) are rejected. Existing passwords are not affected until you change them.

Staying signed in

Octbase signs you out after 8 hours without any activity — a working day, so a lunch break or a long meeting does not cost you your session. Anything you actually do — a click, a keystroke, a scroll, a tap — restarts the clock, so the timeout only ever fires on a session that has genuinely been left alone. When it does, a short “your session timed out” message appears and you are returned to the sign-in page.

This is not only a screen behaviour: the server caps the session to the same window, so leaving a tab open overnight cannot keep a session alive. There is a second, absolute limit of 12 hours from the moment you signed in, which no amount of activity extends — so a session always ends the same day it started. Sign in again to carry on — nothing you had already saved is lost, but an edit you were still in the middle of is not saved for you, so finish or save a long description before stepping away.

The sign-in screen then says "You were signed out after 8 hours of inactivity. Please sign in again." If you were signed out while reading a particular task or page, signing back in returns you to it rather than to the dashboard.

Demo installations

If the installation you are signing in to runs in demo mode, the sign-in page shows a hint naming the shared demo account and its password — they are public by design on such an instance. A demo account's password is locked: the Settings page shows the password panel but refuses the change, because the account is shared with everyone else looking at the demo. Every other instance behaves exactly as the rest of this guide describes.

Dashboard

The Dashboard (My work) is the first screen after signing in. It gives you a personal overview across all projects you are a member of.

Click any task or page title to open it directly. Use Ctrl+K to search across everything from any view.

Every section above is a shortlist, not a report: each is capped at the size given, and the caps are not announced on screen the way the project list's is. The Dashboard answers what should I pick up next; when you need the complete set, open the project's Task list or Backlog, which page through every match.

The calendar

Octbase draws the same month calendar in two places, and which one you want depends on the question:

• My calendar — its own page in the main sidebar, at /#/calendar. The same cross-project grid with the whole screen to itself, so it can be deep-linked, bookmarked and reached with Back and Forward. The entry is there whether or not you have a project open.
• A project's Calendar — the Calendar entry in the project sidebar, at /#/projects/ID/calendar, showing that one project's dated work. The project picker is off here, because the project is the view.

Both read the same way. Where the lists answer what is on your plate, the calendar answers when:

• Tasks appear as a chip on their due date. Click one to open its task panel, exactly as from a list or a search result. An overdue task is highlighted; a finished one is struck through.
• Sprints are drawn as a bar spanning the days of the iteration. A bar that continues into the next week is left open at that edge rather than looking as though the sprint ends on a Sunday. Click it to open that project's sprint list scrolled to the clicked iteration, with the card briefly highlighted.
• Releases are marked on their due date; clicking one opens the project's release list at that release, briefly highlighted.

Use ‹ / › to page months and Today to come back. Three filters accompany the grid, and all of them are remembered in this browser:

• My work / All work — by default the calendar shows only what you are carrying (assigned to you, or waiting on your review). Switch to All work to see every dated task in the selected projects.
• Projects — one chip per project, labelled with its abbreviation. Click chips to include or exclude projects, or All to go back to everything. A project created later joins the calendar on its own. (Not offered on a project's own Calendar, which is already one project.)
• Sprints / Releases — the legend beneath the grid is itself the switch: click Sprints or Releases due to hide that overlay and click again to bring it back. A struck-through legend chip means the overlay is off — useful when a month full of iteration bars is drowning out the tasks you came to read.

A day with more entries than fit shows +N more; click it to expand that day.

How many projects the list shows

One dashboard read returns the first 50 projects you are a member of. That page size is what My projects lists, and because the boards come from those projects it also bounds My boards.

This page size is the Dashboard's alone. All projects lists every project you are a member of, and My calendar's Projects filter offers one chip for each of them — neither is bounded by the 50 above. If the Dashboard's shortlist and the All projects grid disagree about how many projects you are in, the grid is the one telling you the truth.

You are told when it bites. If your membership runs past 50, a line appears under My projects reading “You are in more projects than this list shows.” It is shown only when projects were genuinely left out — being in exactly 50 does not produce it, so the note never claims a gap that is not there.

This is a page size, not a limit on what you may see: the projects past it are still yours, with exactly the access they always had — only this one screen is bounded. The list is ordered by project age, newest first, so it is the oldest projects you belong to that fall outside it, and archived projects still take up a place (archiving changes a project's status, it does not remove your membership).

Optional features

Some of what this guide describes can be turned off for a whole installation, which is why a screen occasionally differs from the text here. Your Octbase reports its own configuration at sign-in, and the effects you may meet are:

• A view that is not there. Optional features (the Task list view, Jira CSV import) can be switched off per deployment. Acting on one that is off reports not available in your Octbase edition.
• A user limit. An installation can cap how many accounts exist; creating one past the cap reports this installation has reached its maximum number of user accounts.
• Uploads switched off. Attachments can be disabled entirely, reported as File uploads are switched off on this installation. There are also per-file and per-user storage caps — see Attachments.

The version your installation runs is printed at the bottom centre of the app (the octopus keeps the corner). Quote it when reporting a problem.

Creating and managing a project

A project is the top-level container for tasks, a board, releases, sprints, pages, and repository connections.

Creating a project

Admin and Super Admin users can create projects. Click New project on the project list screen. Provide a name, an optional abbreviation, an optional description, and choose Public or Private visibility.

Editing and deleting

Every project card on the projects screen shows Edit and Delete buttons. Inside a project, the same two live on its settings page: click the gear in the top bar and stay on the General tab, where the details form edits it and a Delete project card sits below. Deleting a project permanently removes all of its tasks, boards, pages, releases, and activity — a confirmation dialog warns you before proceeding. Deleting is open to a project's Owner and Admin; other members do not see the card.

Archiving

Archiving freezes a project without deleting anything: it stays fully readable, but nothing in it can be created, edited or moved until it is unarchived. Archiving and unarchiving are open to a project's Owner and Admin.

Click the gear in the project top bar to open the project's settings and choose Archive project on the General tab (German UI: Projekt archivieren); the dialog says exactly what changes before you confirm. Once archived, that same card offers Unarchive project — archiving is reversible, and it is the only way back, because the ordinary "edit project" route is frozen along with everything else while the project is archived. The banner across the top of an archived project offers the same button, so you never have to hunt for it.

Exporting a project

Any project member can export the whole project as a single ZIP archive. Exports are capped at 30 per user per hour; past that the request is refused until the hour rolls over. Click the gear icon in the project top bar and scroll the General tab to Export project (German UI: Projekt exportieren). The archive contains everything that makes up the project:

• All tasks with their comments (including reply threads), web links, and task relations
• All attachments — uploaded files are included with their original bytes, external links are preserved
• All pages with their hierarchy and their cross-references (TASK-… and link:task:… alike)
• The planning structure — releases, sprints (with their velocity figures), boards and their lanes, task categories and task templates (both are API-only features — see below) — and, for every task, the release, sprint and board lane it is placed in
• A project.json manifest with the project metadata

The archive is re-importable: use it as a backup, or to move a project to another Octbase instance.

Three things are deliberately not in the archive: the project's member list (an export file must not be able to grant access — people are matched by email on import instead), the repository connections (they hold credentials for your Git provider), and the activity and audit log, which belongs to the instance rather than to the project.

Importing a project

Members with a writer role (any project role except Viewer) can import a previously exported archive. Open the gear in the top bar → General and choose Import project (German UI: Projekt importieren), then select the ZIP file. The imported content is added to the current project — existing content is never modified or deleted.

• Everything is recreated with fresh IDs; task numbers are re-assigned using the target project's abbreviation, and comment threads, page hierarchy, task relations, and the task references inside pages (both the TASK-… and the link:task:… spelling) are re-linked automatically.
• People are matched by email address. If an assignee, reporter, or comment author doesn't exist on the target instance, the field is left empty (comments fall back to the importing user) and a warning is reported.
• Page slugs that already exist in the target project are de-conflicted with a numeric suffix.
• Imported files pass the same file-type and size checks as regular uploads; anything disallowed is skipped and reported.
• The archive's boards and sprints are added alongside the ones the target project already has. A project can only have one default board and one active sprint, so an imported default board becomes an additional board (silently — this is not reported as an import warning) and an imported active sprint arrives as planned; sprint dates that would overlap an existing sprint are dropped. Each of these is reported as an import warning.

People are matched by email address. An assignee or reviewer the target installation does not know is left empty; the reporter is not — it falls back to whoever ran the import, so every task still has one.

Creating a new project from an export

Instead of importing into an existing project, you can create a brand-new project straight from an export archive: on the project list screen, click New project from export and select the ZIP file. The project's name, abbreviation, description, and visibility are taken from the archive, you become its Owner, and all content is imported in one step. Like regular project creation, this requires the Admin or Super Admin global role.

Project members

The Members tab of a project's settings is visible to the project's Owner and Admin only. Other members see the people they work with through assignees, reporters and activity rather than through this tab.

A project's Members tab (the gear in the top bar) lists everyone who can see it, with a row of counts across the top — total, and how many are owners, admins, members and viewers. A search box and a role filter narrow the list; your own row is marked (you).

Two things can be done from each row, if your role allows it:

• Change their role from the select in the row. It takes effect immediately.
• Remove them from the project. Their account is untouched — they simply lose access to this project.

Pending invitations

Invitations that have not been accepted yet appear in their own panel below the member list, and this is where you find out whether the mail actually arrived. Each pending invitation shows its expiry date, the role it will grant, and a delivery status:

• Sending — handed to the mail server, no result yet.
• Delivered — the mail server accepted it.
• Not delivered — it failed. The invitation itself is still valid, so copy the link and send it yourself, or resend.

Resend issues a new link (and copies it to your clipboard); the previous one stops working. Revoke cancels the invitation outright — their link stops working immediately.

Import & export

Octbase project archives

The recommended way to back up a project or move it between Octbase instances is the whole-project ZIP export/import in Project settings → General. It round-trips tasks, comments, files, pages, and the releases, sprints and boards they are planned in — see Projects for details.

Migrating from Jira

Import existing Jira data per project via the Jira CSV import. It is part of every Octbase subscription and switched on by default; an administrator can turn it off for a particular deployment, in which case the button is simply absent.

Jira CSV import

Export your Jira project as CSV (Project → Export → Export Excel CSV). Then open the project's Project settings → General and choose Import Jira CSV. Octbase maps Jira statuses and priorities to Octbase equivalents and stores the original Jira issue key in the external_ref field for cross-referencing during the transition period. Comments and attachments round-trip too: repeating Comment columns become task comments, and repeating Attachment columns become attachment entries on the imported tasks.

Import report

The import response is a report: how many tasks and attachment links were imported, how many rows were skipped, and a per-row list of warnings (with row number and Jira issue key) for anything that needed a fallback — unknown statuses or priorities, users that could not be matched by email, or malformed attachment/comment cells. The import also appears as a single entry in the project's Activity view.

Dry run

The Jira CSV importer can also run as a dry run: it reads the file and returns exactly the report described above — counts, skipped rows and per-row warnings — without writing anything. It is a good way to check the mapping of a large export before committing to it.

Kanban board

The board is the primary task view. Tasks are organised into columns (lanes) that map to a workflow status. Press B from inside any project to jump here.

A card's lane and its status are two views of the same thing and stay aligned both ways: dragging a card to another lane sets the task's status to that lane's status, and changing a task's status elsewhere (for example from the task panel) moves the card into the matching lane. A task not on the board yet joins it when its new status says work has started (In Progress or Review) — started work belongs on the board, not in the backlog. Setting Planned puts a backlog task into the To Do lane — Planned is that lane, not the backlog; Backlog is the status that takes a card off the board again. A finished status does not pull a task onto a board it never visited, and a board that has no lane for the new status places or moves nothing.

Where the board comes from

You do not create a project's board by hand, and there is no template to pick: every project is created with its board already there, named Main Board and pre-filled with four lanes — To Do · In Progress · In Review · Done. The lane names are written in the language the project's creator was using at that moment (English or German), and you can rename, reorder, add and remove them afterwards at any time — see Configuring the board.

The other boards in a project appear the same way rather than being built by hand: every sprint gets its own board the moment the sprint is created, with the lanes copied from the project's board (see Sprints). Completing the sprint removes that board again.

Configuring the board

Click the ⚙ Board settings button above the board to customise it. You can rename the board, add lanes, rename existing lanes, reorder them, and remove lanes you no longer need. A lane can also be renamed right where it stands: click its name in the lane header (or the pencil beside it), type, and press Enter — Escape puts the old name back, exactly as a task's title is edited in the task panel. The same dialog carries a minimum and maximum lane count for this board — they default to 1 and 10, and each can be set anywhere from 1 to 10 (the minimum may not exceed the maximum). Lowering the maximum is how you stop a board growing wider than it should; once a board is at its maximum, Add lane refuses with a message rather than going ahead. A custom lane name becomes a usable task status, so the board's columns and the available task statuses always stay in sync: renaming a custom lane renames the status its tasks carry, while renaming a built-in lane (for example calling "Done" "Shipped") changes only the label — the built-in behaviour stays. Removing a lane sends the tasks in it back to the backlog, where they return to Backlog — the backlog holds work that has not started, so a card cannot sit there still marked In Progress. Tasks already Done keep that status.

Board settings also carries Use as Scrum sprint board, with a Linked sprint picker beside it. It marks any board as a sprint board and binds it to a sprint that has not been completed — so a team that wants one long-lived board per sprint, rather than the per-sprint boards Octbase creates automatically, can have that. The sprint must belong to this project; picking one from another is refused.

Linked columns

You can link a single column from another board so its content is visible alongside your own work — including boards in other projects you have read access to, which is handy when each project has just one board. Click Link a column above the board and pick a source column; the picker groups columns by project · board. The linked column appears on the right of your board, with a linked-column glyph in its header; hover it to read which project, board and column it is linked to. Use the × beside the glyph to remove it (this never affects the source).

Its cards are live tasks, not copies: open one and you can work on it exactly as far as the source project allows you to — the same panel, the same pin and shortcuts. Title, description, status, priority, due date, comments and attachments are all yours to edit from here, and the edit lands on the task itself.

The rest of the panel is shown but not editable: type, labels, parent, assignee, reviewer, release, sprint, the estimate and relations — the Relations tab shows what the task is linked to but offers no form, because a relation joins two tasks in the same project and this one belongs to another; it says so in place of the picker. Each of those is defined by a project — its people, its releases, its own list of labels, whether it estimates at all and in which unit — and this board only knows yours, which are not the ones that task can point at. (Priority is the exception that proves the rule: it stays editable, because the standard priorities mean the same thing in every project. Your project's custom priorities are not offered for a linked card, and if the task carries one of its own project's, you will see it named there.) Rather than offer you the wrong list, the panel shows what it knows and leaves them to be set where the task actually lives. A field the task has not set still reads None, because that is true wherever it lives; an estimate is shown in the unit the task carries it in, not the one your project uses. Labels are the one row that simply says so, because your project cannot see another's label assignments at all — an empty picker there would read as "no labels", which is a different claim. Status stays editable because the app asks the server which stages that task may move to. Only their place on the board belongs elsewhere too, so a linked card cannot be dragged into your own lanes or moved to the top of its lane; it follows the source board, which stays authoritative for where it sits. Change a linked task's status and it moves on the board it really lives on, and the linked column follows.

Backlog column

Toggle the backlog button above the board to show or hide the backlog as a separate column on the left of your board. This keeps unstarted work in view while you plan — drag an item from the backlog column straight into a lane to put it on the board, and drag a card out of a lane onto the backlog column to take it back off the board again (the same thing picking Backlog in the task panel's Status control does), which returns it to Backlog. The toggle is remembered per board on your device, so the backlog stays shown or hidden the way you left it.

Creating a task inline

Press N while the board is visible. An inline creation row appears in the first column — type a title and press Enter. Press Esc to cancel without creating. The same key does the same thing on the Backlog; anywhere else inside a project it opens the full Create task dialog instead, where you can set the other fields as you go.

Moving tasks

Drag a card to a different column to update its status. Or open the task panel and change the Status field.

Filtering

The board's toolbar carries a search box, which matches a card's title or its task ID. The full filter bar belongs to the Backlog and Task list views rather than the board: the Task list filters by status, type and priority, while the Backlog offers type and priority only — it holds unstarted work, so a status filter would have nothing to distinguish. There is no filtering by assignee or by label anywhere yet.

Every one of those filters takes more than one value. Each is a list of checkboxes behind a control that reads like the single choice it replaced: tick Planned and Done together, or bugs and tests at once, and a task matching any ticked value is shown. The control names the selection — the values themselves while one or two fit, a count past that — and carries a Clear; the menu stays open while you tick, and closes on Esc or a click outside. The Task list draws one group per selected status.

Active filters are encoded in the URL, so a filtered view is bookmarkable and shareable; a multiple selection travels as a comma list (?status=PLANNED,DONE). A value in the link that is not a real status is ignored — the view falls back to showing everything rather than refusing the link.

The search box on the board narrows the lanes as you type. It matches the card title and — see Finding a task by its ID — the task ID printed on the card.

Task cards

Each card shows its type badge and sequence number along the top, with the assignee avatar (and the pin button) at the top right, then the title. Below it sits a row of tags, each shown only when it applies: the priority dot, the effort estimate, the due date (red when past due), the release, and — if the task is assigned to a sprint — a green sprint tag. A row of the task's label chips follows when it carries any.

A card always shows the current state of its task: anything you change in the task panel — assignee, priority, type, due date, release, sprint, or the title — appears on the card straight away, with no need to reload the page.

Pinning a card

Hover a card and click the pin button to pin it. Pinned cards float to the top of their lane (and show a coloured left border) so important work stays in view. Click the pin again to unpin. Pinning needs write access and works on a task in any status, Done included. An archived card is never drawn on the board, so there is nothing there to pin or reorder — the API still allows it, the board simply has no such card.

Task panel

Click any task card or list row to open the slide-in task panel. The URL updates to include ?task=TASK_ID — reloading the page restores the panel exactly.

Clicking a value on the card takes you straight to it. A card's type chip, assignee avatar, priority dot, due date, release tag and sprint tag are each a shortcut: clicking one opens the panel and puts you on that field, on the Details tab, instead of leaving you to find it. Clicking anywhere else on the card opens the panel as usual. The shortcuts appear only where you have permission to edit the task — on a read-only project the same values are plain text.

Editing fields

Click any field in the Details tab to edit it inline. Changes save immediately. The title in the panel header is editable too: click it (or the pencil button next to it, or press E) to start editing, then Enter saves and Esc reverts. Press A to assign the task to yourself.

Status is also where a task sits on the board: setting it moves the task into the column that carries that status, so you can move work along without opening the board or dragging anything. A task that was not on the board yet joins it — that is how something you have actually started stops hiding in the backlog. There is no separate "board column" field; the two used to be able to disagree with each other. The one thing status will not do is commit a task to a sprint: a sprint's scope is a planning decision, so use the sprint field or the sprint board for that — and the two are the same decision: setting the sprint field puts the task's card on that sprint's board (in its To Do lane while it is still Planned), so committed work leaves the backlog and shows on the sprint board exactly as if it had been dragged there; clearing the sprint sends a Planned task back to the backlog and work already under way to the project board's matching lane. A task already committed to a sprint joins that sprint's board rather than the project board.

The Assignee and Reviewer lists offer the project's members plus your instance's global admins, who appear marked (admin) — they administer the instance without being members of any particular project. Someone who has since left the project, or whose account was disabled, stays visible on the tasks they still hold, marked (no longer a member).

Picking an admin who is not a member offers to add them to the project as a Viewer: administering the instance does not by itself grant access to a project, so without a membership they could not open the task. If you are not allowed to add members, you are told so and can ask someone who is. Super Admins reach every project already and are never asked about.

Created by records who created the task. It is set once, at creation, and cannot be edited afterwards.

Rich-text description

The task description is a rich-text editor with a formatting toolbar: Bold, Italic, Bullet list, Numbered list, Heading, Link to a web address, Link to a task or page, Code block, and Attach file. You can also use Ctrl/Cmd+B and Ctrl/Cmd+I for bold and italic. Edits are saved with the Save button below the editor; the status line shows whether you have unsaved changes.

Linking to another task or a page

The toolbar carries two link buttons, and the difference between them is where the link goes. Link to a web address — the box with the arrow leaving it — asks you for a URL. Link to a task or page — the chain — links to a record inside Octbase and finds it for you: type at least three characters and it lists the matching tasks and pages of this project as you type; move through them with the arrow keys and press Enter, or click one.

The glyphs say what the link does rather than decorating it: a web address opens in a new tab, so its icon is the one leaving the box, and a cross-reference stays in the tab you are in, so its icon is the plain chain. They are two buttons rather than one on purpose — the web one wants a URL you already have, the other one wants a record you would otherwise have to go and find in another tab first.

The link is labelled with the record's own name — a task arrives as its key and title, as in OCT-42 Ship the importer, and a page as its title. Selected text wins: highlight words before opening the picker and those words become the link instead, so "see the release checklist" stays the sentence you wrote. A cross-reference opens in the same tab, because it stays inside Octbase; only a link out to the web opens a new one.

Attach a file with the toolbar's Attach file button, or by dragging it onto the editor or pasting an image from the clipboard. Uploaded images can be inserted into the text, where they are shown as the picture itself while you write.

The editor can be made taller or shorter by dragging the handle in its bottom-right corner. The height you pick is kept for the rest of your session.

Attachments: what you can upload

Files can be attached to a task — from the Details tab's attachment sidebar, the description editor, or a comment — and to a page (see Files and diagrams on a page). The rules below apply everywhere, and to imported files too.

• Up to 10 MiB per file by default. Your administrator can raise or lower this for the whole installation, so a larger file may be accepted on your instance — the app tells you when one is refused.
• Which file types are accepted:
  • Images — PNG, JPEG, GIF, WebP
  • Documents — PDF; Word, Excel and PowerPoint; OpenDocument text, spreadsheet and presentation; RTF
  • Text — plain text, Markdown, CSV, and log files
  • Diagrams — draw.io files: the native .drawio document and its PNG export
  • Archives — ZIP
  Programs and scripts are rejected on purpose, and so is SVG, because an SVG can carry executable script. A file is checked by its actual content as well as its name, so renaming one does not get it past the check — and a file that merely calls itself .drawio without being one is judged as whatever it really is.
• A storage quota per person — the files you have uploaded, across every project, are capped at 512 MB by default (again adjustable by your administrator). When it is used up, further uploads are refused with a message asking you to delete attachments you no longer need. Deleting an attachment frees its space again.

Preview and images

The Details toolbar has a Preview button. It opens the description as it will be read rather than as it is written — formatted output, not the editor — and is the only place in Octbase that renders a description on its own.

The preview also gathers the task's files: an Images grid of thumbnails and an Attachments list of everything else. Clicking a thumbnail opens the full-size image viewer, which is the product's only one. Inside it, Esc closes and ← / → page between the task's images.

Quick actions

At the bottom of the Details tab sit the task-level actions:

• Backlog — is a status like the others: pick it in the Status control to take the task off the board and into the backlog. It is always offered, whether or not the task currently has a card.
• Archive / Reopen — archives an open task or reopens an archived one.
• Delete — permanently deletes the task after a confirmation dialog (unlike archiving, this cannot be undone).

Task statuses

Backlog → Planned → In Progress → In Review → Done, then Archived as a separate action. Every status is exactly one place: Backlog is the task with no board card, and each other status is a lane of the board its card belongs on — Planned is the To Do lane, Done the Done lane, so a task completed from the backlog shows up in the Done lane. A new task is Backlog; creating it from the board puts it in the Planned lane. The statuses a task can take are Backlog plus the lanes of the board its card belongs on — its sprint board while it is committed to a sprint, the project board otherwise — so the Status control offers exactly the stages that board can show, and a board without an In Review lane has no In Review status. Archived is never in that list: archiving is the Archive action (task panel, bulk bar, or the phone's task menu), never a status you set. Setting the status a task already has changes nothing. Done is an ordinary status: a completed task stays fully editable and moves to another stage like any other, because finishing work says it is complete, not that the record is sealed. Only an Archived task is frozen, and then narrowly. What freezes is what the task says — its title, description, type, effort estimate and due date, plus its status. That is the filed-away record, and it takes a Reopen to change.

Reopen is for finished work only — a task that is still open cannot be "reopened". It is how an Archived task comes back into play; a Done task needs no Reopen, since the Status control already takes it wherever you want it. It returns to the open status it held before it was closed (a task completed out of In Review reopens In Review), and its card goes to that lane; when that stage is no longer on its board, or nothing records where it came from, it lands in the Backlog — the one status every task can always take. The success message names where it went.

Everything else about an Archived task stays live, and deliberately so (all of it is live on a Done task too, along with everything above):

• Where it sits — parent, release, sprint and its place on the board — so a project can be reorganised into an epic/story hierarchy after the work is done, and completed work can be attributed to the sprint and release it belongs to. (Status itself is frozen on an archived task, and since a lane is a status, that includes dragging: an archived card can be reordered within its lane or sent back to the backlog, but moving it to another lane is refused until the task is reopened. A Done card drags anywhere.)
• Who holds it — assignee and reviewer can still be changed, so finished work can be handed over or corrected.
• Its priority — still editable, which is also what lets a finished blocker be downgraded.
• Its discussion — comments and replies stay open on a finished task, because a comment is a note about the record rather than part of it, and a retrospective remark is most likely to be written after the work is done. See Comments & mentions.

A Done task is auto-archived 30 days after it was completed so finished work clears off the board on its own; archived tasks are never deleted — they move to the Archive view, where any of them can be reopened. The task panel shows the split directly: on an Archived task the frozen editors are disabled while everything in the list above stays usable — so the way to change what an archived task says is Reopen, and only that. A Done task's panel is the ordinary one, description editor included. In the mobile companion app, tapping the status of an Archived task offers a single Reopen action (back to the status it was closed from) instead of the status list; a Done task gets the normal status list.

Types, hierarchy, and priorities

Types: Epic · Story · Task · Bug · Test · Subtask (plus the optional Theme and Initiative levels — see below)
Priorities: Low · Medium · High · Critical · Blocker (a project may define more)

Types form a strict hierarchy: epics contain stories, stories contain tasks, tasks contain subtasks. Set a task's place in it with the Parent field (task panel or create dialog): a subtask always needs a parent task, everything else may live without a parent, and the top level of the hierarchy never has one. The parent may be at any level above the task, not only the one directly above: a task can sit straight under an epic, without a story invented to hold it. The picker groups the options by type so you can see which level each candidate is at. The one exception is a subtask, whose parent must always be a task, a bug or a test — a subtask is the breakdown of one specific piece of work at that level. The panel lists a task's children on the Relations tab (only when it has any).

Bug and Test are not extra levels — they are peers of Task, sitting exactly where a task sits. So a bug hangs off a story just as a task does, a subtask can break down a bug, and a bug cannot be the parent of a task (peers share a level, and a parent has to be above the child). They carry effort estimates like a task, for the same reason: they are work someone has to do. Unlike Theme and Initiative they are always available and need no switching on.

Changing a task's Type in the panel keeps the hierarchy consistent for you: turning a task into a subtask first asks you to pick the parent task (the change is saved once you choose it in the Parent field), and changing to a type the current parent no longer fits under clears the parent automatically.

Per-project task settings (admins)

Project owners and admins can tailor the type hierarchy and the priority list for their project from the project's settings (the gear button in the top bar) → the Tasks & board tab.

• Extra hierarchy levels. Switch Theme and Initiative on to extend the hierarchy upward — the full chain becomes Theme → Initiative → Epic → Story → Task → Subtask. Each level is independent: with only Theme enabled, a theme sits directly above epics. Once a level is on, its type appears in the create dialog, filters and parent pickers. A level cannot be switched off while any task (or template) of that type still exists — convert or delete those first. Task templates are an API-only feature; there is no template manager in the app, so in practice it is the tasks that hold a level open.
• Custom priorities. Add your own priorities on top of the built-in five (for example URGENT). Names are stored in upper case and must not clash with a built-in. Custom priorities are then selectable everywhere the built-ins are — create dialog, task panel, filters and bulk actions. A custom priority cannot be deleted while a task or template still uses it.
• Effort estimation. Choose whether the project estimates effort, and in which unit: No estimation (the default), Story points, or Hours. See Effort estimation below.
• Board lanes. Cards per lane sets how many cards a board lane shows at once — 20 by default. See How many cards a lane shows below.

The settings are a page of their own, laid out like your personal settings — one card per group, side by side. Each change saves the moment you make it: there is no separate save step, and no Save button to hunt for. Go back to the board, backlog or any task view when you are done and it is already showing the change.

These settings belong to the project: they travel with a project export/import, and they do not affect any other project.

How many cards a lane shows

A board lane draws at most the project's Cards per lane setting — 20 unless changed — and that number is a wall, not a page. The cards past it are not drawn at all, and scrolling will not bring them in. A lane holding more than it draws ends in a line saying how many are not shown, beside a Search the board button that puts the caret in the board's search box. Searching lifts the wall for whatever matches, however deep it sits, so nothing is ever out of reach; moving a card you found to the top of its lane is how it comes back into the window for good. This keeps a board with a few hundred finished tasks in its Done lane quick to open and quick to drag on, and it keeps a lane readable rather than merely scrollable.

There is still some loading as you scroll, and it is worth knowing which is which. A lane fetches a page at a time, so a lane whose wall stands above what has been fetched fills in as you scroll towards it — that is when a Load N more cards button appears, naming what it can still draw. It never crosses the wall. Setting Cards per lane to 0 takes the wall away entirely: every card is drawn, arriving as you scroll, which is how boards behaved before the limit became a wall.

Nothing is hidden from the counts. The number beside a lane's name is always the whole lane, not the part currently drawn — so a lane reading 71 while showing twenty cards is behaving correctly. Nothing has left the lane, and searching, filtering and dragging still see every card. The one bounded lane is Done: it shows (and counts) work finished in the last 90 days, since older finished work is on its way to the Archive anyway — searching the board still finds it.

What you just did is always visible. A card that arrives in a lane without a position of its own — one you have just created, or one that moved because its status changed — is placed at the top of that lane, so it is inside the window whatever the lane's size. A card you drag lands exactly where you drop it, and if that is past the wall it is pinned visible anyway until you navigate away or change a filter: a move that showed nothing would read as a move that failed. Owners and admins can change the number under Project settings → Tasks & board → Board lanes (up to 500 — a higher number is refused with an error rather than quietly reduced).

Effort estimation

A project can give its tasks an effort estimate, measured either in story points or in hours. It is off by default: until an owner or admin picks a unit under Project settings → Tasks & board → Effort estimation, no estimate field appears anywhere in the project — no box on the task, no badge on the cards. A team that does not estimate never has to look at one.

Once a unit is on, every story, task, bug, test and subtask gains an estimate field in that unit — in the task panel and in the create dialog — and shows it as a small badge on board cards and backlog rows. In the story-points case the panel also offers Fibonacci shortcut chips (1 · 2 · 3 · 5 · 8 · 13 · 21); they are a convenience only — you can type any whole number from 0 to 100, so a team on a different scale is not forced onto Fibonacci. Hours accept up to two decimal places, from 0 to 1000; the input's arrows step in quarters, and any other two-decimal value can be typed. Clicking the chip that is already selected clears the estimate again.

• Empty is not zero. A task with no estimate is unestimated, which is a different statement from an estimate of 0 (“this costs nothing”). Both are allowed, and Octbase keeps them apart. Clear the field to go back to unestimated.
• Epics, initiatives and themes are not estimated. They are containers — their effort is whatever they contain. Octbase refuses an estimate on them, and refuses to change an already-estimated task into one of those types until you clear its estimate first.
• Switching units loses nothing. If you move a project from story points to hours, the points you already entered are kept — they are simply hidden while hours are the active unit, and they come back unchanged if you switch back. The same is true of switching estimation off entirely.
• Hours are an estimate, not a timesheet. This is what you expect the work to take. Octbase does not track logged or remaining time.
• Estimate as you create, or later. The Create task dialog carries the estimate field too, so work can be created already estimated instead of needing a second edit. Leave it empty and the task starts unestimated. The field appears there under the same rules as everywhere else — only when the project estimates, and only while the chosen type can carry an estimate, so switching the type to an epic takes the box away again.
• On the phone too. The mobile companion app (/m/) shows the estimate on its task cards and on the task detail, and lets you change it: tap the estimate row to get the Fibonacci shortcuts and a number field, or Clear estimate to go back to unestimated. Mobile's create form carries the field as well.

Changing the unit is recorded in the project's Activity, and changing a task's estimate in the task's. Estimates travel with a project export/import and are carried by Copy task (an API-only operation — there is no copy button in either app). Task templates do not carry a default estimate. Once a project estimates, the sprint burndown and velocity and the project statistics page can measure the estimate instead of counting tickets.

What the Create task dialog can set

Creating a task is not limited to a title: the dialog also carries description, type, priority, assignee, due date, parent, release, sprint and — where the project estimates — an estimate. Almost the whole record can be set as you create it, which is worth knowing before filing a task and then opening it to fill in the rest.

Backlog

The backlog lists all tasks that are not yet placed on the board (unstarted work), grouped by release. Use it for grooming and sprint planning. Press L to navigate here from inside a project. You can also show the same backlog as a column directly on the board — see Backlog column.

Setting a task's status moves it out of the backlog and into the matching board column, so the backlog keeps meaning what its name says rather than quietly accumulating work that is already underway. Picking Backlog in the task panel's Status control sends a task back, and taking a task off the board returns it to Backlog — the rule holds in both directions, so everything in the backlog is genuinely unstarted. Work that is already Done keeps that status wherever it sits.

Sorting. Click any column header to sort the whole backlog by that column — the release grouping collapses into one flat, sorted list. Click the same header again to reverse the direction (an ▲/▼ arrow marks the active column), and a third click clears the sort and returns to the release grouping. The Backlog and the Task list view remember their sort independently.

Searching. The search box above the list narrows it as you type, matching both the task title and its description.

Finding a task by its ID

Every task carries an ID made of the project abbreviation and a number — OCT-202 — shown on its board card, its backlog row, and at the top of its task panel. Typing that ID into the search box on the Backlog, the Task list, or the Board jumps straight to that one task, so an ID quoted in a chat message or a commit can be pasted back in to find the work it refers to.

• Both spellings work: the full ID (OCT-202, in any capitalisation, with an optional leading #) and the bare number (202).
• The ID has to be complete — OCT-20 finds task 20, not 202.
• An ID from a different project is not matched: searching ABC-202 inside project OCT returns nothing rather than the wrong task.
• The text search keeps running alongside it, so a query like 202 also lists tasks that mention 202 in their title or description.

Each view searches what it shows: the Backlog searches unstarted work, the Board searches the cards on its lanes, the Task list searches both. To search across projects — or for pages and projects too — use the global search (Ctrl+K), described under Search.

Task list view

The task list is a tabular alternative to the Kanban board — every task in the project, grouped by status, with each group showing its first 100 rows and a Load N more cards control for the rest (it names the number held back, and it says cards here as well as on the board) (see How many rows a group shows). It is useful for quickly scanning status across all work or applying bulk changes to a large set of tasks.

Use the filter bar above the table to narrow by type, priority, or status. Filters are encoded in the URL the same way as the board — the view is bookmarkable. The search box next to them matches the title and description of a task, or its ID — see Finding a task by its ID. Text search starts at three characters (an ID of any length works); the backlog's search has no such minimum.

Sorting. Click any column header to sort the whole list by that column — the status grouping collapses into one flat, sorted list, and the sort is applied across every task in the project, not only the rows currently drawn. Click the same header again to reverse the direction (an ▲/▼ arrow marks the active column), and a third click clears the sort and returns to the status grouping. Each column sorts by what it means rather than alphabetically: type follows the hierarchy, status the workflow order, priority its rank. A row with nothing in the sorted column — no assignee, no due date — sorts last whichever direction you choose, because it is missing a value rather than holding a small one.

How many rows a group shows

Each status group draws its first 100 rows, with a Load N more cards button under the group when it holds more — it names how many are held back. Each press adds another hundred to that group and leaves the other groups where they are, up to 1,000 rows per group — past that the button gives way to a note saying what is shown and that narrowing the search or filters is the way to the rest. A project with thousands of tasks therefore opens as quickly as a small one, because only the first hundred of each group is fetched.

The counts are the truth, the rows are a page of it. A header reading In Progress 120 above twelve rows is telling you about the group, not about what is drawn — exactly as a board lane's badge does. Nothing has been hidden from filtering or searching by being undrawn: those are answered by the server across the whole group, not by the rows on screen. Bulk actions, though, act on rows you can select, and you can only select rows that are drawn — load a group out before selecting all of it.

Changing a filter, typing in the search box or re-sorting re-reads the list, and the groups go back to their first hundred — the rows you had expanded belonged to the previous question. Sorting by a column also collapses the status grouping into one flat, sorted list, which has its own Load N more cards button.

The Backlog is not grouped this way — it groups by release, and a release group is short enough to read whole.

Select rows with their checkboxes to use bulk actions across many tasks at once. Each row also has a delete button (shown only if your role permits it) to delete a single task after a confirmation. A task that still has subtasks cannot be deleted directly — delete or detach its subtasks first, and the app tells you when this is why.

Mindmap

The Mindmap entry in the project sidebar renders the project's open tasks — everything that is not finished, backlog work included — as a left-to-right map: the project at the root, then epics → user stories → tasks → subtasks (preceded by themes and initiatives in a project that has switched those levels on). It gives you a one-screen picture of how the work hangs together. Click any node to open its task panel; double-click a node to fold or unfold its children — a folded node shows a +N badge with the number of hidden children. Folding is a view setting only and lasts until you leave the app.

The hierarchy follows each task's Parent field: a story nests under its epic, a task under its story, a subtask under its task.

Re-parent by dragging. Drag a node onto another node to make it that task's child, or onto the project node at the root to detach it from its parent — the pointer turns into a grab hand over a node that can be dragged. A drop the type rules forbid is refused rather than silently ignored, and the app names the rule that stopped it: a node cannot go under one whose type does not sit above its own, and no task can be moved under one of its own children. The synthetic branches (Stories without epic, Tasks without parent) are labels rather than tasks, so they are not drop targets; drop onto the project root instead to clear a parent.

Every line on the map is one thing: parent and child. Task relations — relates-to, blocks, duplicates — are deliberately not drawn here, because they do not follow the left-to-right hierarchy the layout is built from and an edge that cuts across it makes the map harder to read rather than richer. They live on the task's Relations tab, which lists them in both directions and draws its own dependency map.

Labels

A label is a free-form tag a task can carry — needs-design, customer-reported, whatever vocabulary your team already uses. Labels belong to the project, so two teams' urgent stay separate.

Managing the label set

Open the project's ⚙ Project settings page and its Tasks & board tab; Labels is one of its cards. Add a label by typing a name (up to 40 characters) and picking one of eight colours — slate, red, amber, green, teal, blue, purple, pink. You pick a colour by name, not a hex value, so the label stays legible in all four themes. Names are unique per project, ignoring case: Backend and backend cannot both exist.

Each label can be renamed (the change reaches every task carrying it) and recoloured. Deleting a label removes it from every task that carries it, and there is no undo — the confirmation says as much.

Putting labels on tasks

The task panel has a Labels row of toggle chips: click one to attach it, click again to remove it. If the project has no labels yet, the row reads No labels defined yet, with labels linking straight to the Labels card in project settings (for readers allowed to open that tab). Attached labels appear as small coloured chips on board cards and backlog rows, so the tag is visible without opening the task.

Bulk actions

Select multiple tasks using the checkboxes in the Backlog and the task list — board cards carry no checkboxes, so selection lives in the list views, not on the board. A bulk action bar appears at the bottom to apply a change to all selected tasks at once.

Available bulk operations: set priority or assignee; set status — offered in the Task list only, since backlog work is unstarted and putting it on the board is its status move; Add to board, a single button offered in the Backlog that puts the selection onto the board's Planned lane (there is no per-column picker and no bulk move back to the backlog); archive; and delete (delete is only offered if your role permits it). Both archive and delete ask for confirmation first. Setting a status in bulk places the selection the same way the task panel does — each task lands in the column carrying that status.

Archived work is skipped: an Archived task in the selection keeps its status when you set a status in bulk, exactly as the task panel refuses to change it. Reopen it individually (its Reopen button) if you want it back in play. Done tasks are not skipped — they take a bulk status change like any other task, and their cards move with the batch. The other bulk operations — priority, assignee, archive — apply to finished tasks too, matching what the task panel allows on them.

The Assign to list offers the same people the task panel does: the project's members plus your instance's global admins, marked (admin).

Archive

The Archive view lists every task in the project that has the Archived status — both tasks you archived by hand and tasks Octbase archived automatically. Open it from the Archive entry in the project sidebar.

Click a task's title to open its panel. Use Reopen on any row to bring a task back to the open status it was closed from (else Backlog). Its card follows: a status the board can show puts the card on the matching lane — Planned lands in To Do — while a task archived out of the backlog reopens into the backlog with no card, because Backlog is what it was closed from.

Releases

A release is a long-horizon target that groups tasks into a shippable product increment. Press R from inside a project to open the Releases view.

Lifecycle

• Planned — work in progress toward this release
• Closed — all tasks done; the release has shipped

A release cannot be closed while it still has open tasks. Octbase refuses the close and says so — "This release still has open tasks. Finish or move them first." — but it does not list them; filter the task list by that release to find them.

Creating and managing a release

New release on the Releases view opens a dialog with three fields: a name, an optional goal (a sentence saying what this release is for — it shows on the release card and is the thing a reader scans), and an optional due date, which is what puts the release into the Dashboard's Upcoming releases list.

Each release card carries its own actions:

• Edit — change the name, goal or due date at any time, including after shipping.
• Ship release — closes it. Refused while any task on it is still open.
• Reopen — closing is not final. A shipped release can be reopened, and the activity log records the two as separate events, Release closed and Release reopened.
• Delete — removes the release record. The tasks survive; they simply stop naming a release.

Sprints

Sprints are time-boxed iterations (typically 1–2 weeks) used to execute toward a release step by step. Only one sprint can be Active per project at a time. Press S to open the Sprints view.

What a sprint records

New sprint asks for a name, an optional goal, a start and end date, and optionally the release this sprint feeds — the picker's first entry is Not linked to a release, so a team running sprints without releases is not forced into one.

Two guardrails apply when you pick the dates, both reported on screen rather than silently accepted:

• Sprints may not overlap. A range that touches an existing planned or active sprint's is refused — end dates count as inside the range, so a sprint starting on another's end date is an overlap. Completed sprints do not block anything.
• The end date must not precede the start date.

An existing sprint can be edited (same fields) and deleted. Deleting is not destructive to the work: its tasks return to the backlog, and the confirmation says so before you commit.

Sprint states

• Planned — created but not yet started; this is when you plan the scope by adding tasks to its board
• Active — currently running (shown with a blue left border on the card); the scope is locked
• Completed — finished; unfinished tasks are automatically moved back to the backlog and returned to Backlog

The sprint board

Every sprint gets its own sprint board the moment it is created (its lanes are copied from the project's default board). Open it from the Plan board / Open board button on the sprint card; the board's banner shows the sprint name and links back to the Sprints view. The sprint board exists from creation until the sprint is completed.

Planning the scope (before starting)

While a sprint is Planned, open its board and turn on the backlog column (toolbar toggle), then drag tasks from the backlog onto a lane. Dragging a task onto the sprint board adds it to the sprint. Plan all the work you intend to commit to before you start.

Starting and completing a sprint

Click Start sprint on any Planned sprint to activate it. Once a sprint is Active its scope is locked against additions: you can no longer drag new tasks onto its board (you'll see a "scope is locked" message), but tasks already in the sprint move freely between lanes. Removals stay possible: taking a card off a running sprint's board un-commits the task from the sprint and resets it to Backlog, back in the backlog. At the end of the iteration click Complete sprint — a confirmation dialog warns that any unfinished tasks will be moved back to the backlog. They return as Backlog, ready to be picked up again in a later sprint; the sprint's own result is recorded before that happens, so the numbers below are unaffected.

An archived task still counts, on both sides of the figure: archiving is a way of finishing, so an archived task in the sprint is counted as committed and as done.

Completing a sprint records its result as done / committed — for example 2/5 means 5 tasks were committed to the sprint and 2 were Done. It counts the tasks whose Sprint is this sprint, however they got there, and the completed sprint card keeps showing the figure even after the unfinished tasks return to the backlog. Archived tasks are left out of both halves.

Assigning tasks to a sprint

The primary way to add tasks is to drag them onto the sprint board while planning (above). You can also set a task's sprint directly from a task panel → Details tab → Sprint field; only Planned and Active sprints appear in the selector.

Sprint reports: burndown & velocity

Every Active or Completed sprint card has a Report button that expands two charts:

• Burndown — remaining work per calendar day of the sprint window against the ideal straight line to zero. For a running sprint, future days are blank and the current day updates live.
• Velocity — committed vs. completed figures for the project's last completed sprints (up to six), so you can see the throughput trend across iterations.

In a project that estimates in story points or hours, the panel gains a Tasks / Story points (or Tasks / Hours) switch and opens on the effort view: the burndown then falls by a task's estimate on the day it finishes rather than by one per ticket, so three 1-point chores and one 13-point epic no longer read the same. Committed tasks with no estimate weigh nothing, and the chart says how many there are rather than quietly under-reporting the commitment. Velocity switches to effort automatically once sprints have been completed under estimation; if the project changed its unit part-way through its history, velocity keeps counting tasks instead of adding points to hours.

Reports are a desktop feature; the mobile companion app does not include them.

Project statistics

The chart icon in the top bar, immediately left of the project-settings gear, opens the project's statistics page — the overview a project manager wants before a standup or a steering meeting. It is per project and read-only, and every project member can open it.

• Headline tiles — open tasks, in progress, finished in the last 30 days (against how many were created in the same window), overdue, and unassigned. Overdue and unassigned count open tasks only: a finished task that was late is history, not something to act on. Where a sprint is running (or has most recently finished) a further tile names it and reads done / committed with the days left in the iteration; where the project estimates, two more show the effort still remaining and how many tasks are still unestimated.
• Sprint burndown — the running sprint, or the most recently completed one when none is running, using effort wherever the project estimates.
• Throughput — how much finished in each of the last 8 weeks. A quiet week is a zero bar, not a missing one.
• Cycle time — how long a task took from creation to done, over the last 90 days. The median sits beside the average because one long-running straggler drags the average somewhere no real task lives.
• Distributions — tasks by status, tasks by type, and open work by priority (finished and archived tasks are left out of the priority chart: the point is what is still queued).
• Open work per person — how the open tasks are spread across the team, with the effort total per person where the project estimates, plus how many open tasks nobody owns.
• Velocity and releases — the velocity trend and the release plan: how many are open and closed, the next due date, and whether any open release is already past it.

Switch effort estimation on for the project (see Effort estimation) and the page adds an effort summary — remaining, done, and how many tasks are still unestimated — and measures the burndown and throughput in that unit. With estimation off, none of it appears and everything counts tasks.

Project activity

The project activity view shows a reverse-chronological event log for everything that has happened across the entire project — task changes, comments, page publishes, sprint transitions, and more.

Each entry shows the event type as an icon, the task it belongs to, a human-readable description, and — on the footer line — how long ago it happened followed by the exact date and time. Entries that relate to a task are clickable and open that task panel directly.

The heading states how many entries the whole log holds. The view loads the 50 most recent of them; Load older activity at the foot of the list fetches the next 50 and stops offering itself once you reach the end of the log.

This view and the administrator's audit log are the two chronological records in Octbase, and they are deliberately the same page: same heading with its entry count, same rows, same footer (the audit log alone keeps a narrower reading width). What the audit log adds is what only it has — a severity colour down the row, and a source IP address on the footer line.

Activity entries are purged automatically after a retention period (365 days by default; the operator can configure or disable this), so the log shows recent history rather than the project's full lifetime.

Comments & mentions

Add comments on any task from the Comments tab of the task panel — any task, including one that is already Done or Archived: an Archived task is frozen in what it says, never closed to discussion, and a Done task is not frozen at all (see Task statuses). The comment box has the same formatting toolbar as the task description, including Attach file — so a comment can carry a screenshot or a document. You can also drag a file onto the box or paste an image straight into it, and an inserted image is shown as the picture itself while you write. The same applies while editing an existing comment.

The comment box and the description editor both carry a drag handle in their bottom-right corner: pull it down to give a long comment more room. The size lasts for that editing session.

@mentions

Type @ followed by a team member's name to mention them. A dropdown suggests matching members. Mentioning someone creates an in-app notification and optionally sends them an email.

Replies

Use Reply on any comment to respond to it directly; replies are threaded underneath the comment they answer. You can edit or delete your own comments and replies — deleting a comment that has replies removes the whole thread beneath it.

A single comment holds up to 10,000 characters. It is a generous bound rather than a working limit — long enough for a review or a postmortem — but it is there, so a document that outgrows it belongs on a page the task can link to.

Notifications

The bell icon in the top bar shows your unread notification count. Click it to see the full list.

Notifications are delivered in-app and optionally by email. You can toggle per-type preferences (in-app / email / both) on your Settings page.

The panel has a Mark all read action at the top, which clears the unread badge in one step rather than one notification at a time.

Notification preferences

Notification preferences live on your Settings page (/#/settings), in the Notification preferences card. The page is a responsive grid, so which card sits beside which depends on the width of your window — look for the card by its name rather than by a position. Open the notification panel and click Preferences at the bottom to jump straight there. You choose — per notification kind — whether to receive in-app notifications, email notifications, both, or neither.

For each kind you can independently toggle In-App and Email delivery, and changes take effect immediately — with one exception: “Task you created or are assigned to was changed” is email-only, and its In-App cell shows an inert dash rather than a switch.

Real-time updates

The dot in the top bar reports whether your session is healthy, and has three states: Live, Connecting… (only while the first check is in flight) and Disconnected. It is not a readout of the live-updates stream: if that stream drops it reconnects on its own, backing off to at most 30 seconds between attempts, and the dot stays as it was throughout. Only the first means you are seeing changes as they happen; the other two mean reload before trusting the screen.

Octbase uses Server-Sent Events (SSE) to push live updates to all users viewing the same project. When a teammate moves a task or changes a status, a “This content has changed since you opened it.” banner appears within about a second, with a Reload button. It is shown on the Board, the Sprint board, Backlog, Tasks, Calendar and Statistics views. A new comment raises it only where you would read it — on a task panel you have open — rather than on the whole board, and your own changes never raise it.

The page deliberately does not redraw on its own: a view that repaints while you are reading it costs you your scroll position, your selection, and your place in a half-finished edit. You reload when it suits you.

The reconnect is exponential — 1 s → 2 s → 4 s, capped at 30 s between attempts — so a brief network blip recovers on its own without you doing anything.

When two people edit the same thing

Octbase does not lock anything, so two people can open the same task or page at once. When the one who saves second would overwrite the first, Octbase stops and asks instead of picking a winner. Your text is never discarded to make room — it stays in the editor in every case below.

A page

Saving a page someone else has published in the meantime raises a Page changed by someone else dialog with two choices:

• Discard my edits and load latest — abandon your version and start again from theirs.
• Overwrite with my version — publish yours on top; theirs stays in the page's revision history.

A task description

Saving a description that changed underneath you reports the conflict and keeps your text in the editor: review what the task says now, then save again. The description is the only field that keeps your draft. A conflict on any other field reloads the panel with the current values, so copy anything long before you retry.

Pages

Each project has a built-in wiki. Pages are written in AsciiDoc with a live split-pane preview that updates as you type (debounced 300 ms). Press P to open the Pages view, and use the Syntax help button in the editor for a quick reference.

Supported AsciiDoc

The editor renders genuine AsciiDoc: section titles (= through ======), bold *text*, italic _text_, monospace `text`, links (https://site[label], and link:target[label] where target is itself an https, http or mailto URL — a relative target is left as plain text) and bare URLs, unordered (*/-) and ordered (.) lists with nesting, code blocks (---- or [source,lang]), block quotes (____), admonitions (NOTE:, TIP:, WARNING:, IMPORTANT:, CAUTION:), tables (|===), and relative block images (image::/path[alt]). TASK-<id> mentions become links to the task, and the labelled link:task:<id>[label] and link:page:<id>[label] macros link to a task or to another page under a name you choose — see Cross-references.

For safety, raw-HTML passthrough and external image sources are intentionally not supported, and all rendered output is sanitised on the server, so a page can never run injected scripts. Note that the bold marker is a single * as in standard AsciiDoc (the older Markdown-style **double** form now renders as ordinary bold via AsciiDoc's unconstrained marker).

Page statuses

• Draft — work in progress, not yet visible to readers (a project viewer neither lists nor opens it)
• Published · unpublished changes — a draft saved on top of a published page: readers keep seeing the published version until you publish again; the sidebar shows a hollow dot
• Published — visible to all project members; each publish creates a revision snapshot
• Archived — left out of the page list, and read-only: editing one is refused until it is taken back out of the archive. Archiving and restoring are API-only today (POST /pages/{id}/archive and /unarchive); there is no control for either on the page screen yet. A restored page returns as a draft, so what readers see is a decision you make again rather than one inherited from before

Where the state is shown. As a badge beside the title on the read view; as a dot in the page tree (faint for a draft, solid once published, hollow while a draft sits on top of a published page); and in the editor, above the text, where the same badge is followed by a line saying what that state means for readers. The editor matters most: a draft is only invisible to other people, so the person writing it never sees the effect and has to be told.

Finding a page

The page list has its own search box — Search pages… — which matches a page's title or its content and narrows the list as you type. It is scoped to this project's pages; the global search covers pages across every project you can see.

An open page has an address of its own, so it can be sent to someone, bookmarked, or reloaded without losing your place: the URL carries ?page= and the page's slug. Every way into a page writes it — the page tree, the Dashboard's recent pages, a search result, creating one — and opening such a link cold goes straight to that page. A link to a page that has been deleted, or to one in a project you are not in, says so where the page would be rather than dropping you on an empty Pages view.

Table of contents

When a published page has three or more headings, a sticky TOC sidebar is generated automatically on the read view.

Revision history

Every publish action creates an immutable revision, recording who changed what and when. There is no revisions panel in the app yet — the history is written on every publish and is readable through the API, but nothing surfaces it on screen.

Files and diagrams on a page

A page carries the documents it describes. Open a page and use Add files under the page body, or drop files straight onto that area. The same size cap, type rules and personal storage quota apply as for task attachments — see Attachments: what you can upload.

An attached file can be referenced from the page text with three macros. The attachment list offers an insert action that writes the right one at the cursor, so you rarely need to type them:

• image::attachment:<id>[alt] — shows an attached image in the page
• diagram::attachment:<id>[title] — shows an attached draw.io diagram
• link:attachment:<id>[label] — links to any attached file for download

A macro only resolves against the page it is written on: a page cannot display another page's files.

draw.io diagrams

Octbase displays draw.io diagrams but does not include the draw.io editor. Draw in draw.io, attach the result here, and the page shows it.

Which export you attach decides what happens:

• The PNG export (File → Export as → PNG with Include a copy of my diagram ticked) is the one to use. It renders in the page as a picture, and it is still a draw.io document — download it later, open it in draw.io, edit, and attach it again.
• The native .drawio file is accepted and stored, and is marked with a Diagram badge, but there is no picture inside it to show — the page offers it as a download instead. Attach the PNG export as well if you want the diagram visible.
• The SVG export is not accepted, for the same reason SVG is rejected everywhere else.

Cross-references

A page can link to a task or to another page. The Cross-reference button above the editor is the way in: type at least three characters, see the matching tasks and pages of this project, move through them with the arrow keys and press Enter. It writes the macro at the cursor, labelled with the record's own name — a task as its key and title, as in OCT-42 Ship the importer, a page as its title. Select text in the editor first and your own words become the label instead.

Three spellings render, and the button writes the first two:

• link:task:<id>[label] — a link to a task, under any label
• link:page:<id>[label] — a link to another page
• TASK-<id> — the original bare form. Still supported and still rendered, but it has nowhere to put a name, so the reader sees the raw ID; it is what pages written before the button contain, and what you get by pasting an ID out of a task's URL.

The <id> is the record's full ID, as in TASK-00000000-0000-0000-0000-000000000abc — which is why the picker is worth using rather than typing one out. A label may contain square brackets (a task really can be called Fix [urgent] importer); the button escapes them for you, and by hand you write \[ and \].

On publish, the task references on a page are stored — either task spelling counts — which is what lets an export and import re-link them onto the new task IDs. Only tasks of the page's own project are recorded, which is why the picker searches that project alone: a link to another project's task still renders, but nothing tracks it.

The reverse direction is not available yet: a task does not list the pages that mention it, in the panel or anywhere else. A task description can link to a page — see Linking to another task or a page — but that is a link you write, not a list Octbase keeps for you.

Repository connections

Connect a Git repository to a project so that you can create branches and open pull/merge requests for tasks directly from Octbase, with PR status shown on task panels. Supported providers: GitHub, GitLab, and Bitbucket. You can connect more than one repository to a project — useful when a project spans multiple repos (e.g. a separate frontend and backend) — and choose which one to branch in per task.

Adding a repository connection

Open your project, click the gear in the top bar and open the Integrations tab. The form has five labelled fields, in this order:

• Display name — a friendly label shown in the UI, like the Backend API the empty field shows as its example
• Repository URL — the full HTTPS clone URL, in the shape of the https://github.com/org/repo example the empty field shows
• Provider — GitHub, GitLab, or Bitbucket. A demo instance also offers FAKE_GITLAB, an offline stand-in that makes no outbound requests.
• Default branch — typically main or master. Left empty it is main, which the empty field shows as its example.
• Access token (optional) — a Personal Access Token (PAT) for the provider, used to create branches and pull/merge requests on your behalf (see required permissions below). The token is encrypted at rest and never shown again.

Click Add repository. When a token is supplied, Octbase validates the repository against the provider on save and adopts its real default branch. The connection then appears in the list and is immediately available in the Branches tab of any task panel in this project.

Access token permissions

The token needs to read the repository, create branches, and open pull/merge requests — the per-provider settings that grant those are listed below.

What is actually checked when you save. Octbase reads the repository with the token you supplied, and a token that cannot even do that is rejected with "SCM provider rejected the access token" (the provider's own explanation is appended when it gives one). Whether the same token may write is a separate question, and how much of it the provider will answer on that one call differs:

• GitHub — answered. The repository reply states whether this token may push, so a read-only token is refused on save with "The access token can read this repository but not write to it".
• GitLab — answered only in part. A role below Developer cannot push and is refused on save. At Developer or above, the token's own scopes are not visible to Octbase, so a read_api token saves and fails later.
• Bitbucket — not answered. Bitbucket does not report a repository access token's permissions to the token itself, so a read-only token saves cleanly.

Where write access cannot be proven at save, the first failure arrives when someone clicks Link branch or opens a pull request, and it carries the provider's own words — GitHub's "Resource not accessible by personal access token", for instance. If that appears, the connection is fine and the token is not: issue one with write access and put it on the connection — today that means removing the connection and adding it again with the new token (the form does not yet offer replacing a saved token), or a REST call (PATCH /api/v1/repository-connections/{id} with accessToken), which keeps the connection and its linked branches in place.

GitHub — create a token under Settings → Developer settings → Personal access tokens (see GitHub's guide: Managing your personal access tokens):

• Classic token — enable the repo scope (or public_repo for public repositories only).
• Fine-grained token — grant access to the specific repository, then set Contents: Read and write (branches) and Pull requests: Read and write (the mandatory Metadata: Read-only is selected automatically).
• If the repository belongs to an organization with SAML SSO enabled, authorize the token for that organization (Configure SSO), or GitHub returns a 403.

GitLab — create a project or personal access token with the api scope.

Bitbucket — create an access token with Repositories: Read & Write and Pull requests: Read & Write.

Creating a branch for a task

Open the task panel → Branches tab. Select the repository, choose a branch type (feature / bugfix / hotfix / release), and enter the branch name. Octbase suggests a name based on the task type and title — for example feature/dp-42-improve-search. Click Link branch and Octbase creates the branch on the remote (from the repository's default branch) and records it on the task. Use the copy button if you instead just want the suggested name for your terminal.

A task carries one branch per repository. Once it branches in a repository, that repository drops out of the picker — so a task that spans a frontend and a backend repo can hold one branch in each, but not two in the same one. Unlink the existing branch (below) if you need to point the task at a different one.

And a branch name is linked once, across the whole repository. If the name is already recorded against another task you are told “This branch is already linked to a task. Open that task and unlink it there, or pick another branch name.” — so a branch always names the one piece of work it belongs to.

Opening a pull request

Once a branch is linked, use Open PR on the branch to open a pull request (GitHub/Bitbucket) or merge request (GitLab) from that branch into the repository's default branch. The PR link and status then appear on the task.

One open pull request per branch. While the recorded PR is still open the Open PR button is not offered, so the branch cannot end up with a second PR that orphans the first. Once it is merged or declined the button returns and the branch may have another.

PR status

Once a webhook is configured (see below), PR status updates appear automatically on the task panel: open, merged, or declined, with a direct link to the PR in your provider.

Unlinking a branch

The button beside a linked branch is Unlink branch (German UI: Verknüpfung aufheben). It removes Octbase's record of the branch and nothing else: the branch, its commits and any pull request stay exactly as they are in your provider. The confirmation says so — “… will no longer be linked to this task. The branch itself stays in the repository — this only removes the link.”

Unlinking is how a wrong link is undone, and it is recorded in the project's activity log, so a branch that disappears from a task can be traced. Because a branch may be linked only once, it is also what frees a branch name for the task that should have had it.

Administrator setup

Two server-side settings are required before repository connections work:

• Token encryption key — set OCTBASE_SCM_ENC_KEY to a 32-byte key (base64- or hex-encoded; generate with openssl rand -base64 32). Access tokens are encrypted at rest with this key, so adding a connection fails with "access token encryption is not configured" until it is set. Changing it is a rotation, not a one-way door: set OCTBASE_SCM_ENC_KEY_OLD to the previous key for the duration of the changeover and stored tokens are read with either, so nothing has to be re-added. See Rotating an encryption key in the operations guide.
• OAuth apps (optional, only for Connect with OAuth) — register an OAuth app with each provider and set OCTBASE_OAUTH_<PROVIDER>_CLIENT_ID / _CLIENT_SECRET (e.g. OCTBASE_OAUTH_GITHUB_CLIENT_ID) plus OCTBASE_OAUTH_REDIRECT_BASE (the public origin that serves the API). The callback URL to register with the provider is:

<OCTBASE_OAUTH_REDIRECT_BASE>/api/v1/oauth/<github|gitlab|bitbucket>/callback

It must match the OAuth app's registered callback exactly. The default authorize/token endpoints and scopes are GitHub's, GitLab's, and Bitbucket's public ones; for self-hosted instances override them with OCTBASE_OAUTH_<PROVIDER>_AUTH_URL / _TOKEN_URL / _SCOPE.

Webhooks

Configure a webhook in your Git provider to send push and PR events to Octbase. The receiver endpoints are:

• POST /api/v1/webhooks/bitbucket
• POST /api/v1/webhooks/github
• POST /api/v1/webhooks/gitlab

Enter a shared secret in your provider's webhook settings and set the matching environment variable on the server — OCTBASE_WEBHOOK_SECRET_BITBUCKET, OCTBASE_WEBHOOK_SECRET_GITHUB or OCTBASE_WEBHOOK_SECRET_GITLAB. Ask your administrator to configure these. Until the variable for a provider is set, that endpoint refuses every delivery.

GitHub and Bitbucket authenticate the delivery with an HMAC-SHA256 signature over the request body. GitLab does not sign the body — it sends the secret itself in the X-Gitlab-Token header — so Octbase compares that instead. That is GitLab's own scheme, not a weaker setting on the Octbase side. Point the GitLab hook at the Merge request events trigger.

Auto-close on merge

A repository connection with auto-close on merge enabled completes the linked task when its pull request is merged. The completion follows the same rules as closing the task yourself: a task with an open Blocker task below it is left open (resolve the blocker, then complete the task by hand), an already finished task is never reopened or re-closed, the card moves into the board's Done lane, and the change appears in the project's Activity view without an actor — it was the merge, not a person.

Roles & permissions

Octbase has two layers of roles: a global role (set once per user for the whole platform) and a project role (set per project membership). Authorization is enforced server-side on every request.

Global roles

Project roles

Every project always has at least one Owner. When a project is created, the creator becomes its owner. Ownership can be transferred to another member by first promoting them to Owner (only an existing owner can do this), then optionally stepping down.

Admin panel

The admin panel (/#/admin) is visible only to Super Admin users. It provides:

• User management — list all users, change global role, enable/disable accounts, delete users. Disabling a user immediately invalidates all their active sessions.
• Audit log (/#/admin/audit-logs) — immutable record of all privileged actions: logins, user changes, project deletes, and more.
• Invitations are not here — there is no invitations screen in the admin panel. They are issued from a project's Members settings; see Inviting users.

Creating a user directly

New user on the user list creates an account without an invitation — email, display name, a starting password, and a global role of User, Admin or Guest. The password must meet the same 12-character minimum as any other.

You do not have to pass that password on. The new account is emailed the same set your password screen a reset uses, so the one you typed never has to reach its owner by chat or on paper — a password two people know is not a password. The link is single-use and valid for 7 days, not the 60 minutes a self-service reset gets: the recipient did not ask for it and may not read that mailbox today, so it is the invitation window instead. Spending it ends every session of that account, as a reset always does.

The mail is best-effort and never fails the creation: if it cannot be sent, the account still exists and the administrator still has the password to hand over — and Forgot password? mints the same link again on demand.

This is the second way into an installation, alongside invitations, and it is the one to use when you are setting an account up on someone's behalf rather than asking them to accept a link. A user who has been invited but has not yet accepted shows the status Invited in the list, and the status filter offers it.

User management

The user list page opens with a row of statistics cards showing total users, active users, disabled accounts, and a breakdown by global role (Super Admin / Admin). Use the search box and the role / status filter dropdowns to narrow the list. For each user you can:

• Edit their display name, email address, or global role — after an email change, a security notice is sent to the previous address so a hijacked change doesn't go unnoticed
• Enable or disable their account (disabling immediately invalidates all active sessions)
• Delete the account

Audit log

The audit log at /#/admin/audit-logs is an immutable, append-only record of privileged actions. Each entry shows the actor (user or system), the target, the action, any metadata such as changed field values, and a footer line carrying how long ago it happened, the exact date and time, and the source IP address.

Filter by action type using the dropdown to focus on a specific category (e.g. all Failed sign-in events, or all Project deleted events). The log reads newest first, in the same layout as a project's Activity view — the same heading with its entry count, the same rows and the same footer, so the two records in this app read as one thing (only the width differs: the audit log keeps the administration pages' narrower measure); Load older entries at the foot of the list adds the next page below what you are already reading, and disappears once you reach the end. Changing the filter starts the feed again from the newest matching entry.

Entries that matter for security stand out without being read: a failed login, a disabled account, a disabled second factor, a failed password change and an account whose sessions were all revoked are marked in amber, and a deleted user, a deleted project or a replayed refresh token in red.

For data-protection reasons, audit entries are purged automatically after a retention period (365 days by default; the operator can configure or disable this).

Inviting users

There is no self-registration. Admin and Super Admin users invite teammates by email. A project's Owners and Admins can also invite users directly to their project.

1. Open a project's Members settings as its Owner or Admin and use Invite a teammate. This is the only invitation screen in the app — the admin panel has no invitations section.
2. Enter the invitee's email address and optionally select a project and role. Only an existing Owner can invite someone directly as an Owner.
3. Octbase generates an accept link and emails the invitation to the invitee automatically (when SMTP is configured on the server). The link is copied to your clipboard so you can share it manually — it is not shown on screen, so paste it somewhere before you copy anything else.
4. The invitee opens the link, enters their name and a password, and their account is created and they are signed in immediately.

Adding an existing user (Super Admin)

A Super Admin can add someone who already has an Octbase account straight into a project — no invitation email and no accept step. Open the project's Members settings; under Add an existing user, pick the account, choose a project role, and click Add to project. The user becomes a member immediately. Accounts that are already members, and disabled accounts, are not offered in the list.

Personal settings

The Settings page collects the preferences that belong to you rather than to a project. Open it with the user icon in the top bar's right corner, or navigate to /#/settings. (The gear icon next to it is different — it opens the settings of the project you are in.)

Language and theme are saved to your account, not just to the browser — sign in on another device or browser and your choices follow you. Changing the language or theme from the top-bar switchers keeps the account preference in sync automatically.

Changing your password

You can change your own password at any time from the Settings page — the Password card (the grid reflows with the window, so find it by name). You do not need an administrator, and you do not need to go through the forgotten-password email.

1. Open Settings and find the Password panel.
2. Enter your current password, then the new one twice.
3. Click Change password.

The new password must meet the same rules as any other: at least 12 characters, and not one of the obviously common ones (see Password requirements). It also has to differ from your current one — re-entering the same password is refused rather than quietly accepted. Your current password is checked on the server, so a typo there fails the change and nothing else happens: it does not sign you out.

A successful change signs out every one of your other sessions — other browsers, other devices, the phone — so a password you are changing because it may have leaked stops being useful immediately. You stay signed in on the device you changed it from.

Both a successful change and a failed attempt are recorded in the instance's audit log, so an administrator can see that an account's password moved — and can spot someone repeatedly guessing at it.

The mobile companion app has the same panel on its own Settings page.

Two-factor authentication

Two-factor authentication (2FA) adds an extra layer of security to your account: after entering your password, you also enter a 6-digit time-based code from an authenticator app (Google Authenticator, 1Password, Authy, …). Each user enables it for their own account on the Settings page.

Enabling 2FA

1. Open Settings and click Enable two-factor authentication.
2. A QR code and a setup key are shown. Scan the QR code with your authenticator app, or add the key manually as a new account (use the copy button to copy it).
3. Enter the 6-digit code your app now generates and click Confirm and enable.
4. Octbase shows your recovery codes — save them somewhere safe (there is a copy button). They are shown only this once. Confirm with I've saved these codes.

From then on, every sign-in asks for a code from your authenticator app after the password step.

Recovery codes

Recovery codes are your fallback if you lose access to your authenticator app. At the sign-in verification step, enter a recovery code instead of the 6-digit code. Each code works exactly once; letter case and the hyphen don't matter when typing one in.

Use Regenerate recovery codes on the Settings page to get a fresh set at any time — this invalidates all previous codes.

Disabling 2FA

Click Disable two-factor authentication on the Settings page. Disabling — like regenerating recovery codes — always requires you to re-prove your identity first: enter your current password, or a code from your authenticator app / a recovery code.

Administrator setup

MFA enrollment requires one server-side setting: OCTBASE_MFA_ENC_KEY, a 32-byte key (base64- or hex-encoded; generate with openssl rand -base64 32) used to encrypt users' authenticator secrets at rest. It is deliberately separate from the SCM token key. Until it is set, users cannot enable two-factor authentication. Changing it is a rotation as well: OCTBASE_MFA_ENC_KEY_OLD holds the previous key for the changeover, so nobody has to re-enroll. See Rotating an encryption key in the operations guide.

Requiring 2FA

Administrators can make two-factor authentication mandatory with the server-side setting OCTBASE_REQUIRE_MFA: off (default — 2FA stays voluntary), admins (required for Admin and Super Admin accounts), or all (required for everyone). When an account in scope signs in without 2FA enabled, the sign-in is interrupted by a forced-enrollment step: the user scans the QR code, saves their recovery codes, and confirms a code from their authenticator app before continuing. Users who already have 2FA enabled just see the normal verification step.

Appearance & themes

Octbase ships several colour themes. Click the theme button in the top bar to cycle through them, or pick one directly on the Settings page; your choice is saved to your account and follows you across devices.

The octopus mascot sits in the bottom-right corner of the desktop app in every theme, not just Octopus. It is now drawn in the colour of the theme you are in — deep green on Light, mint on Dark, coral on Octopus — where it used to be the same black drawing everywhere, merely flipped to white so it stayed visible in the dark. It is decorative only: it never covers a control and never reacts to clicks. It doesn't appear on phone screens, where the space is needed.

The theme reaches past the page. Your choice also colours the tab icon, the browser toolbar tint on a phone, and the controls the browser draws rather than Octbase — scrollbars, dropdown menus, date pickers — so a dark page no longer comes with light scrollbars. On System all of it follows your operating system's Light/Dark setting and changes the moment you change that setting, with no reload; pin a theme and the pinned one wins everywhere, whatever the OS is set to.

Themes change only how the interface looks; they have no effect on your data or on what other users see. The mobile companion app supports all the same themes, including Octopus (without the corner mascot, to save space on phone screens).

Language

Octbase ships with the interface available in English and German. Use the language switcher in the top bar — or the Settings page — to change the display language. The choice is saved to your account, so it follows you across devices and browsers.

Changing the language affects all UI labels, buttons, and messages immediately. Content created by users (task titles, comments, page text) is not translated.

Vocabulary: agile or classic

Not every team speaks Scrum. On the Settings page, next to language and theme, Vocabulary switches the words the interface uses between Agile (the default) and Classic project management. Like the language, the choice is saved to your account and follows you across devices — and it is yours alone, so a colleague on the same project can keep the agile wording.

Only the labels change. Your projects, tasks, boards and reports are untouched, nothing is converted or migrated, and the API keeps its field names — so integrations and exports are unaffected. Switching back and forth costs nothing.

Two chart names stay as they are in both vocabularies: burndown and velocity. They are agile measurements rather than agile names for something classic, so translating them would invent a term rather than replace one. The words around them still follow your vocabulary — in classic wording a sprint burndown is a phase burndown, and velocity is counted in effort points.

The mobile app

Octbase ships a phone-first companion app alongside the desktop one. It is not a separate product or a separate login — the same account, the same projects, the same data, drawn for a small screen and thumbs instead of a mouse.

Getting to it

You normally don't have to do anything: open Octbase on a phone and you land on the mobile app automatically. The front door recognises a phone browser and sends it to /m/; open the same address on a laptop and you get the desktop app as usual. If you ever want it explicitly, add /m/ to your Octbase address.

What it covers

On a task you can change status, priority, assignee and the effort estimate, move the card to another board column, and write comments. Signing in, accepting an invitation, resetting a forgotten password and the two-factor verification step all work on the phone too, so a new teammate can be onboarded entirely from one.

What it deliberately leaves out

The mobile app is for keeping work moving, not for planning it. These live on the desktop only:

• Releases and sprints, including the burndown and velocity reports (the Dashboard's Upcoming releases shortlist is still shown)
• Pages, the mindmap, project statistics, the Archive and the project activity log. Following a cross-reference to a page on the phone says the section is on desktop and offers to open that page there, rather than dropping you on My work; a cross-reference to a task opens on the phone as normal.
• Repository connections, project members, and the admin panel
• Editing a task's title or description — a rich-text editor is not a good experience on a phone, so those are written and changed on the desktop; the phone shows them read-only, and the task menu names the hand-off (Edit on desktop)
• Bulk actions, linked columns and the import/export tools

The phone's task list loads 50 rows at a time with a Load more button beneath them, and its filters are applied to the whole list rather than to the rows already loaded — so narrowing by priority or type (the phone has no status filter) finds work that had not been drawn yet. Loading stops at 500 rows, after which the list asks you to narrow the filters instead. The count on the button is what is still held back, not a guess.

Everything the mobile app does show follows the same rules as the desktop — your role, the freeze on archived tasks, the blocker guard and the warning before closing a container over live work all behave identically. It also honours your language and theme, Octopus included; only the decorative corner mascot is dropped, to save space.

Keyboard shortcuts

Press ? at any time to show the full shortcut overlay inside the app.

The letters below are bare keys. Holding Ctrl, Cmd or Alt leaves the keystroke to the browser, so Ctrl+R reloads the page and Ctrl+P prints it, as they do anywhere else. Ctrl+K is the one deliberate combination.

Navigation

Task actions

General

Search

Octbase has two ways to search across everything you can see. They run the same search — the difference is the surface, not the depth:

• Command palette (Ctrl+K) — fast, keyboard-driven, stays in context. Best for quickly jumping to a known task or page.
• Search page (/#/search) — the same results on a full screen, at a URL you can bookmark or paste to a teammate.

Search terms need at least three characters — one or two return no results rather than matching half the project. The threshold is counted in bytes, so a word in a language that spends more than one byte per letter reaches it sooner: Öl is two letters and three bytes, and searches.

Command palette

Press Ctrl+K (or Cmd+K on Mac) from any view to open the command palette.

Type three or more characters to search across tasks, pages, and projects in one box. Navigate results with ↑ ↓ and open with Enter. Press Esc to close.

Search page

On the search page, type a term and press Enter or click Search. Results are grouped into Tasks, Pages, and Projects. Click any result to navigate directly to it.

Bookmarkable URLs

Every view in Octbase has a stable, shareable URL. Filter state and the open task panel are encoded in the URL hash so you can bookmark or share an exact state.

Copy the URL from the browser address bar to share an exact view with a team member — filters and open panels are preserved. A column sort is not part of the URL and is not remembered: it lasts until you reload the page.

Small things worth knowing

• The sidebar collapses to a strip of icons — see Collapsing the sidebar below.
• Skip to main content. The first thing Tab reaches on any screen is a skip link that jumps past the navigation, so keyboard and screen-reader users do not walk the sidebar on every page.
• The version tag. The bottom centre of the screen prints the version this installation runs (the octopus keeps the corner) — quote it when reporting a problem.
• Where this guide lives. The sidebar's Resources group holds the User guide you are reading. The API spec and Style guide links appear beside it only on a development instance, so on your own installation this group holds the guide alone.
• Privacy policy and imprint are linked from the foot of the sign-in page.
• Add to home screen. Both the desktop app and the mobile companion ship a web manifest with proper icons, so a phone or desktop browser can install Octbase as an app rather than a bookmark.

Collapsing the sidebar

The button at the top of the sidebar, beside the Octbase wordmark, narrows the sidebar to a rail of icons — about a quarter of its width. It is not a way to hide the navigation: every entry stays exactly where it was, in the same order, under the same icon, and is still one click away. Only the labels go, along with the section headings above them; the dividers stay, so the groups still read as groups. The same button, still at the top of the rail, brings the labels back.

Hovering an icon names it, so a rail you have not memorised is still readable, and a screen reader announces every rail button by its full label exactly as before — the labels are hidden from the eye, not removed.

The choice is remembered in this browser, per device: collapse it on the laptop you use for board work and it stays collapsed there, without following you to another machine. It is worth doing on a narrow screen, or on the board and the mindmap, where the extra width is the difference between one more column on screen and scrolling for it.