MOSU-67 docs: Application, Admin, Profile 관련 swaggerDocs 작성 #72
Conversation
WalkthroughThis update introduces extensive OpenAPI (Swagger) annotations across DTOs and controller interfaces to enhance API documentation. It also refactors controller method signatures to use Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Controller
participant DocsInterface
participant Service
Client->>Controller: HTTP Request (with userId as RequestParam)
Controller->>DocsInterface: (implements API documentation)
Controller->>Service: Call business logic
Service-->>Controller: Result
Controller-->>Client: ResponseEntity<ApiResponseWrapper<...>>
Possibly related PRs
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @chominju02, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request focuses on significantly improving the API documentation for the Application, Admin, and Profile modules by integrating OpenAPI 3.0 (Swagger) annotations. It introduces a structured approach to API documentation by creating dedicated interfaces for each controller, which now house the API metadata. This change aims to provide a more robust and easily discoverable API specification for consumers and future developers.
Highlights
- API Documentation Enhancement: I've added comprehensive Swagger (OpenAPI 3.0) annotations to the Application, Admin, and Profile API endpoints and their associated DTOs. This includes detailed descriptions, examples, and schema definitions for clearer API specifications.
- Controller Refactoring for Documentation: I've refactored the
AdminController,ApplicationController, andProfileControllerto implement new dedicated documentation interfaces (AdminControllerDocs,ApplicationControllerDocs,ProfileControllerDocs). This separates API documentation concerns from the controller logic. - Parameter Handling Adjustment: The way
userIdparameters are handled in theApplicationController,ApplicationSchoolController, andProfileControllerhas been updated from a custom@UserIdannotation to the standard@RequestParam Long userId. - Security Annotation Changes (Admin): In the
AdminController, the@PreAuthorizeannotations have been commented out, likely in preparation for moving security definitions to the new documentation interfaces or for testing purposes.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces Swagger documentation for the Admin, Application, and Profile APIs. However, the changes also include several critical issues that need to be addressed: authorization checks have been commented out in AdminController, which poses a significant security risk; there are multiple API changes; the handling of userId is inconsistent; and there are several mismatches between the API documentation and the controller implementations, as well as incorrect schemas for list/paginated responses.
|
|
||
| @GetMapping("/students") | ||
| @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") | ||
| // @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") |
There was a problem hiding this comment.
The @PreAuthorize annotation is commented out, disabling security checks for this admin-only API. This creates a critical security vulnerability and must be restored.
| // @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") | |
| @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") |
| @PathVariable Long applicationSchoolId, | ||
|
|
||
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | ||
| @PathVariable Long userId, |
There was a problem hiding this comment.
The documentation for userId incorrectly uses @PathVariable. The controller implementation uses @RequestParam, meaning it's a query parameter. Remove the @PathVariable annotation.
| @PathVariable Long userId, | |
| Long userId, |
| @Parameter(name = "userId", description = "회원 ID", in = ParameterIn.QUERY) | ||
| @RequestParam Long userId |
There was a problem hiding this comment.
There is a mismatch between the documentation and the implementation for the getProfile method. The documentation specifies userId as a @RequestParam, but the controller implementation uses the custom @UserId annotation. Update the documentation to reflect the actual implementation.
| @Schema(description = "파일 이름", example = "수험표사진이름.png") | ||
| String fileName, | ||
|
|
||
| @Schema(description = "S3 저장 경로 키", example = "") |
There was a problem hiding this comment.
The example for s3Key is an empty string. A realistic example would improve clarity.
| @Schema(description = "S3 저장 경로 키", example = "") | |
| @Schema(description = "S3 저장 경로 키", example = "admission-tickets/c1f8b5-4a2b-4b7e-8e7a-1b2c3d4e5f6a_ticket.png") |
| @Operation(summary = "학교별 도시락 신청 수 조회", description = "학교별 도시락 신청 수를 조회합니다.") | ||
| @ApiResponses(value = { | ||
| @ApiResponse(responseCode = "200", description = "도시락 신청 수 조회 성공", | ||
| content = @Content(schema = @Schema(implementation = SchoolLunchResponse.class))) |
There was a problem hiding this comment.
The method returns a List<SchoolLunchResponse>, but the @Schema annotation describes a single SchoolLunchResponse object. Use @ArraySchema to correctly document a list response.
content = @Content(
mediaType = "application/json",
array = @io.swagger.v3.oas.annotations.media.ArraySchema(
schema = @Schema(implementation = SchoolLunchResponse.class)
)
)| @Operation(summary = "전체 신청 내역 조회", description = "사용자의 전체 신청 내역을 조회합니다.") | ||
| @ApiResponses(value = { | ||
| @ApiResponse(responseCode = "200", description = "신청 내역 조회 성공", | ||
| content = @Content(schema = @Schema(implementation = ApplicationResponse.class))) |
There was a problem hiding this comment.
This method returns a List<ApplicationResponse>, but the documentation schema is for a single ApplicationResponse. Update it to represent an array of responses using @ArraySchema.
content = @Content(
mediaType = "application/json",
array = @io.swagger.v3.oas.annotations.media.ArraySchema(
schema = @Schema(implementation = ApplicationResponse.class)
)
)![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
🧹 Nitpick comments (5)
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationResponse.java (1)
13-14: Consider adding an example for the schools field.While the description is clear, adding an example would improve API documentation consistency with other fields.
- @Schema(description = "신청 학교 목록") + @Schema(description = "신청 학교 목록", example = "[{\"applicationSchoolId\": 1, \"schoolName\": \"대치중학교\"}]")src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentListResponse.java (1)
16-17: Consider standardizing phone number format.The example uses "010-1234-5678" format while related DTOs like
StudentExcelDtouse "01012345678" format. Consider standardizing the format across DTOs.Based on the relevant code snippet from
StudentExcelDto.java(line 16), the format there is "01012345678" without hyphens. Consider using:- @Schema(description = "전화번호", example = "010-1234-5678") + @Schema(description = "전화번호", example = "01012345678")src/main/java/life/mosu/mosuserver/global/util/FileRequest.java (1)
18-19: Improve the example value for s3Key field.The example value for
s3Keyis empty, which doesn't provide meaningful guidance for API consumers. Consider providing a representative S3 key example.- @Schema(description = "S3 저장 경로 키", example = "") + @Schema(description = "S3 저장 경로 키", example = "application/admission-tickets/2025/user123/admission-ticket-20250710.png")src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationFilter.java (1)
7-19: Consider phone number format consistency across DTOs.The phone number example "01012345678" (without hyphens) should be consistent with other DTOs in the codebase. From the ApplicationRequest.java file, I see "010-1234-5678" (with hyphens) is used as an example.
Consider standardizing the phone number format across all DTOs:
- @Schema(description = "전화번호 필터", example = "01012345678") + @Schema(description = "전화번호 필터", example = "010-1234-5678")src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationRequest.java (1)
16-18: Note: Phone number format inconsistency across DTOs.The phone number examples in this file use the hyphenated format "010-1234-5678", while ApplicationFilter.java uses "01012345678" without hyphens. Consider standardizing the format across all DTOs for consistency.
Also applies to: 20-22
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
src/main/java/life/mosu/mosuserver/global/util/FileRequest.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/AdminController.java(4 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/AdminControllerDocs.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java(2 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationFilter.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationListResponse.java(2 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/dto/SchoolLunchResponse.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentExcelDto.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentFilter.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentListResponse.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/application/ApplicationController.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/application/ApplicationControllerDocs.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/application/dto/AddressRequest.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/application/dto/AgreementRequest.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationRequest.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationResponse.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationSchoolRequest.java(2 hunks)src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationSchoolResponse.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolController.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolControllerDocs.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/applicationschool/dto/AdmissionTicketResponse.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/applicationschool/dto/RefundRequest.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/applicationschool/dto/SubjectUpdateRequest.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/profile/ProfileController.java(2 hunks)src/main/java/life/mosu/mosuserver/presentation/profile/ProfileControllerDocs.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/profile/dto/EditProfileRequest.java(2 hunks)src/main/java/life/mosu/mosuserver/presentation/profile/dto/ProfileDetailResponse.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/profile/dto/ProfileRequest.java(2 hunks)src/main/java/life/mosu/mosuserver/presentation/profile/dto/SchoolInfoRequest.java(1 hunks)src/main/java/life/mosu/mosuserver/presentation/profile/dto/SchoolInfoResponse.java(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (9)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/SchoolLunchResponse.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
Schema(12-88)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentExcelDto.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
Schema(12-88)
src/main/java/life/mosu/mosuserver/presentation/applicationschool/dto/AdmissionTicketResponse.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
Schema(12-88)
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationSchoolRequest.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
Schema(12-88)
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationSchoolResponse.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
Schema(12-88)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentExcelDto.java (1)
Schema(10-47)
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationRequest.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
Schema(12-88)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentListResponse.java (1)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentExcelDto.java (1)
Schema(10-47)
src/main/java/life/mosu/mosuserver/presentation/admin/AdminControllerDocs.java (2)
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
Schema(12-88)src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentExcelDto.java (1)
Schema(10-47)
🔇 Additional comments (81)
src/main/java/life/mosu/mosuserver/presentation/admin/AdminController.java (1)
32-32: Good: API documentation interface implementationThe controller now implements
AdminControllerDocsinterface, which centralizes Swagger documentation and improves API documentation consistency.src/main/java/life/mosu/mosuserver/presentation/application/dto/AddressRequest.java (1)
3-3: Well-implemented Swagger annotationsThe added
@Schemaannotations provide comprehensive API documentation with clear descriptions and realistic examples. The Korean descriptions are consistent with the project's internationalization approach.Also applies to: 6-6, 9-10, 12-13, 15-16
src/main/java/life/mosu/mosuserver/presentation/profile/dto/SchoolInfoRequest.java (1)
3-3: Excellent Swagger documentation implementationThe
@Schemaannotations are well-structured with appropriate Korean descriptions and realistic examples. The school-related examples ("서울고등학교", Korean address format) are contextually appropriate.Also applies to: 6-6, 9-10, 12-13, 15-16
src/main/java/life/mosu/mosuserver/presentation/profile/dto/SchoolInfoResponse.java (2)
3-3: Consistent and well-structured Swagger annotationsThe
@Schemaannotations are properly aligned with the correspondingSchoolInfoRequestDTO, maintaining consistency between request and response models. The Korean descriptions and examples are appropriate for the domain.Also applies to: 6-6, 9-10, 12-13, 15-16
20-29: Improved code formattingThe
from()method has been reformatted for better readability while maintaining the same functionality, including proper null checking.src/main/java/life/mosu/mosuserver/presentation/applicationschool/dto/RefundRequest.java (2)
3-3: Comprehensive Swagger documentation for refund operationsThe
@Schemaannotations provide clear descriptions and realistic examples for refund-related fields. The Korean descriptions are consistent with the project's localization approach, and the examples (refund reason, boolean agreement, ISO 8601 timestamp) are appropriate for the domain.Also applies to: 7-7, 10-11, 13-14, 16-17
3-5: Improved import organizationThe imports have been reordered to include the Swagger annotation import in a logical sequence, improving code organization.
src/main/java/life/mosu/mosuserver/presentation/admin/dto/SchoolLunchResponse.java (3)
3-3: Good addition of OpenAPI import.The import statement is correctly added for Swagger annotations.
5-5: Clear class-level schema description.The Korean description appropriately identifies this as a response DTO for school lunch application counts.
8-12: Well-documented field schemas.Both fields have clear descriptions with realistic examples. The
schoolNameexample "서울고등학교" andcountexample "42" are appropriate for the context.src/main/java/life/mosu/mosuserver/presentation/applicationschool/dto/SubjectUpdateRequest.java (3)
3-3: Appropriate OpenAPI import addition.The import is correctly added for Swagger schema annotations.
7-7: Clear DTO description.The Korean description properly identifies this as a subject update request DTO.
10-15: Comprehensive field documentation.The subjects field annotation is well-structured with:
- Clear description mentioning it contains Subject enum values
- Realistic example showing actual enum values
- Proper required = true marking for mandatory field
src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentExcelDto.java (3)
3-3: Correct OpenAPI import.The import statement is properly added for Swagger annotations.
10-10: Appropriate class schema description.The Korean description correctly identifies this as a student Excel download DTO.
15-45: Comprehensive field documentation.All fields are well-documented with:
- Clear Korean descriptions
- Realistic examples appropriate for each field type
- Proper enum value examples for
educationLevelandgrade- Date format specification for
birthDate- Consistent formatting across all fields
The annotations complement the existing
@ExcelColumnannotations without conflicts.src/main/java/life/mosu/mosuserver/presentation/profile/dto/ProfileRequest.java (3)
4-4: Proper OpenAPI import addition.The import is correctly added for Swagger schema annotations.
16-16: Clear class description.The Korean description properly identifies this as a profile registration request DTO.
19-47: Excellent field documentation.All fields are thoroughly documented with:
- Clear Korean descriptions
- Realistic examples appropriate for Korean context
- Proper required field marking
- Enum value examples for
gender,education, andgrade- Date format specification for
birth- Implementation reference for complex
schoolInfoobject- Korean phone number format example
The annotations work well with existing validation annotations without conflicts.
src/main/java/life/mosu/mosuserver/presentation/application/dto/AgreementRequest.java (3)
3-3: Appropriate OpenAPI import.The import statement is correctly added for Swagger annotations.
5-5: Clear class description.The Korean description appropriately identifies this as an agreement request DTO.
8-12: Well-documented boolean fields.Both fields have clear descriptions explaining their purpose:
agreedToNoticesfor notice acknowledgment and agreementagreedToRefundPolicyfor refund policy agreementThe boolean examples are appropriate and consistent.
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationSchoolRequest.java (7)
3-3: LGTM: Swagger import added correctly.The OpenAPI import is properly placed and will enable the schema annotations used throughout the file.
17-17: LGTM: Record-level schema annotation is well-structured.The description clearly identifies this as an application school request DTO in Korean.
20-22: LGTM: School name field annotation is appropriate.The description and example value ("대치중학교") are realistic and clear for API documentation.
24-25: LGTM: Area field annotation provides good context.The description explains the expected format with examples (DAECHI, NOWON, MOKDONG) and provides a realistic example.
27-29: LGTM: Exam date field annotation is clear.The description and example date format (2025-08-10) are appropriate for API documentation.
31-33: LGTM: Lunch field annotation provides helpful options.The description clearly indicates the possible values (NONE or OPTION1) with a realistic example.
35-37: LGTM: Subjects field annotation is well-documented.The description provides a specific example of subject format (PHYSICS_1) and shows the expected array structure with realistic subject examples.
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationResponse.java (4)
3-3: LGTM: Swagger import added correctly.The OpenAPI import is properly placed and enables the schema annotations used throughout the file.
7-7: LGTM: Record-level schema annotation is clear.The description appropriately identifies this as an application response DTO in Korean.
10-11: LGTM: Application ID field annotation is appropriate.The description and example value (1) are realistic and clear for API documentation.
18-27: LGTM: Static factory method formatting improvements.The minor formatting adjustments in the static method improve readability without changing the logic.
src/main/java/life/mosu/mosuserver/presentation/applicationschool/dto/AdmissionTicketResponse.java (8)
3-3: LGTM: Swagger import added correctly.The OpenAPI import is properly placed and enables the schema annotations used throughout the file.
7-7: LGTM: Record-level schema annotation is clear.The description appropriately identifies this as an admission ticket response DTO in Korean.
10-11: LGTM: Admission ticket image URL field annotation is well-structured.The description and example URL are realistic and clearly demonstrate the expected format for S3 bucket storage.
13-14: LGTM: User name field annotation is appropriate.The description and example value ("홍길동") are realistic and clear for API documentation.
16-17: LGTM: Birth date field annotation is clear.The description and example date format (2005-05-10) are appropriate for API documentation.
19-20: LGTM: Examination number field annotation is well-documented.The description and example value ("20250001") provide clear guidance on the expected format.
22-23: LGTM: Subjects field annotation provides realistic examples.The description and example array with Korean subject names ("생명과학", "지구과학") are appropriate for the Korean educational context.
25-26: LGTM: School name field annotation is consistent.The description and example value ("대치중학교") are consistent with other DTOs in the codebase and provide clear guidance.
src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentListResponse.java (9)
3-3: LGTM: Swagger import added correctly.The OpenAPI import is properly placed and enables the schema annotations used throughout the file.
7-7: LGTM: Record-level schema annotation is clear.The description appropriately identifies this as a student list response DTO in Korean.
10-11: LGTM: Name field annotation is appropriate.The description and example value ("홍길동") are realistic and clear for API documentation.
13-14: LGTM: Birth date field annotation is well-documented.The description includes the expected format (yyyy-MM-dd) and provides a realistic example.
19-20: LGTM: Gender field annotation is clear.The description and example value ("남자") are appropriate for API documentation.
22-23: LGTM: Education level field annotation is appropriate.The description and example value ("ENROLLED") provide clear guidance on the expected enum value.
25-26: LGTM: School name field annotation is consistent.The description and example value ("서울고등학교") are consistent with other DTOs in the codebase.
28-29: LGTM: Grade field annotation is well-documented.The description and example value ("HIGH_1") provide clear guidance on the expected enum value.
31-32: LGTM: Exam count field annotation is clear.The description and example value (2) are appropriate for API documentation.
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationSchoolResponse.java (9)
3-3: LGTM: Swagger import added correctly.The OpenAPI import is properly placed and enables the schema annotations used throughout the file.
10-10: LGTM: Record-level schema annotation is clear.The description appropriately identifies this as an application school response DTO in Korean.
13-14: LGTM: Application school ID field annotation is appropriate.The description and example value (1) are realistic and clear for API documentation.
16-17: LGTM: Area field annotation is well-documented.The description and example value ("대치") are appropriate and consistent with the domain context.
19-20: LGTM: Exam date field annotation is clear.The description and example date format (2025-08-10) are appropriate for API documentation.
22-23: LGTM: School name field annotation is consistent.The description and example value ("대치중학교") are consistent with other DTOs in the codebase.
25-26: LGTM: Lunch field annotation is well-documented.The description and example value ("신청 안 함") provide clear guidance on the expected localized format.
28-29: LGTM: Examination number field annotation is appropriate.The description and example value ("20250001") are consistent with other DTOs and provide clear guidance.
31-32: LGTM: Subjects field annotation provides realistic examples.The description and example array with Korean subject names ("생활과 윤리", "정치와 법") are appropriate for the Korean educational context.
src/main/java/life/mosu/mosuserver/global/util/FileRequest.java (1)
3-3: LGTM! Swagger annotations are properly added.The Swagger annotations are well-structured with appropriate descriptions in Korean and meaningful examples. This enhances API documentation quality.
Also applies to: 12-12, 15-15
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationExcelDto.java (1)
3-3: LGTM! Comprehensive Swagger documentation added.Excellent work on adding comprehensive Swagger documentation to all fields in the Excel DTO. The descriptions are clear and the examples are realistic and helpful for API consumers.
Also applies to: 12-12, 17-88
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationListResponse.java (1)
3-3: LGTM! Comprehensive Swagger documentation added.The Swagger annotations are well-implemented with clear descriptions and relevant examples. The documentation covers all aspects of the application list response data structure effectively.
Also applies to: 14-74
src/main/java/life/mosu/mosuserver/presentation/profile/dto/ProfileDetailResponse.java (2)
3-3: LGTM! Swagger annotations properly added.The Swagger annotations are comprehensive with clear descriptions and appropriate examples. The documentation enhances API usability for profile-related endpoints.
Also applies to: 10-39
42-54: LGTM! Code formatting improved.The reformatting of the static factory method improves readability while maintaining the same functionality.
src/main/java/life/mosu/mosuserver/presentation/admin/dto/StudentFilter.java (1)
3-3: LGTM! Swagger annotations and formatting improved.The Swagger annotations are well-implemented with clear descriptions and examples. The separation of
@PhoneNumberPatternannotation on line 13 improves readability. ThedefaultValuespecification for theorderfield is particularly helpful.Also applies to: 6-18
src/main/java/life/mosu/mosuserver/presentation/profile/dto/EditProfileRequest.java (2)
3-3: LGTM: Appropriate imports added for Swagger annotations.The Schema and LocalDate imports are correctly added to support the new API documentation annotations.
Also applies to: 6-6
14-14: LGTM: Comprehensive Swagger documentation added.The @Schema annotations provide clear descriptions and appropriate examples for all fields. The required flags correctly match the validation annotations (@notblank, @NotNull).
Also applies to: 17-44
src/main/java/life/mosu/mosuserver/presentation/admin/dto/ApplicationFilter.java (1)
3-3: LGTM: Appropriate imports added for Swagger annotations.The Schema and PhoneNumberPattern imports are correctly added to support the new API documentation annotations.
Also applies to: 5-5
src/main/java/life/mosu/mosuserver/presentation/application/dto/ApplicationRequest.java (2)
3-3: LGTM: Appropriate imports and class-level documentation.The Schema import and class-level @Schema annotation are correctly added to support comprehensive API documentation.
Also applies to: 10-10
13-31: LGTM: Well-structured field documentation.The @Schema annotations provide clear descriptions and appropriate examples. The required flags correctly match the validation annotations (@NotNull for schools and agreementRequest).
src/main/java/life/mosu/mosuserver/presentation/application/ApplicationControllerDocs.java (2)
20-21: LGTM: Well-structured API documentation interface.The @tag annotation provides clear categorization for the API endpoints, and the interface structure follows good documentation practices.
27-32: LGTM: Comprehensive API documentation.The @operation and @apiresponse annotations provide detailed documentation for both endpoints, including parameter descriptions and response schemas.
Also applies to: 40-42
src/main/java/life/mosu/mosuserver/presentation/application/ApplicationController.java (2)
12-12: LGTM: Appropriate imports and interface implementation.The imports for ResponseEntity and RequestParam are correctly added, and the controller properly implements the ApplicationControllerDocs interface.
Also applies to: 18-18, 25-25
37-37: LGTM: Proper ResponseEntity wrapping.The responses are correctly wrapped in ResponseEntity.ok() with appropriate HTTP status codes and success messages.
Also applies to: 46-47
src/main/java/life/mosu/mosuserver/presentation/profile/ProfileController.java (1)
27-27: Good implementation of documentation interface pattern.The controller now implements the
ProfileControllerDocsinterface, which centralizes API documentation and improves maintainability.src/main/java/life/mosu/mosuserver/presentation/profile/ProfileControllerDocs.java (1)
20-21: Well-structured API documentation interface.The interface provides comprehensive Swagger documentation with appropriate tags and descriptions.
src/main/java/life/mosu/mosuserver/presentation/admin/AdminControllerDocs.java (3)
23-24: Well-structured admin API documentation interface.The interface provides comprehensive documentation for administrative endpoints with clear descriptions and proper grouping.
35-36: Appropriate use of hidden parameters.The
@Parameter(hidden = true)annotation is correctly used forPageableparameters, which are typically handled by Spring's pagination framework and don't need to be exposed in the API documentation.Also applies to: 63-64
43-45: Correct exception handling for file downloads.The
throws IOExceptiondeclaration is appropriate for Excel download methods that involve file operations.Also applies to: 71-73
src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolController.java (1)
27-27: Good implementation of documentation interface pattern.The controller now implements the
ApplicationSchoolControllerDocsinterface, following the same pattern as other controllers in this PR.src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolControllerDocs.java (1)
21-22: Well-structured API documentation interface.The interface provides comprehensive documentation for application school endpoints with clear descriptions.
|
|
||
| @GetMapping("/students") | ||
| @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") | ||
| // @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Critical Security Issue: Authorization checks removed
All @PreAuthorize annotations have been commented out, effectively removing admin role-based access control from sensitive endpoints. This creates a significant security vulnerability as these endpoints handle:
- Student personal information
- Application data
- Excel file downloads with sensitive data
Either uncomment these annotations or verify that authorization is properly handled elsewhere in the application:
-// @PreAuthorize("isAuthenticated() and hasRole('ADMIN')")
+ @PreAuthorize("isAuthenticated() and hasRole('ADMIN')")Let me verify if there's alternative authorization handling:
Also applies to: 47-47, 65-65, 73-73, 83-83
🏁 Script executed:
#!/bin/bash
# Check if there's alternative authorization handling in the codebase
rg -A 5 "AdminController\|admin.*security\|admin.*auth" --type javaLength of output: 69
I’ll check for global method-security setup and any existing security configuration:
🏁 Script executed:
#!/bin/bash
echo "Checking for global method-security annotations..."
rg -n "@EnableGlobalMethodSecurity" -t java
rg -n "@EnableMethodSecurity" -t java
echo "Searching for a SecurityConfig class..."
rg -n "class .*SecurityConfig" -t java
echo "Listing all @PreAuthorize annotations in the codebase..."
rg -n "@PreAuthorize" -t javaLength of output: 1641
Restore Admin Role Checks in AdminController
The application enables method-level security (@EnableMethodSecurity in SecurityConfig), but all @PreAuthorize annotations in AdminController have been commented out—leaving sensitive admin endpoints unprotected. There’s no URL-based restriction for /admin/** in the security configuration, so these methods must enforce admin access explicitly.
Please uncomment the security annotations at the following locations:
- src/main/java/life/mosu/mosuserver/presentation/admin/AdminController.java
• Line 37
• Line 47
• Line 65
• Line 73
• Line 83
Example diff for each occurrence:
-// @PreAuthorize("isAuthenticated() and hasRole('ADMIN')")
+ @PreAuthorize("isAuthenticated() and hasRole('ADMIN')")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") | |
| @PreAuthorize("isAuthenticated() and hasRole('ADMIN')") |
🤖 Prompt for AI Agents
In src/main/java/life/mosu/mosuserver/presentation/admin/AdminController.java at
lines 37, 47, 65, 73, and 83, uncomment the @PreAuthorize annotations that
enforce admin role checks. This will restore method-level security on sensitive
admin endpoints by ensuring only authenticated users with the ADMIN role can
access these methods.
| @Operation(summary = "신청 등록", description = "사용자가 신청을 진행합니다.") | ||
| @ApiResponses(value = { | ||
| @ApiResponse(responseCode = "200", description = "신청 성공") | ||
| }) | ||
| ResponseEntity<ApiResponseWrapper<ApplicationResponse>> apply( | ||
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | ||
| @RequestParam Long userId, | ||
|
|
||
| @Parameter(description = "신청 요청 정보", required = true) | ||
| @Valid @RequestBody ApplicationRequest request | ||
| ); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Security concern: User ID handling in query parameters.
The interface defines userId as a @RequestParam, which means it will be passed as a query parameter. This could be a security issue if users can manipulate the userId in the URL to access other users' data.
Verify that the authentication/authorization mechanism properly validates that the requesting user can only access their own data, regardless of the userId parameter:
If the previous @userid annotation was extracting the user ID from the authentication context, consider reverting to that approach or implementing proper authorization checks.
Also applies to: 35-43
🏁 Script executed:
#!/bin/bash
# Check how userId is validated in the authentication/authorization layer
rg -A 10 -B 5 "PreAuthorize.*USER" --type java
rg -A 10 -B 5 "@UserId" --type javaLength of output: 6775
Enforce authentication-based userId injection instead of query parameter
The current docs and implementation accept userId as a query param—even though the controller is protected with
@PreAuthorize("isAuthenticated() and hasRole('USER')"), a malicious user could supply someone else’s ID. We should bind the userId directly from the security context (as other controllers do with @UserId) and hide it from the public API.
• In ApplicationControllerDocs.java (L23–33 & L35–43), replace:
- @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
- @RequestParam Long userId,
+ @Parameter(hidden = true)
+ @UserId Long userId,• In ApplicationController.java, update the method signature accordingly:
- public ResponseEntity<ApiResponseWrapper<ApplicationResponse>> apply(
- @RequestParam Long userId,
+ public ResponseEntity<ApiResponseWrapper<ApplicationResponse>> apply(
+ @UserId Long userId,
@Valid @RequestBody ApplicationRequest request
) { … }• See ProfileController and ApplicationSchoolController for examples of @UserId usage.
This change ensures the userId is always taken from the authenticated principal, eliminating any risk of ID swapping.
🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/application/ApplicationControllerDocs.java
around lines 23 to 33 and 35 to 43, the userId is currently accepted as a query
parameter, which poses a security risk. Remove the userId query parameter and
instead annotate the method parameter with @UserId to inject the authenticated
user's ID from the security context. Update the method signature to no longer
accept userId as a request parameter and ensure the API documentation reflects
this change by hiding userId from the public API. Follow the pattern used in
ProfileController and ApplicationSchoolController for correct @UserId usage.
| public ResponseEntity<ApiResponseWrapper<ApplicationResponse>> apply( | ||
| @RequestParam Long userId, | ||
| @Valid @RequestBody ApplicationRequest request | ||
| ) { | ||
| ApplicationResponse response = applicationService.apply(userId, request); | ||
| return ApiResponseWrapper.success(HttpStatus.OK, "신청 성공", response); | ||
| return ResponseEntity.ok(ApiResponseWrapper.success(HttpStatus.OK, "신청 성공", response)); | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Security concern: User ID parameter validation.
The change from @UserId to @RequestParam for the userId parameter could be a security vulnerability. Users might be able to pass any userId in the query parameters to access other users' data.
Verify that the PreAuthorize annotation or authentication mechanism properly validates that the requesting user can only access their own data:
Consider implementing an authorization check that validates the userId parameter against the authenticated user's ID, or revert to using @userid if it was extracting the user ID from the authentication context.
Also applies to: 42-48
🏁 Script executed:
#!/bin/bash
# Check the PreAuthorize implementation and how it validates userId
rg -A 15 -B 5 "PreAuthorize.*isAuthenticated.*USER" --type java
rg -A 10 -B 5 "SecurityContext\|Authentication" --type javaLength of output: 2757
🏁 Script executed:
#!/bin/bash
# Locate the ApplicationService implementation
APPLICATION_SERVICE_FILE=$(rg -l "class ApplicationService" --type java)
echo "----- File: $APPLICATION_SERVICE_FILE -----"
# Show imports and class declaration
sed -n '1,50p' "$APPLICATION_SERVICE_FILE"
# Inspect the apply(...) method
rg -A10 -B5 "apply(" "$APPLICATION_SERVICE_FILE"
# Inspect the getApplications(...) method
rg -A10 -B5 "getApplications(" "$APPLICATION_SERVICE_FILE"
# Check for any manual SecurityContextHolder usage
rg "SecurityContextHolder" "$APPLICATION_SERVICE_FILE"Length of output: 3462
🏁 Script executed:
#!/bin/bash
# Inspect apply method implementation
rg -A20 -B5 --fixed-strings "public ApplicationResponse apply(" src/main/java/life/mosu/mosuserver/application/application/ApplicationService.java
# Inspect getApplications method implementation
rg -A20 -B5 --fixed-strings "public List<ApplicationResponse> getApplications(" src/main/java/life/mosu/mosuserver/application/application/ApplicationService.java
# Check for SecurityContextHolder usage across the repository
rg -n "SecurityContextHolder" -l
# Check for custom @UserId annotation definitions or usages
rg -n "@UserId" -lLength of output: 3067
Enforce User-ID Authorization on Application Endpoints
Currently both apply(...) and getApplications(...) are secured only by
@PreAuthorize("isAuthenticated() and hasRole('USER')")but take a client-supplied @RequestParam Long userId without verifying it matches the authenticated user’s ID. This allows any authenticated user to act on or view another user’s data.
• In ApplicationController.java, replace the raw @RequestParam Long userId with your custom @UserId annotation (backed by UserIdArgumentResolver), or explicitly fetch the principal’s ID via SecurityContextHolder.getContext().getAuthentication() and compare it to the userId parameter.
• Throw a CustomRuntimeException (e.g. ErrorCode.UNAUTHORIZED_ACCESS) if they differ.
• Ensure the same check is applied in every endpoint that currently accepts @RequestParam Long userId.
Example using SecurityContextHolder:
@PostMapping
@PreAuthorize("isAuthenticated() and hasRole('USER')")
public ResponseEntity<ApiResponseWrapper<ApplicationResponse>> apply(
@RequestParam Long userId,
@Valid @RequestBody ApplicationRequest request
) {
Long authenticatedUserId = ((CustomUserDetails) SecurityContextHolder
.getContext().getAuthentication().getPrincipal()).getId();
if (!authenticatedUserId.equals(userId)) {
throw new CustomRuntimeException(ErrorCode.UNAUTHORIZED_ACCESS);
}
ApplicationResponse response = applicationService.apply(userId, request);
return ResponseEntity.ok(ApiResponseWrapper.success(HttpStatus.OK, "신청 성공", response));
}Apply the same pattern to getApplications(...).
🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/application/ApplicationController.java
around lines 32 to 38, the apply method accepts a userId parameter from the
client without verifying it matches the authenticated user's ID, which risks
unauthorized access. To fix this, retrieve the authenticated user's ID from
SecurityContextHolder, compare it with the userId parameter, and throw a
CustomRuntimeException with ErrorCode.UNAUTHORIZED_ACCESS if they differ. Apply
this same authorization check to all other endpoints like getApplications that
accept userId as a parameter.
| public ResponseEntity<ApiResponseWrapper<Void>> update( | ||
| @RequestParam Long userId, | ||
| @Valid @RequestBody EditProfileRequest request | ||
| ) { | ||
| profileService.editProfile(userId, request); | ||
| return ApiResponseWrapper.success(HttpStatus.OK, "프로필 수정 성공"); | ||
| return ResponseEntity.ok(ApiResponseWrapper.success(HttpStatus.OK, "프로필 수정 성공")); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Same inconsistency in parameter binding.
The update method also changed from @UserId to @RequestParam, but this is inconsistent with the getProfile method.
Apply the same standardization as suggested for the create method.
🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/profile/ProfileController.java
around lines 42 to 47, the update method uses @RequestParam for userId, which is
inconsistent with the getProfile method. Change the userId parameter annotation
from @RequestParam to @UserId to standardize parameter binding across methods as
done in the create method.
| public ResponseEntity<ApiResponseWrapper<ProfileDetailResponse>> getProfile( | ||
| @UserId Long userId) { | ||
| ProfileDetailResponse response = profileService.getProfile(userId); | ||
| return ApiResponseWrapper.success(HttpStatus.OK, "프로필 조회 성공", response); | ||
| return ResponseEntity.ok(ApiResponseWrapper.success(HttpStatus.OK, "프로필 조회 성공", response)); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Inconsistent with other methods in the same controller.
This method still uses @UserId annotation while create and update methods use @RequestParam. This inconsistency should be resolved.
🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/profile/ProfileController.java
around lines 51 to 54, the getProfile method uses the @UserId annotation for the
userId parameter, which is inconsistent with the create and update methods that
use @RequestParam. To fix this, replace the @UserId annotation with
@RequestParam on the userId parameter in the getProfile method to maintain
consistency across the controller methods.
| public ResponseEntity<ApiResponseWrapper<ApplicationSchoolResponse>> getDetail( | ||
| @UserId Long userId, | ||
| @PathVariable("applicationSchoolId") Long applicationSchoolId | ||
| ) { | ||
| ApplicationSchoolResponse response = applicationSchoolService.getApplicationSchool( | ||
| applicationSchoolId); | ||
| return ApiResponseWrapper.success(HttpStatus.OK, "신청 상세 조회 성공", response); | ||
| return ResponseEntity.ok( | ||
| ApiResponseWrapper.success(HttpStatus.OK, "신청 상세 조회 성공", response)); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Inconsistent with other methods in the same controller.
This method still uses @UserId annotation while cancelApplicationSchool and updateSubjects methods use @RequestParam.
🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolController.java
around lines 54 to 61, the getDetail method uses the @UserId annotation for the
userId parameter, which is inconsistent with other methods like
cancelApplicationSchool and updateSubjects that use @RequestParam. To fix this,
change the userId parameter annotation in getDetail from @UserId to
@RequestParam to maintain consistency across the controller methods.
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | ||
| @PathVariable Long userId, |
There was a problem hiding this comment.
Critical parameter annotation mismatch.
The documentation declares userId as @PathVariable but the controller implementation uses @RequestParam (line 34 in ApplicationSchoolController.java). This mismatch will cause the API documentation to be incorrect.
- @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
- @PathVariable Long userId,
+ @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
+ @RequestParam Long userId,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | |
| @PathVariable Long userId, | |
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | |
| @RequestParam Long userId, |
🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolControllerDocs.java
around lines 32 to 33, the parameter `userId` is incorrectly annotated as a
`@PathVariable` in the documentation, while the actual controller uses
`@RequestParam`. To fix this, change the annotation on `userId` from
`@PathVariable` to `@RequestParam` in the documentation to match the controller
implementation and ensure accurate API docs.
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | ||
| @PathVariable Long userId, |
There was a problem hiding this comment.
Same critical parameter annotation mismatch.
The documentation declares userId as @PathVariable but the controller implementation uses @RequestParam.
- @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
- @PathVariable Long userId,
+ @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
+ @RequestParam Long userId,🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolControllerDocs.java
around lines 48 to 49, the parameter annotation for userId is mismatched between
the documentation and the controller implementation. The documentation uses
@PathVariable while the controller uses @RequestParam. To fix this, update the
documentation annotation to use @RequestParam for userId to match the controller
method signature and ensure consistency.
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | ||
| @PathVariable Long userId, |
There was a problem hiding this comment.
Same parameter annotation mismatch.
The documentation declares userId as @PathVariable but the controller implementation uses @UserId.
- @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
- @PathVariable Long userId,
+ @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
+ @UserId Long userId,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | |
| @PathVariable Long userId, | |
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | |
| @UserId Long userId, |
🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolControllerDocs.java
around lines 74 to 75, the parameter annotation for userId is inconsistent; the
documentation uses @PathVariable while the controller uses @UserId. Update the
annotation in the documentation to match the controller by replacing
@PathVariable with @UserId to ensure consistency between the docs and
implementation.
| @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY) | ||
| @PathVariable Long userId, |
There was a problem hiding this comment.
Parameter annotation mismatch with controller implementation.
The documentation declares userId as @PathVariable but the controller implementation uses @UserId (line 55 in ApplicationSchoolController.java).
- @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
- @PathVariable Long userId,
+ @Parameter(name = "userId", description = "사용자 ID", in = ParameterIn.QUERY)
+ @UserId Long userId,🤖 Prompt for AI Agents
In
src/main/java/life/mosu/mosuserver/presentation/applicationschool/ApplicationSchoolControllerDocs.java
around lines 61 to 62, the parameter annotation for userId is incorrectly
declared as @PathVariable while the actual controller uses @UserId. Update the
@Parameter annotation to match the controller by removing or replacing
@PathVariable with the correct annotation that corresponds to @UserId, ensuring
consistency between the documentation and implementation.
✨ 구현한 기능
📢 논의하고 싶은 내용
🎸 기타
Summary by CodeRabbit
New Features
Refactor
Documentation