Accounts and GitHub Sign-In

Pomavo now gives users more control over identity, access, navigation, and rich text. Accounts and GitHub Sign-In combines account settings, OAuth, join requests, custom icons, routing improvements, and durable editor storage into one release focused on everyday usability.

User settings are now self-service

The user settings experience gives you a dedicated place to manage your own account details. You can update profile information, change credentials, and manage linked social accounts without asking an administrator to edit your profile.

This supports the security direction described in the Security Model: identity belongs to the auth system, while the application verifies tokens and applies permissions. Users should own their own profile and credential changes.

The release also refined the user settings surface over multiple iterations, moving from a page to a more focused dialog experience and improving navigation from the sidebar user menu.

GitHub OAuth sign-in gives teams another login path

GitHub OAuth sign-in lets users authenticate with a GitHub account in addition to email and password. This is useful for engineering teams that already use GitHub as part of their daily workflow and want sign-in to match that identity.

Pomavo uses Better Auth for authentication, with a dedicated auth service handling login and session management. The application API verifies issued tokens and then applies organization context and permissions.

GitHub sign-in improves authentication convenience, but it does not grant organization access by itself. Membership, join requests, and permissions still decide what a user can see and do.

Set-password support bridges OAuth and password accounts

Set-password support helps users who start with social sign-in but later need password login. For example, a user may join with GitHub OAuth, then decide to add a password for direct email-based sign-in.

This is different from changing an existing password. Set-password handles the case where the account does not already have a password credential attached.

This gives teams flexibility without creating duplicate accounts for the same person.

Cross-origin cookies improve hosted auth flows

Hosted products often split the auth service, application API, and frontend across different origins or subdomains. Cross-origin cookie handling improves OAuth and session flows in that deployment shape.

The change matters most during OAuth redirects, callback handling, and session establishment. After GitHub returns the user to Pomavo, the auth session needs to be available to the frontend and API in a way that works across the configured origins.

This work pairs with the broader security model: the auth service owns sessions, while API requests still validate identity, tenant, and permissions.

Join requests support controlled organization access

Join requests let users ask to join an organization instead of requiring every membership to start with an invitation. Organization administrators can review requests from a dedicated page and approve or reject them.

This is described in Organization Settings, where member management includes both invites and join requests. It is especially useful when an organization has a known Pomavo workspace but wants to keep membership approval explicit.

Join requests fit cleanly with Permissions. Approval can add the user to the workspace, while default member permissions and additional grants define what they can do.

Custom project icons make workspaces easier to scan

Projects can now have custom icons uploaded through presigned URLs. A recognizable project icon helps users scan the sidebar, project list, and project detail areas more quickly.

The presigned upload flow lets the frontend upload icon files without routing the file body through every application layer. Pomavo stores the resulting icon path with the project so it can be shown consistently in navigation and project pages.

Custom icons do not change permissions. They improve recognition for projects a user can already access.

Custom organization icons and IconUpload standardize branding

Organizations can also use custom icons, and the shared IconUpload component gives project and organization pages a common upload experience. This reduces duplicated UI logic and gives users a predictable pattern.

Organization icons are useful in switchers, settings, and branded workspace surfaces. They help users confirm which tenant they are working in, which is especially important for people who belong to more than one Pomavo organization.

The result is a clearer multi-tenant experience: the organization tells you where you are, and the project tells you what work context you are in.

React Router 7 data router modernizes navigation

The frontend moved to the React Router 7 data router with modular routes and typed route params. This improves route organization and makes parameter handling more explicit across organization, project, ticket, admin, and auth flows.

The migration extracted route definitions into dedicated route modules and added typed helpers for route parameters. That makes navigation code easier to maintain as Pomavo grows.

For users, the migration should feel like a cleaner, more reliable app shell. For the product, it gives routing a stronger foundation.

TipTap JSON storage preserves rich text structure

Pomavo now stores TipTap rich text as JSON. This preserves editor structure more directly than plain serialized markup and gives the system a better foundation for comments, descriptions, mentions, attachment references, history, and search indexing.

The release also simplified rich-text history diffs to markdown for readability. That means Pomavo can store structured editor content while still showing change history in a form people can review.

A migration script supports moving existing rich text content to the new JSON shape. This is infrastructure work, but it improves the reliability of the writing experience users see every day.

Rich text, identity, and search still follow permissions

Account improvements and editor storage do not change the core access model. A signed-in user still needs permission to view tickets, list comments, add comments, edit fields, download attachments, or run query mutations.

For example, a user can sign in with GitHub, join an organization after approval, and then use search only within the resources they can access.

1
2
3

assignee = @me and status not in ("Done", "Closed")
order by updated_at desc
limit 25

This is the same defense-in-depth posture described in the Security Model: identity, tenant context, permissions, and scoped data access work together.

A smoother first-run and recovery experience

The release also improves edge cases around organization access, including handling when an organization cannot be found. Clearer routing and account flows help users recover from bad links, deleted workspaces, or missing tenant context.

That matters because authentication and tenant routing meet at sign-in time. A user may arrive from a GitHub callback, a public link, an invitation, or a bookmarked organization URL. Pomavo now has a stronger route structure and better account tools for those paths.

What you can do now

If you administer a Pomavo organization, review Organization Settings, confirm your default member permissions, and decide whether join requests should be part of your onboarding workflow.

If you are a user, open user settings, confirm your username and email, link GitHub if your team uses it, and set a password if you want both OAuth and direct sign-in available.

If you manage projects, add icons to your most active projects and check that organization branding makes it clear which workspace users are in.