Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/joaomonteir0/printheritage/llms.txt

Use this file to discover all available pages before exploring further.

PrintHeritage operates on a layered access model. Platform-wide roles control what a user can do globally, while per-project roles determine what they can do within a specific project. Administrators can create and manage users from the Team Management page, and project members can be invited, assigned roles, or removed from within each project’s detail view. Users manage their own profiles and passwords from the Settings page.

Global Roles

Every user is assigned exactly one global role:
RoleDescription
SUPER_ADMINFull access to all users, projects, and audit logs. Can manage any user regardless of role.
GENERAL_ADMINCan create, edit, and delete users with the PROJECT_ADMIN or VISUALIZER role.
PROJECT_ADMINCan manage the team and data of projects they belong to.
VISUALIZERRead-only access to project data. Cannot create users or manage teams.
A GENERAL_ADMIN cannot manage other GENERAL_ADMIN or SUPER_ADMIN accounts. The canManage guard in the UI enforces this by checking both the current user’s role and the target user’s role before showing action buttons.

Creating a User

Only SUPER_ADMIN and GENERAL_ADMIN accounts have access to the user creation form on the Gestão de Equipa page. The form collects:
  • Full name (full_name) — required.
  • Email (email) — must be a valid email address; used as the login credential.
  • Password (password) — set by the administrator at creation time.
  • Global role (global_role) — selected from GENERAL_ADMIN, PROJECT_ADMIN, or VISUALIZER.
Submitting the form calls:
POST /register
{
  "email": "user@example.com",
  "password": "securepassword",
  "global_role": "PROJECT_ADMIN",
  "full_name": "João Monteiro"
}
There is no email-verification step. Accounts are active immediately after creation. Ensure you share credentials securely with the new team member.

Searching and Listing Users

The search bar on the Gestão de Equipa page filters the user list in real time. On every keystroke the component calls:
GET /users?q={search}
An empty query string returns all users the current administrator is permitted to see. Each user row displays their avatar (or initial letter), full name, email, and global role badge. The SUPER_ADMIN role badge is rendered in red; all other roles use a neutral grey.

Inline Role and Name Editing

Administrators can edit a user’s full name and global role directly in the table without navigating to a separate page. Clicking the edit pencil icon on a row:
  1. Replaces the name cell with a text input pre-filled with the current full_name.
  2. Replaces the role cell with a <select> dropdown.
  3. Shows Save (green check) and Cancel (grey ✕) buttons in the actions column.
Confirming the edit calls:
PATCH /users/{user_id}
{
  "full_name": "João Monteiro",
  "global_role": "VISUALIZER"
}

Deleting a User

The trash-bin icon triggers a confirmation modal before deletion. Confirmed deletion calls:
DELETE /users/{user_id}
You cannot delete your own account. The delete button is hidden for the row matching the currently authenticated user’s ID (u.id !== currentUser?.id).

User Profile Settings

Every user can update their own profile from the Definições page. The personal information form accepts:
  • Full name (full_name)
  • Birth date (birth_date) — stored as an ISO 8601 datetime.
  • Profile picture URL (profile_pic_url) — an external URL to an image.
  • Public visibility (is_public) — a toggle that controls whether the profile is discoverable by other users.
Saving calls:
PATCH /users/{user_id}
{
  "full_name": "João Monteiro",
  "birth_date": "1990-06-15T00:00:00.000Z",
  "profile_pic_url": "https://cdn.example.com/avatar.jpg",
  "is_public": true
}
The is_public field determines whether the user’s name and avatar appear in the autocomplete suggestion list when someone sends a project invitation. Private profiles (is_public: false) are not suggested.

Changing Your Password

The Segurança section of Settings provides a password change form with three fields: current password, new password, and a confirmation repeat. Client-side validation enforces:
  • New password must be at least 8 characters.
  • New password and confirmation must match.
Submitting calls:
POST /change-password
{
  "current_password": "oldpassword123",
  "new_password": "newpassword456"
}
If the current_password is incorrect the server returns an error with a detail field. The Settings page surfaces this message in a modal so the user knows exactly what failed.

Per-Project Member Management

Project-level team management lives in the project detail view’s Equipa sidebar panel.

Inviting a Member

Users with the PROJECT_ADMIN, GENERAL_ADMIN, or SUPER_ADMIN role can invite new members by clicking the UserPlus button. An invite modal collects:
  • Email — as you type (≥ 3 characters), a debounced search (GET /users/search?q={email}) surfaces matching users as a dropdown suggestion list. Clicking a suggestion auto-fills the email field.
  • Role — either VISUALIZER (read-only) or PROJECT_ADMIN (can manage team and data).
Submitting sends:
POST /projects/{project_id}/invite?user_email={email}&access_level={role}
The invited user receives a pending invitation. Their member card shows an amber clock icon until they accept.

Removing Members

Clicking Gerir Acessos enters an edit mode that turns each member card into a clickable toggle. Selected members are staged for deletion (shown with a strikethrough and red highlight). Clicking Confirmar sends a batch of parallel requests:
DELETE /projects/{project_id}/members/{user_id}
one per staged member. Clicking Cancelar exits edit mode without making any changes.
Pending invitations appear in the invited user’s notification area. Accepting calls the INVITE_ACCEPT action; rejecting calls INVITE_REJECT. Both transitions are recorded in the audit log with the PROJECT target type and the relevant project ID.

Build docs developers (and LLMs) love