Student Profile Edit — Bio Only

Overview

Sequence Diagram

sequenceDiagram
    participant B as Browser
    participant R as Route / Middleware
    participant RQ as UpdateProfileRequest
    participant C as UpdateProfileController
    participant S as StudentProfileService
    participant RP as ProfileWriteRepository
    participant M as MoodleUserProfile
    participant DB as MySQL (user table)
    participant E as Event Dispatcher
    participant L as ForwardEventToMoodle
    participant MO as Moodle Plugin (REST)

    B->>R: PATCH /api/v1/students/me
    R->>R: auth:sanctum + moodle.active + throttle:10,1
    R->>RQ: Validate input
    alt bio missing / too long
        RQ-->>B: 422 Validation Error
    end
    alt picture or imagealt present
        RQ-->>B: 422 Picture editing not allowed
    end
    RQ->>C: toDTO() produces UpdateProfileDTO
    C->>S: updateProfile(dto, user)
    S->>RP: updateBio(studentId, bio)
    RP->>M: updateBio(userId, bio)
    M->>DB: UPDATE user SET description, descriptionformat, timemodified WHERE id = ?
    DB-->>M: OK
    S->>E: dispatch(StudentProfileUpdated)
    E->>L: handle(event) [queued]
    L->>MO: POST /event (user_updated) [async]
    S->>DB: user refresh
    DB-->>S: Fresh user row
    S-->>C: StudentProfileDTO
    C-->>B: 200 JSON envelope with updated profile
      

Flowchart

flowchart TD
    A[PATCH /api/v1/students/me] --> B{Authenticated?}
    B -- No --> C[401 Unauthenticated]
    B -- Yes --> D{Rate limit OK?}
    D -- No --> E[429 Too Many Requests]
    D -- Yes --> F{Validate input}
    F -- bio missing --> G[422 bio is required]
    F -- bio exceeds 65535 chars --> H[422 bio too long]
    F -- picture or imagealt present --> I[422 picture not allowed]
    F -- Valid --> J[UpdateProfileController]
    J --> K[StudentProfileService.updateProfile]
    K --> L[ProfileWriteRepository.updateBio]
    L --> M[MoodleUserProfile.updateBio]
    M --> N[UPDATE user SET description, descriptionformat, timemodified]
    N --> O[Dispatch StudentProfileUpdated]
    O --> P[ForwardEventToMoodle queued]
    P --> Q[Refresh user model]
    Q --> R[Return StudentProfileDTO]
    R --> S[200 OK with StudentResource envelope]

    style C fill:#ef4444,color:#fff
    style E fill:#f59e0b,color:#000
    style G fill:#ef4444,color:#fff
    style H fill:#ef4444,color:#fff
    style I fill:#ef4444,color:#fff
    style S fill:#10b981,color:#000
      

Files Changed

Rules Applied

• Architecture — Moodle Write Exception: Writing to Moodle's core user table is forbidden by default. This feature uses the approved exception path: a dedicated model (MoodleUserProfile) with explicit write methods, no generic Eloquent mass-assignment, and columns enumerated in the query.
• Architecture — Layer Discipline: Request flows through all layers without skipping: Route → Middleware → FormRequest → Controller → Service → Repository → Model → Event. Controller is thin (6 lines), business logic lives in the service, DB access in the repository.
• Architecture — Event System: StudentProfileUpdated extends BaseEvent, carries Moodle-compatible metadata (crud, edulevel, component, target, action, objectTable), and is forwarded to Moodle via the existing ForwardEventToMoodle listener on the queue (async).
• Architecture — DI Bindings: ProfileWriteRepositoryInterface bound to its concrete implementation in AppServiceProvider. Service depends on the interface, not the concrete class.
• Security — Validation in FormRequest Only: All input validation lives in UpdateProfileRequest. No inline validation in the controller or service. The prohibited rule blocks picture/imagealt at the validation layer.
• Security — Own Data Only: The endpoint operates on request->user()->id exclusively. No cross-student access is possible — there is no user ID parameter in the route.
• Security — Rate Limiting: throttle:10,1 middleware applied (10 requests/minute), matching the "sensitive write" tier defined in the security rules.
• Security — SQL Injection Prevention: The write uses Eloquent's query builder with parameter binding (->where('id', $userId)->update([...])). No raw SQL or interpolation.
• Coding Style — PHP 8.3 Features: final readonly DTO with constructor promotion, typed properties throughout, const int for format and max-length constants, explicit return types on every method.
• Coding Style — final by Default: All new classes are final: controller, repository, DTO, request, event, test.
• Coding Style — Constructor Injection: All dependencies injected via constructor. No app() calls or service location in the service or repository layers.
• Coding Style — PHPDoc: Every class has a summary docblock. Public methods have brief descriptions. @param/@return omitted when the signature is self-explanatory.
• Testing — AAA Pattern: Every test follows Arrange → Act → Assert with descriptive test_it_* naming. Tests cover: happy path, persistence, auth failure, validation failures (3 scenarios), picture immutability, and event dispatch.
• Testing — Mocking Rules: External services (Moodle REST API) mocked via Http::fake(). Events tested with Event::fake(). Real database used via RefreshDatabase trait. No Moodle factory files — test data seeded via DB::table()->insert().
• Testing — No Factories for Moodle Models: Tests seed data with DB::table()->insertGetId() and manual model hydration, following the project's canonical pattern (no database/factories/Moodle*Factory.php).