Project Settings
Project Settings are the control center of every project in Axoria. Here you define how the workflow operates, who can do what, which rules are enforced, and how the system behaves. Every rule configured in this area is verified and enforced by the backend - no frontend role change or field manipulation is sufficient to bypass them.
Access settings via the ⚙️ Settings menu in the project's left sidebar.
Who Can Access Settings
Access to settings is restricted and verified on every request:
| Who | Condition |
|---|---|
| Organization Owner | Full access to any project in the org |
| Organization Admin | Full access to any project in the org |
Member with MANAGE_PROJECTS permission |
Can configure any project (via Profile Group) |
Member with PROJECT_ADMIN role |
Can configure only the project they belong to |
| DEVELOPER / REPORTER / VIEWER | No access to settings - board and backlog only |
How this is enforced: All access checks are performed server-side on every request. Users who do not satisfy any of the conditions above receive HTTP 403. The interface hides settings menus accordingly, but the backend is the authoritative enforcement layer.
General Settings
Where: Settings → General
Define the project's basic information and visibility behavior.
| Field | Type | Description |
|---|---|---|
| Name | Text | Display name shown in the interface, reports, and breadcrumbs. Required. |
| Description | Text | Describes the project's purpose. Optional. |
| Type | Enum | SOFTWARE, BUSINESS, KANBAN, SCRUM, or CUSTOM |
| Visibility | Enum | PRIVATE, INTERNAL, or PUBLIC (see below) |
| Avatar | Image or icon | Built-in icon (FontAwesome) or uploaded custom image |
Visibility Rules
| Value | Behavior |
|---|---|
PRIVATE |
Only project members can access |
INTERNAL |
Any organization member can view the project |
PUBLIC |
Anyone with the URL can view (no authentication required) |
PUBLICvisibility exposes read-only access only - write operations still require authentication and an appropriate role.
Project Key
The project key (key) is set at creation time (e.g., SHOP, API). It forms the identifier prefix for issues (SHOP-1, API-42). The key cannot be changed after creation.
Key rules: 2 to 10 characters, uppercase letters and digits only ([A-Z0-9]).
Board
Where: Settings → Board
The Board is the visual tracking surface for issues. Each project can have multiple boards, but only one board can be active at a time.
Creating and Activating a Board
- Click + Create Board and provide a name and type (
KANBANorSCRUM). - To set which board is displayed, click Activate. Activating a board automatically deactivates the previous one.
View Modes
Each board can enable one or more view modes:
| Mode | Description |
|---|---|
KANBAN |
Visual column board - always included, cannot be removed |
TABLE |
Tabular issue list with sortable columns |
CALENDAR |
Due-date calendar view |
Configure at Settings → Board → [board] → Edit Views.
Columns
Where: Settings → Board → Columns
Columns represent workflow stages. Each issue occupies a column according to its status.
| Field | Type | Description |
|---|---|---|
| Name | Text | Label shown on the board (max 100 chars) |
| Type | Enum | TODO, IN_PROGRESS, or DONE |
| WIP Limit | Integer | Maximum simultaneous issues in the column. 0 or null = no limit |
| Status Mapping | Text | Name of the Workflow status this column represents |
| Order | Integer | Position on the board (drag to reorder) |
Why use a WIP Limit?
The WIP (Work in Progress) Limit prevents overload at a workflow stage. When a column reaches its limit, no issue can be moved into it until another is completed.
How it is enforced: The backend validates the WIP limit on every status move. If the destination column is full, the operation is rejected with HTTP 400 and a descriptive error message.
Transitions
Where: Settings → Board → Transitions
Transitions define which status-to-status moves are allowed.
| Field | Type | Description |
|---|---|---|
| Name | Text | Descriptive label for the transition |
| From | Status (nullable) | Source status. If null = accepts any status as origin |
| To | Status | Required destination status |
Default Behavior
If no transitions are defined in the default workflow, any status change is allowed.
If transitions are defined, only explicitly configured moves are permitted.
How it is enforced: The backend validates every status change against the configured transitions. If the move is not allowed, the operation is rejected with HTTP 400.
Practical example: To prevent issues from jumping directly from To Do to Done, create explicit transitions only between consecutive stages (e.g., TODO → IN_PROGRESS, IN_PROGRESS → REVIEW, REVIEW → DONE).
Workflows and Statuses
Where: Settings → Workflow
The Workflow defines the statuses available in the project. Each issue holds a status belonging to the active default workflow.
Multiple Workflows
You can create multiple workflows (e.g., one for bugs, another for features), but only one workflow can be marked as default. When a workflow is set as default, the system automatically unmarks the previous one.
Creating/Editing a Workflow
| Field | Type | Description |
|---|---|---|
| Name | Text | Internal workflow name (max 100 chars) |
| Description | Text | Optional description (max 500 chars) |
| Default | Boolean | Marks this as the project's active workflow |
Workflow Statuses
Each workflow contains a list of statuses:
| Field | Type | Description |
|---|---|---|
| Name | Text | Status label (max 100 chars) |
| Color | Hex | Highlight color for the status (e.g., #3fb950) |
| Category | Enum | TODO, IN_PROGRESS, or DONE - used for reports and filters |
| Position | Integer | Display order |
Why does category matter? Categories are used to calculate sprint completion rates, burndown charts, and completed-issue counts in reports.
Field Schema
Where: Settings → Field Schema
The Field Schema defines custom fields that appear in each issue's detail panel. You can create multiple schemas and associate them with specific issue types.
Creating a Schema
| Field | Type | Description |
|---|---|---|
| Name | Text | Schema identifier (max 150 chars) |
| Description | Text | Optional (max 500 chars) |
| Issue Types | List | If set, schema appears only for these types. If empty, applies to all |
| Active | Boolean | Inactive schemas are not shown in issues |
Available Field Types
| Type | Use |
|---|---|
TEXT |
Single-line short text |
TEXTAREA |
Multi-line long text |
NUMBER |
Numeric value |
DATE |
Date picker |
SELECT |
Single selection from predefined options |
MULTISELECT |
Multiple selections from options |
CHECKBOX |
Boolean value (checked/unchecked) |
USER |
Reference to a project user |
LABEL |
Free-form tag/label |
Custom Fields
Each field within a schema has:
| Field | Description |
|---|---|
| Name | Label shown in the panel (displayName) |
| Key | Unique technical identifier in the schema (fieldKey) |
| Type | One of the types listed above |
| Required | If checked, the issue cannot be saved without this field filled in |
| Default | Pre-filled value when creating a new issue |
| Options | List of allowed values (SELECT/MULTISELECT only) |
| Position | Display order in the panel |
Issue Panel
Where: Settings → Issue Panel
Defines how the issue detail panel is displayed when clicking on an issue.
| Mode | Description |
|---|---|
OFFCANVAS |
Sliding side panel (default) |
MODAL |
Centered modal dialog |
PAGE |
Dedicated page with its own URL |
In addition to the mode, the width parameter is configurable for OFFCANVAS and MODAL modes, accepted in px, em, rem, and % formats (e.g., 560px, 80%).
Who can change this: Only members with settings access (
PROJECT_ADMIN, org Owner/Admin). Regular members can view the panel but cannot change its mode.
Issue Types
Where: Settings → Issue Types
Issue types categorize the work. Axoria includes 10 default types plus CUSTOM:
| Type | Default Icon | Default Color | Hierarchy |
|---|---|---|---|
EPIC |
fa-bolt |
#a371f7 |
EPIC |
STORY |
fa-book-open |
#3fb950 |
STANDARD |
TASK |
fa-square-check |
#58a6ff |
STANDARD |
BUG |
fa-bug |
#f85149 |
STANDARD |
SUBTASK |
fa-circle-dot |
#7d8590 |
SUBTASK |
IMPROVEMENT |
fa-arrow-trend-up |
#a5a5ff |
STANDARD |
SPIKE |
fa-bolt-lightning |
#ffd43b |
STANDARD |
RESEARCH |
fa-magnifying-glass |
#4dabf7 |
STANDARD |
HOTFIX |
fa-fire |
#ff6b6b |
STANDARD |
TECHNICAL_DEBT |
fa-gauge-high |
#adb5bd |
STANDARD |
Customizing Types
For each type you can change:
- Display name (
displayName) - what appears in the interface - Icon - any FontAwesome class
- Color - hexadecimal value (
#RRGGBB) - Hierarchy level -
EPIC,STANDARD, orSUBTASK - Active / Inactive - inactive types are not shown when creating issues
How the Rule is Enforced
If an issue's type is changed to a disabled type, the backend rejects the operation with HTTP 400.
Priorities
Where: Settings → Priorities
Priorities indicate the urgency of each issue. The system includes 5 default levels:
| Priority | Default Color | Default Icon |
|---|---|---|
CRITICAL |
#f03e3e |
fa-angles-up |
HIGH |
#fd7e14 |
fa-angle-up |
MEDIUM |
#f59f00 |
fa-equals |
LOW |
#40c057 |
fa-angle-down |
TRIVIAL |
#868e96 |
fa-angles-down |
Customizing Priorities
For each priority you can change the display name, color, icon, and sort order. Priorities can be enabled or disabled.
How the Rule is Enforced
If an issue's priority is changed to a disabled one, the backend rejects the operation with HTTP 400.
Schemes
Where: Settings → Schemes
A Scheme is a configuration bundle that links three elements into a reusable structure:
- Board - which board is active for this scheme
- Workflow - which status workflow is used
- Field Schema - which custom fields are displayed
Only one scheme can be active at a time. Activating a scheme automatically deactivates the previous one.
Card Layout (CardLayoutSettings)
Each scheme also controls which information appears on board cards:
| Field | Default | Description |
|---|---|---|
showPriority |
true |
Display priority icon on the card |
showStoryPoints |
true |
Display story points estimate |
showAssignee |
true |
Display assignee's avatar |
showLabels |
true |
Display labels |
showDueDate |
false |
Display due date |
showType |
true |
Display issue type icon |
Why Use Schemes?
Schemes let you quickly switch between distinct configurations without recreating boards and workflows. Example: a "Active Sprint" scheme with a SCRUM board and another "Continuous Kanban" scheme with a KANBAN board - switch with one click.
Notification Rules
Where: Settings → Notifications
Notification rules determine who is notified, how, and when something happens in the project.
Available Events
| Event | Triggered when |
|---|---|
ISSUE_CREATED |
A new issue is created in the project |
ISSUE_UPDATED |
An issue's fields were edited |
ISSUE_ASSIGNED |
An issue is assigned or reassigned to a member |
COMMENT_ADDED |
A comment is added to an issue |
STATUS_CHANGED |
An issue's status was changed |
SPRINT_STARTED |
A sprint was started |
SPRINT_COMPLETED |
A sprint was completed |
MENTION |
A member was mentioned with @ in an issue or comment |
Notification Channel
| Channel | Description |
|---|---|
IN_APP |
Notification visible in the 🔔 bell inside Axoria |
Email sending can be configured through Automations (
send_email). Webhooks are a separate system from in-app notifications.
Recipients
Recipients can be defined as:
| Token | Who receives |
|---|---|
ASSIGNEE |
The issue's assignee(s) |
REPORTER |
The person who reported the issue |
ALL_MEMBERS |
All project members |
| User UUID | A specific member by their ID |
Creating a Rule
Go to Settings → Notifications → + New Rule and define:
- The event that triggers the notification
- The delivery channel
- The recipients
- Whether the rule is active
An inactive rule is preserved but does not trigger notifications.
Webhooks
Where: Settings → Webhooks
Webhooks are distinct from Notification Rules. While rules manage in-app notifications (IN_APP), webhooks send signed payloads to external endpoints (e.g., Slack, CI/CD systems, custom pipelines).
| Field | Description |
|---|---|
| Name | Webhook identifier |
| URL | Endpoint that will receive HTTP POST requests |
| Secret Token | Key used to sign the payload with HMAC-SHA256 |
| Events | Set of subscribed events |
| Active | Enable/disable without deleting |
Webhook Security
Each request is signed using HMAC-SHA256 with the configured secretToken. The receiving endpoint must validate the signature before processing the payload.
Project Members
Where: Settings → Members
Manage who has access to the project and with which role.
Project Roles
| Role | Permissions |
|---|---|
PROJECT_ADMIN |
Full project control: settings, members, board, issues |
DEVELOPER |
Create, edit, and move issues; view settings (cannot change) |
REPORTER |
Create issues and comment; cannot move or delete |
VIEWER |
Read-only: view issues and board without editing |
Adding a Member
- Click + Add Member
- Enter the user's email address
- Select a role (default:
DEVELOPER) - Confirm
If the user is already a project member, the operation returns a
409 CONFLICTerror.
Changing a Role
A member with settings access can change any member's role via the action menu next to each member in the list.
Removing a Member
Click Remove next to the member. The removal revokes access immediately. Issues already assigned to the member are not automatically reassigned.
Who can manage members: org Owner/Admin, member with MANAGE_PROJECT_MEMBERS, or a PROJECT_ADMIN in the project.
Attachments
Where: Settings → Attachments
Control whether project issues accept uploaded files.
| Setting | Default | Description |
|---|---|---|
| Attachments enabled | true |
Toggle file uploads on issues |
| Max per issue | 4 |
Between 1 and 20. File limit per issue |
Upload Rules
- Only image files are accepted (PNG, JPG, GIF, WebP)
- Maximum file size: 5 MB
- If
attachmentsEnabled = false, any upload attempt returnsHTTP 403 - If the limit is reached, the upload is rejected with
HTTP 400
Public Tokens
Where: Settings → Public Tokens
Public Tokens allow sharing a read-only view of the board or reports with people who do not have an Axoria account.
| Field | Description |
|---|---|
| Type | BOARD (specific board) or REPORT (project reports) |
| Token | Secure 64-character string generated with SecureRandom |
| Expires at | Optional expiration date. null = never expires |
| Active | Token can be deactivated without being deleted |
| Filters | Optional filters applied to the public view (e.g., specific sprint) |
Generating a Token
- Go to Settings → Public Tokens
- Click + Generate Token
- Select the type (
BOARDorREPORT) and target resource - Set expiration (optional)
- Copy the generated public URL
Security
- No internal UUIDs or sensitive data are returned in the public response
- Revoking a token immediately invalidates all access using that link
Danger Zone
Where: Settings → Danger Zone
Archiving a Project
Archiving a project changes its status to ARCHIVED. Archived projects:
- Do not appear in the default project listing
- Keep all data preserved (issues, sprints, attachments)
- Can be unarchived by an Owner/Admin
Who can archive: org Owner/Admin, member with MANAGE_PROJECTS, or the project's PROJECT_ADMIN.
⚠️ Deleting a project is irreversible. All data is permanently removed. Export your data before proceeding.
Who Can Do What - Summary
| Action | Viewer | Reporter | Developer | PROJECT_ADMIN | Org Owner/Admin |
|---|---|---|---|---|---|
| View board and issues | ✅ | ✅ | ✅ | ✅ | ✅ |
| Create issues | ❌ | ✅ | ✅ | ✅ | ✅ |
| Edit and move issues | ❌ | ❌ | ✅ | ✅ | ✅ |
| Manage members | ❌ | ❌ | ❌ | ✅ | ✅ |
| Access settings | ❌ | ❌ | ❌ | ✅ | ✅ |
| Create/edit columns | ❌ | ❌ | ❌ | ✅ | ✅ |
| Configure workflows | ❌ | ❌ | ❌ | ✅ | ✅ |
| Manage types/priorities | ❌ | ❌ | ❌ | ✅ | ✅ |
| Generate public tokens | ❌ | ❌ | ❌ | ✅ | ✅ |
| Archive project | ❌ | ❌ | ❌ | ✅ | ✅ |
Members with permissions via the organization's Profile Group (
MANAGE_PROJECTS,MANAGE_BOARDS, etc.) may have expanded access without beingPROJECT_ADMIN.
General Settings
| Field | Description |
|---|---|
| Name | Display name shown in the interface and reports |
| Description | Brief description of the project's purpose |
| Type | Software, Business, or Marketing |
| Visibility | Private, Public (Org), or Public |
| Avatar | Built-in icon or custom image for the project |
Board Configuration
Columns
Manage Kanban columns at Settings → Board → Columns:
| Field | Description |
|---|---|
| Name | Label shown on the board |
| Type | TODO, IN_PROGRESS, DONE, or CANCELLED |
| WIP Limit | Max simultaneous issues (0 = no limit) |
| Order | Drag to reorder columns on the board |
Click + Add Column to create a new workflow step.
Transitions
Transitions define which column-to-column moves are allowed. Go to Settings → Board → Transitions.
By default all transitions are allowed. Restrict them to enforce mandatory steps (e.g., prevent moving from TODO directly to DONE without passing through IN_PROGRESS).
Workflow and Statuses
The Workflow defines the available statuses, each linked to a board column.
At Settings → Workflow:
- View all statuses and their column associations
- Add, rename, or remove statuses
- Set the default status for new issues
Field Schema
The Field Schema defines custom fields displayed in each issue's panel. Access at Settings → Field Schema.
Available field types:
- Free text
- Number
- Date
- Single select
- Multi select
Configure the visibility of each default and custom field at Settings → Issue Panel.
Issue Types
Configure issue categories at Settings → Issue Types:
- Create types with custom name and icon
- Set the default type for new issues
- Reorder or deactivate existing types
Priorities
Configure urgency levels at Settings → Priorities:
- Name and color of each priority level
- Display order in filters and forms
- Default priority for new issues
Schemes
Schemes allow you to create and reuse configurations (issue types and fields) across multiple projects. Access at Settings → Schemes.
Notifications
Configure notification rules per project event at Settings → Notifications.
Available Events
| Event | Triggered when |
|---|---|
| ISSUE_CREATED | A new issue is created |
| ISSUE_UPDATED | An issue is edited |
| ISSUE_ASSIGNED | An issue is assigned to a member |
| COMMENT_ADDED | A comment is added to an issue |
| STATUS_CHANGED | An issue's status changes |
| SPRINT_STARTED | A sprint is started |
| SPRINT_COMPLETED | A sprint is completed |
| MENTION | A member is mentioned in an issue |
Notification Channel
| Channel | Description |
|---|---|
| IN_APP | In-app notification in the Axoria interface |
Email sending can be configured through Automations. Webhooks are a separate system.
Recipients
| Token | Who receives the notification |
|---|---|
| ASSIGNEE | All assignees of the issue |
| REPORTER | The member who created the issue |
| ALL_MEMBERS | All project members |
Creating a Rule
- Go to Settings → Notifications → New Rule.
- Select the event, channel, and recipients.
- Enable the rule with the toggle and save.
Webhooks
Webhooks integrate Axoria with external systems like Slack, Discord, CI/CD pipelines, and more.
- Go to Settings → Webhooks → Add Webhook.
- Enter the destination URL (HTTPS recommended).
- Select the events that trigger the webhook.
- Save.
The payload is a JSON object with event details.
Attachment Settings
Control issue attachments at Settings → Attachments:
| Field | Default | Range |
|---|---|---|
| Enable Attachments | Yes | - |
| Max per issue | 3 | 1–20 |
Only images (PNG, JPG, GIF, WebP) are accepted. Maximum size: 5 MB per file.
Public Tokens
Public Tokens allow sharing the board or report with people without an Axoria account.
- Go to Settings → Public Tokens → Generate Token.
- Select the type: Board or Report.
- Optionally set an expiration date.
- Copy and share the generated link.
To revoke access, click Revoke next to the token. The link stops working immediately.