Auto Approve

[pearmini]

#1113

[rlho]

@pearmini Can you resolve the conflict?

[Copilot]

Pull request overview

This PR refactors the auto-approval system to replace the simple boolean shouldAutoApprove field with a more granular autoApproval configuration object in tenant schemas. This change addresses issue #1113 by providing fine-grained control over auto-approval conditions based on user roles, booking duration, and requested services. The refactoring centralizes auto-approval logic in a new utility module and updates both state machines (ITP and Media Commons) to use this centralized approach.

Key changes:

• Introduces a new autoApproval configuration structure with role-based hour limits and service-specific conditions
• Centralizes auto-approval logic in autoApprovalUtils.ts for consistency across tenants
• Updates test fixtures to use the new configuration format

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
booking-app/lib/utils/autoApprovalUtils.ts	New utility module containing centralized auto-approval logic with role normalization, duration checks, and service condition validation
booking-app/components/src/types.ts	Updates RoomSetting type to replace shouldAutoApprove boolean with granular autoApproval configuration object
booking-app/components/src/client/routes/components/SchemaProvider.tsx	Updates Resource type definition to match new autoApproval structure and makes minHour optional
booking-app/lib/stateMachines/mcBookingMachine.ts	Refactors auto-approval guard to use new checkAutoApprovalEligibility utility instead of inline logic
booking-app/lib/stateMachines/itpBookingMachine.ts	Refactors ITP state machine to use new auto-approval utility with appropriate service mappings
booking-app/components/src/client/routes/booking/hooks/useCheckAutoApproval.tsx	Updates client-side auto-approval checks to use new utility for non-XState tenants
booking-app/app/api/bookings/route.ts	Updates API logging to reference new autoApproval field instead of shouldAutoApprove
booking-app/tests/e2e/helpers/mock-services.ts	Updates mock service logic to check for autoApproval configuration instead of boolean flag
booking-app/tests/unit/mc-booking-machine.unit.test.ts	Updates test fixtures to use new autoApproval configuration structure
booking-app/tests/unit/mc-booking-machine.xstate.unit.test.ts	Updates XState test scenarios with detailed autoApproval configurations
booking-app/tests/unit/xstate-approval-real-integration.unit.test.ts	Updates integration test fixtures to use new autoApproval structure and adds clarifying comments

Comments suppressed due to low confidence (2)

booking-app/components/src/client/routes/components/SchemaProvider.tsx:59

• The minHour field was changed from required to optional (added ?). This is a potentially breaking change if any code depends on this field always being present. Ensure that all code accessing minHour properly handles the undefined case, or document why this change was necessary as part of the auto-approval refactor.

  minHour?: {
    student: number;
    faculty: number;
    admin: number;
    studentWalkIn: number;
    facultyWalkIn: number;
    adminWalkIn: number;
    studentVIP: number;
    facultyVIP: number;
    adminVIP: number;
  };

booking-app/components/src/types.ts:353

• The type definition has both the new autoApproval.minHour / autoApproval.maxHour fields and the legacy minHour / maxHour fields at the root level. This creates ambiguity about which fields should be used. Consider deprecating the legacy fields or clarifying their relationship in the documentation. The same issue exists in the SchemaProvider.tsx Resource type.

  autoApproval?: {
    minHour?: {
      admin: number;
      faculty: number;
      student: number;
    };
    maxHour?: {
      admin: number;
      faculty: number;
      student: number;
    };
    conditions?: {
      setup: boolean;        // Allow auto-approval with setup requests
      equipment: boolean;    // Allow auto-approval with equipment requests
      staffing: boolean;     // Allow auto-approval with staffing requests
      catering: boolean;     // Allow auto-approval with catering requests
      cleaning: boolean;     // Allow auto-approval with cleaning requests
      security: boolean;     // Allow auto-approval with security requests
    };
  };
  maxHour?: {
    student: number;
    faculty: number;
    admin: number;
    studentWalkIn: number;
    facultyWalkIn: number;
    adminWalkIn: number;
    studentVIP: number;
    facultyVIP: number;
    adminVIP: number;
  };
  minHour?: {
    student: number;
    faculty: number;
    admin: number;
    studentWalkIn: number;
    facultyWalkIn: number;
    adminWalkIn: number;
    studentVIP: number;
    facultyVIP: number;
    adminVIP: number;
  };

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rlho]

Please check whether there are any issues with Copilot’s comments.

[rlho]

The logic looks fine, so please add unit tests for checkAutoApprovalEligibility, and then go ahead and merge it.

[pearmini]

The logic looks fine, so please add unit tests for checkAutoApprovalEligibility, and then go ahead and merge it.

Added!