Development: Implement interview slot conflict validation

[Abi107717]

Checklist

General

• I tested all changes and their related features with all corresponding user types.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
• I strictly followed the principle of data economy for all database calls.
• I strictly followed the server coding and design guidelines.
• I documented the Java code using JavaDoc style.

Client

• Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data (e.g. using paging).
• I strictly followed the principle of data economy for all client-server REST calls.
• I strictly followed the client coding and design guidelines.
• I documented the TypeScript code using JSDoc style.
• I added multiple screenshots/screencasts of my UI changes.

Motivation and Context

The previous conflict detection logic for interview slots was too strict, preventing professors from creating parallel "availability" slots across different interview processes. This need to be refined to allow flexibility while strictly preventing double-bookings. Additionally, to keep the schedule clean, overlapping unused slots should be automatically removed once a booking is confirmed.

Description

Refined the server-side and client-side conflict logic to distinguish between different types of overlaps:

Cross-Process Logic:
Allowed: Overlap with unbooked slots from other processes. This allows professors to offer the same time window in multiple job openings.
Blocked: Overlap with booked slots from other processes. This strictly prevents double-booking the professor.

Same-Process Logic:
Blocked: Any overlap within the same process is forbidden to prevent duplicate or messy slot creation.

Auto-Cleanup:
When a slot is booked by an applicant, the system now automatically finds and deletes any overlapping unbooked slots in other processes to ensure the schedule is consistent.

UI Updates:
Client side now visually distinguishes these conflicts and displays appropriate error messages (e.g., specific warning for "Conflict with booked slot in another process").

Steps for Testing

Prerequisites:
Log in to TumApply as Professor
Go to interviews/overview and choose an Interview Process

Case 1: Same Process Conflict (Strict)

1. Create a slot (e.g., 10:00 - 11:00).
2. Try to add another slot that overlaps this time (e.g., 10:30 - 11:30) within the same process.
3. Verify: The UI shows a conflict error. Saving is disabled.

Case 2: Other Process - Unbooked Slot (Allowed)

1. Ensure you have an unbooked slot in "Process A" (e.g., 12:00 - 13:00).
2. Switch to "Process B".
3. Create a slot at the exact same time (12:00 - 13:00).
4. Verify: No conflict error is shown. You can save the slot successfully.

Case 3: Other Process - Booked Slot (Blocked)

1. Ensure you have a booked slot (with an assigned applicant) in "Process A" (e.g., 14:00 - 14:30).
2. Switch to "Process B".
3. Try to create a slot at that time (14:00 - 14:30).
4. Verify: The UI displays a red error: "Conflict with a booked slot in another Job Position". Saving is disabled.

Case 4: Auto-Cleanup on Booking

1. Create an unbooked slot in "Process A" and an unbooked slot in "Process B" at the same time (e.g., 15:00 - 15:30).
2. Assign an Applicant to the created Slot in Process A
3. Go back to the slot management for "Process B".
4. Verify: The unbooked slot in "Process B" (15:00 - 15:30) overlaps the new booking and should have been automatically deleted by the system.

Review Progress

Code Review

• Code Review 1

Manual Tests

• Test 1

Test Coverage

Warning: Both client and server tests failed. Coverage could not be fully measured. Please check the workflow logs.

Last updated: 2026-01-20 21:11:52 UTC

Screenshots

Slot conflict in same process

Slot conlfict with a booked slot in another process

[github-actions]

@Abi107717 Test coverage could not be fully measured because some tests failed. Please check the workflow logs for details.

[github-actions]

📊 Client Test Coverage Too Low

🔍 View coverage locally:

npm run test:ci
open build/test-results/lcov-report/index.html

🌐 View coverage from GitHub:
Download the "coverage-report-client" artifact from this workflow run.

[github-actions]

🤖 OpenAPI spec and client code auto-updated and committed.

[github-actions]

@Abi107717 Test coverage could not be fully measured because some tests failed. Please check the workflow logs for details.

[github-actions]

📊 Client Test Coverage Too Low

🔍 View coverage locally:

npm run test:ci
open build/test-results/lcov-report/index.html

🌐 View coverage from GitHub:
Download the "coverage-report-client" artifact from this workflow run.

[github-actions]

🤖 No OpenAPI or client changes needed.

[github-actions]

@Abi107717 Test coverage could not be fully measured because some tests failed. Please check the workflow logs for details.

[github-actions]

🤖 No OpenAPI or client changes needed.

[github-actions]

@Abi107717 Test coverage could not be fully measured because some tests failed. Please check the workflow logs for details.

[github-actions]

@Abi107717 Test coverage could not be fully measured because some tests failed. Please check the workflow logs for details.

[github-actions]

🤖 No OpenAPI or client changes needed.

[github-actions]

@Abi107717 Test coverage could not be fully measured because some tests failed. Please check the workflow logs for details.