Allow creating event without client id

[wen-templari]

Allow creating event without client id. This could simplify event creation process.

[wen-templari]

@claude can you add more design detail to this issue

[claude]

Claude finished @wen-templari's task —— View job

---

Design Details for Creating Events Without Client ID

Based on my analysis of the codebase, here are the comprehensive design details for allowing event creation without client ID:

Task List

• Understand current event creation system and client ID usage
• Analyze database schema for events
• Examine API endpoints related to event creation
• Document design options and considerations
• Provide implementation recommendations

---

Current System Analysis

Current Architecture:

• Events are tightly coupled to clients via client_id (foreign key constraint)
• Authentication extracts client_id from JWT/Logto tokens
• Database enforces referential integrity: event_client_id_fkey
• All event operations require client authentication
• Event access control based on client ownership

Current Event Creation Flow:

1. Client authenticates → Extract client_id from auth token
2. Create event with client_id → Database validates foreign key
3. Log creation action → Event becomes "open" status
4. Only authenticated clients can access their own events

---

Design Options for Client-ID-Free Events

Option 1: Anonymous Events (Recommended)

Allow unauthenticated users to create events without client association.

Implementation Details:

-- Database Schema Change
ALTER TABLE public.event ALTER COLUMN client_id DROP NOT NULL;
ALTER TABLE public.event DROP CONSTRAINT event_client_id_fkey;

-- Add constraint to allow NULL client_id
ALTER TABLE public.event ADD CONSTRAINT event_client_id_fkey 
  FOREIGN KEY (client_id) REFERENCES public.client(client_id) 
  ON UPDATE RESTRICT ON DELETE SET NULL;

New API Endpoint:

// router/event.go
func (EventRouter) CreateAnonymousEvent(ctx context.Context, input *CreateAnonymousEventInput) (*util.CommonResponse[model.Event], error) {
    event := &model.Event{
        ClientId:          0, // or sql.NullInt64{Valid: false}
        Model:             input.Body.Model,
        Phone:             input.Body.Phone,
        QQ:                input.Body.QQ,
        ContactPreference: input.Body.ContactPreference,
        Problem:           input.Body.Problem,
    }
    
    err := service.EventServiceApp.CreateAnonymousEvent(event)
    if err != nil {
        return nil, huma.Error422UnprocessableEntity(err.Error())
    }
    return util.MakeCommonResponse(*event), nil
}

Pros:

• Simplifies event creation for non-registered users
• Reduces friction for problem reporting
• Maintains backwards compatibility

Cons:

• No ownership model for anonymous events
• Cannot retrieve events later without event ID
• Potential for spam/abuse without authentication

---

Option 2: System-Generated Client ID

Automatically create a temporary/anonymous client record for each event.

Implementation Details:

// service/event.go
func (service EventService) CreateAnonymousEvent(event *model.Event) error {
    // Create anonymous client
    client := &model.Client{
        OpenId: "", // Empty for anonymous
    }
    
    if err := repo.CreateClient(client); err != nil {
        return err
    }
    
    event.ClientId = client.ClientId
    return service.CreateEvent(event)
}

Pros:

• Maintains referential integrity
• Consistent data model
• Easier to track anonymous events

Cons:

• Creates unnecessary client records
• More complex cleanup process
• Database bloat with temporary clients

---

Option 3: Hybrid Approach

Support both authenticated and anonymous event creation with different workflows.

Implementation Details:

• Modify Event model to use sql.NullInt64 for client_id
• Create two separate endpoints: /events (authenticated) and /events/anonymous (public)
• Implement different authorization logic for authenticated vs anonymous events

---

Security & Authorization Considerations

Anonymous Events

• Access Control: Anonymous events readable by all admins/members
• Modification: Only admins can modify anonymous events
• Retrieval: Require event ID for anonymous event lookup (no listing)
• Rate Limiting: Implement IP-based rate limiting to prevent spam

Authenticated vs Anonymous Workflow

// Authorization matrix
if event.ClientId == 0 {
    // Anonymous event - only admins can modify
    if action != "read" && auth.Role != "admin" {
        return ErrUnauthorized
    }
} else {
    // Authenticated event - existing logic
    if event.ClientId != userClientId && auth.Role != "admin" {
        return ErrUnauthorized
    }
}

---

Database Migration Strategy

Phase 1: Schema Changes

-- Migration 000002_optional_client_id.up.sql
ALTER TABLE public.event ALTER COLUMN client_id DROP NOT NULL;
ALTER TABLE public.event DROP CONSTRAINT event_client_id_fkey;
ALTER TABLE public.event ADD CONSTRAINT event_client_id_fkey 
  FOREIGN KEY (client_id) REFERENCES public.client(client_id) 
  ON UPDATE RESTRICT ON DELETE SET NULL;

-- Add index for NULL client_id queries
CREATE INDEX event_anonymous_idx ON public.event (client_id) WHERE client_id IS NULL;

Phase 2: Model Updates

// model/event.go
type Event struct {
    EventId           int64              `json:"eventId" db:"event_id"`
    ClientId          sql.NullInt64      `json:"clientId,omitempty" db:"client_id"`
    // ... rest of fields
}

// New DTO for anonymous events
type CreateAnonymousEventRequest struct {
    Model             string `json:"model" binding:"omitempty,max=40"`
    Phone             string `json:"phone" binding:"required,len=11,numeric"`
    QQ                string `json:"qq" binding:"omitempty,min=5,max=20,numeric"`
    ContactPreference string `json:"contactPreference" binding:"required,oneof=phone qq"`
    Problem           string `json:"problem" binding:"required,max=1000"`
}

---

Implementation Recommendations

Recommended Approach: Option 1 (Anonymous Events)

1. Minimal Database Changes: Only modify client_id to be nullable
2. New Public Endpoint: /api/events/anonymous (no authentication required)
3. Enhanced Authorization: Update existing endpoints to handle NULL client_id
4. Spam Prevention: Implement rate limiting and basic validation

API Design:

POST /api/events/anonymous
{
  "model": "iPhone 12",
  "phone": "13800138000",
  "qq": "123456789",
  "contactPreference": "phone",
  "problem": "Screen is cracked"
}

Migration Path:

1. Create database migration for nullable client_id
2. Update models to use sql.NullInt64
3. Add new anonymous event creation endpoint
4. Update existing authorization logic
5. Add rate limiting middleware
6. Update API documentation

---

Additional Considerations

Event Lifecycle Management

• Anonymous events follow same status workflow (open → accepted → committed → closed)
• Members can accept anonymous events normally
• Admin approval may be required for anonymous events

Contact Information Validation

• Require at least one contact method (phone or QQ)
• Validate phone numbers and QQ formats
• Consider SMS/email verification for anonymous events

Monitoring & Analytics

• Track anonymous vs authenticated event creation rates
• Monitor for spam patterns
• Measure conversion from anonymous to registered users

---

This design maintains system integrity while significantly simplifying the event creation process for non-registered users, potentially increasing problem reporting rates and user engagement.

---

[wen-templari]

We found it's acceptable for clients to create ticket after login. So we can skip this feature for now.