feat: Allow adding users as workspace owners via API

[Christ-Roy]

Allow adding users as workspace owners via API

Context

Currently, when using POST /api/workspaces.inviteMember to add a user to a workspace, the role is hardcoded to "member" (see workspace_service.go:650), even when providing full owner permissions.

This creates a limitation for programmatic workspace provisioning where we need to automatically add users as owners without requiring email invitation acceptance + manual upgrade.

Current Behavior

For existing users

POST /api/workspaces.inviteMember
{
  "workspace_id": "myworkspace",
  "email": "user@example.com",
  "permissions": { /* full permissions */ }
}

Result: User is added directly with role = "member" (line 650 in workspace_service.go)

For new users

Result: Invitation sent by email, user becomes "member" after accepting

Problem

There is no API endpoint to:

1. Add a user as owner directly when they exist
2. Promote a member to owner (without using TransferOwnership which demotes the current owner)

Attempted Workarounds

• ❌ setUserPermissions: Only updates permissions, not the role
• ❌ TransferOwnership: Exists in service but not exposed via HTTP, and it demotes the current owner (not suitable for multi-owner workspaces)
• ✅ Direct DB UPDATE: Works but bypasses API validation

Proposed Solutions

Option 1: Add optional role parameter to inviteMember (Recommended)

Pros:

• Backward compatible (defaults to "member")
• Uses existing endpoint
• Simple implementation

Implementation:

// workspace_service.go
func (s *WorkspaceService) InviteMember(ctx context.Context, workspaceID, email string, permissions domain.UserPermissions, role string) (*domain.WorkspaceInvitation, string, error) {
    // ...existing code...

    // Default role to "member" if not specified
    if role == "" {
        role = "member"
    }

    // Validate role
    if role != "member" && role != "owner" {
        return nil, "", fmt.Errorf("invalid role: must be 'member' or 'owner'")
    }

    // Line 647: Use the provided role instead of hardcoded "member"
    userWorkspace := &domain.UserWorkspace{
        UserID:      existingUser.ID,
        WorkspaceID: workspaceID,
        Role:        role, // ✅ Use parameter
        Permissions: permissions,
        CreatedAt:   time.Now().UTC(),
        UpdatedAt:   time.Now().UTC(),
    }
    // ...
}

HTTP Handler:

// workspace_handler.go
type InviteMemberRequest struct {
    WorkspaceID string                 `json:"workspace_id"`
    Email       string                 `json:"email"`
    Permissions domain.UserPermissions `json:"permissions"`
    Role        string                 `json:"role,omitempty"` // ✅ Optional, defaults to "member"
}

Option 2: Create new endpoint POST /api/workspaces.promoteToOwner

Pros:

• Explicit API
• No breaking changes
• Clear intent

Implementation:

// workspace_service.go
func (s *WorkspaceService) PromoteToOwner(ctx context.Context, workspaceID, userID string) error {
    // ... auth checks ...

    targetUserWorkspace, err := s.repo.GetUserWorkspace(ctx, userID, workspaceID)
    if err != nil {
        return fmt.Errorf("user is not a member of the workspace")
    }

    if targetUserWorkspace.Role == "owner" {
        return nil // Already owner
    }

    targetUserWorkspace.Role = "owner"
    targetUserWorkspace.Permissions = domain.FullPermissions
    targetUserWorkspace.UpdatedAt = time.Now().UTC()

    return s.repo.AddUserToWorkspace(ctx, targetUserWorkspace)
}

Use Case

Automated SaaS provisioning (e.g., Web-Dashboard provisioning Notifuse workspaces):

// 1. Root admin creates workspace
const workspace = await createWorkspace(workspaceId);

// 2. Invite user AS OWNER immediately
await inviteMember(workspaceId, userEmail, fullPermissions, 'owner');
// OR with Option 2:
// await inviteMember(workspaceId, userEmail, fullPermissions);
// await promoteToOwner(workspaceId, userId);

// ✅ User has immediate owner access (if existing user)
// ✅ No email acceptance required
// ✅ No database bypass needed

Testing

Tested with existing users in workspace testazernew:

• ✅ inviteMember adds user directly (has user_id)
• ❌ Role is hardcoded to "member"
• ❌ setUserPermissions doesn't change role
• ✅ Direct DB UPDATE works: UPDATE user_workspaces SET role = 'owner'

Recommendation

Option 1 (add role parameter to inviteMember) is preferred because:

• Backward compatible
• Single API call
• Consistent with existing patterns
• Minimal code changes

Related Files

• internal/service/workspace_service.go (lines 589-704)
• internal/http/workspace_handler.go
• internal/domain/workspace.go

[pierre-b]

Hi, could you please explain your use-case, why do you need to give "owner" status to another user? what actions do they need to do as owner that they can't do with all permissions as 'member' ?

[Christ-Roy]

Thanks for the question! Let me explain our use-case and the specific differences between "owner" and "member" roles.

Our Use-Case: SaaS Multi-Tenant Provisioning

We're building a SaaS platform (Web-Dashboard) that automatically provisions Notifuse workspaces for our users when they sign up. Here's the workflow:

1. User signs up on our platform
2. We create a dedicated Notifuse workspace for them (via root admin API)
3. The user should become the owner of their own workspace

The user needs to fully manage their instance: invite their own team members, configure SMTP settings, manage blogs, etc. We want them to be completely autonomous, not dependent on us for administrative tasks.

Specific Actions That Require "Owner" Role

After reviewing the Notifuse source code (workspace_service.go:722-723), here's what only owners can do, even with all permissions set to true:

1. Manage User Permissions

// Line 722-723: Only owners can call this
if userWorkspace.Role != "owner" {
    return fmt.Errorf("only workspace owners can manage user permissions")
}

• setUserPermissions: Modify other members' permissions
• Members with full permissions still can't manage permissions

2. Workspace Administration

Based on the codebase, owners can:

• Invite new members (inviteMember requires owner role)
• Remove members (removeMember requires owner role)
• Transfer ownership
• Access sensitive workspace settings (SMTP credentials, blog settings, etc.)

3. Security & Ownership Model

The "owner" role represents who owns the workspace, while "member" represents who has access. Even with all permissions granted, a member:

• Cannot fully manage team membership
• Cannot be trusted with administrative tasks
• Is still subject to owner's decisions

Why Not Just Use "member" with All Permissions?

We tested this approach with existing users. Even when a member has all permissions:

• They cannot invite their own team members
• They cannot modify member permissions
• They're essentially stuck depending on the root admin

For a true multi-tenant SaaS where customers own their workspace, they need the owner role - not just full permissions as a member.

Proposed Solution

Adding an optional role parameter to inviteMember (or a promoteToOwner endpoint) would allow SaaS platforms like ours to properly provision workspaces where customers have full ownership of their instance.

Would this explanation help clarify the use-case?

---

Robert & Claude

[pierre-b]

At the moment Notifuse only allows a "transferOwnership" to another user, but what if the transferOwnership would not demote the current owner and allow for multiple owners?

You could promote owners via API automatically.

[Christ-Roy]

That's a brilliant solution! 🎉

Allowing transferOwnership to promote users to owners without demoting the current owner would perfectly solve our problem:

• ✅ Multiple owners support
• ✅ Can programmatically promote users via API
• ✅ Root admin can stay as owner for support/maintenance
• ✅ Users get full ownership of their workspace

This is actually even better than adding a role parameter to inviteMember — it's cleaner and reuses existing functionality.

Looking forward to this feature!

---

Robert & Claude

[pierre-b]

Just to make sure, do you need some non-owner users to be able to create/delete workspaces? or just have full control over the workspace they belong to?

[Christ-Roy]

Just to make sure, do you need some non-owner users to be able to create/delete workspaces? or just have full control over the workspace they belong to?

If possible it would be workinf if they have full control over the workspace they belong to as owner