Job Posting Functionality Implementation #50
Conversation
This commit introduces the Job model representing job postings in the application. It includes fields for title, description, budget, job type, status, and creation timestamp.
This commit defines the JobStatus enum with possible values for the status of a job posting: - OPEN: Job is open for applications. - CLOSED: Job is no longer accepting applications. - IN_PROGRESS: Job has been awarded and work is ongoing.
This commit defines the JobType enum with possible types for a job posting: - HOURLY: Job is billed by the hour. - FIXED: Job has a fixed price.
- Added JobDTO class to encapsulate job data for transfer between layers. - Contains fields for job attributes including id, title, description, budget, job type, status, and creation timestamp. - Utilizes Lombok's @DaTa annotation for automatic getter/setter generation.
- Created JobService interface to outline methods for job-related operations. - Added createJob method to facilitate the creation of a new Job using JobDTO.
- Created JobMapper class to handle conversion between Job and JobDTO objects. - Implemented mapTo method to convert Job to JobDTO. - Implemented mapFrom method to convert JobDTO to Job. - Ensured that all relevant fields are mapped correctly for seamless data transfer.
- Added getCurrentUserId method to retrieve the ID of the currently authenticated user. - Utilized SecurityContextHolder to access authentication details. - Checked for non-null authentication and user authentication status before returning the user ID. - Returns null if no authenticated user is found, ensuring safe handling of authentication context.
- Integrated JobRepository and UserRepository into JobServiceImpl to manage job creation. - Implemented createJob method to map JobDTO to Job entity and associate it with the current authenticated user. - Utilized AuthService to retrieve the current user's ID and fetch the corresponding User. - Included error handling to throw an exception if the user is not found. - Saved the newly created job entity in the database.
- Added createJob endpoint to handle job creation requests. - Integrated JobService for business logic. - Included necessary validations for user authentication and job data. - Updated exception handling for better error responses.
- Updated field name for clarity and consistency. - Ensured that the 'jobId' field accurately represents the job identifier.
- Renamed 'id' to 'jobId' to accurately represent the job identifier. - Changed 'jobStatus' to 'status' for clarity and to match the JobDTO class.
… first letter - Renamed enum constants to follow Java naming conventions: `In_Progress` to `InProgress` - Ensured consistency in naming style across the application
…irst letter - Updated enum constants to follow Java naming conventions
…n and retrieval - Throw IllegalStateException if the user is not authenticated - Throw IllegalArgumentException if the user is not found in the database
- Implemented tests for createJob method, covering success and error scenarios. - Verified user authentication and user existence checks. - Used Mockito to mock dependencies and assert expected behavior.
- Previously, the code assumed roles in the request body were valid. This commit updates the logic to:
- Extract role names from the "roles" key in the request body.
- Throw a `RuntimeException` if the user or any requested role is not found.
- Modified the `assignRolesToUser` test to work with the new implementation that accepts a list of role names. - Updated the test to populate the roles map with a list of roles, ensuring compatibility with the revised method. - Verified that roles are correctly assigned to the user and that the user repository is called as expected.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
When creating a Job, the jobId, status, and createdAt fields are not needed in the POST request body. Could you please create a separate DTO for creating a Job that excludes these fields? Thanks!
Also, the createdAt field is set to null; please make sure it is initialized.
…ers.sql to V5__Create_user_profile_to_all_inserted_users.sql to fix a typo in the filename.
…t reflectd the JobService.
- Refactor method signature and chained method calls in buildResponseEntity to adhere to 120-character line limit. - Improve code readability and maintain consistency with Checkstyle formatting rules.
I think adding the required skills should be implemented in a separate endpoint to avoid complexity and keep the responsibilities of each API call clear and manageable. This approach would make it easier to maintain and extend the functionality if needed. |
I think it’d be a good idea to keep the required skills in the same endpoint. Splitting it into a separate endpoint could make things unnecessarily complicated. We could let clients select from a list of matching skills, and if they don’t find what they need, they can create a new skill on the spot. This way, we’ll also reduce the number of API calls. |
ok, i will implement it. |
There was a problem hiding this comment.
Copilot reviewed 6 out of 15 changed files in this pull request and generated no suggestions.
Files not reviewed (9)
- src/test/java/com/activecourses/upwork/service/RoleServiceImplTest.java: Evaluated as low risk
- src/main/java/com/activecourses/upwork/service/authentication/AuthService.java: Evaluated as low risk
- src/main/java/com/activecourses/upwork/service/role/RoleServiceImpl.java: Evaluated as low risk
- src/main/java/com/activecourses/upwork/service/authentication/AuthServiceImpl.java: Evaluated as low risk
- src/test/java/com/activecourses/upwork/service/JobServiceImplTest.java: Evaluated as low risk
- src/main/java/com/activecourses/upwork/model/JobType.java: Evaluated as low risk
- src/main/java/com/activecourses/upwork/mapper/JobMapper.java: Evaluated as low risk
- src/main/java/com/activecourses/upwork/dto/JobDTO.java: Evaluated as low risk
- src/main/java/com/activecourses/upwork/model/JobStatus.java: Evaluated as low risk
…rofile - Implemented the Skill entity to map the `skills` table in the database. - Established a @manytomany relationship between Skill and Job via the `job_skills` table. - Configured a @manytomany relationship between Skill and UserProfile via the `user_skills` table. - Added fields for `id`, `name`, and relevant relationships in the Skill entity. This change enables the proper management of skills associated with jobs and user profiles.
feat: implement job posting functionality with skill association
- Created a Flyway migration script `V6__Add_test_skills.sql`. - Inserted four sample skills: 'Java', 'Spring Boot', 'Angular', and 'PostgreSQL'. - These skills will be used for testing job posting functionality.
- Mock SkillRepository to simulate fetching skills by ID. - Add test cases for handling skill association in createJob: - Verify successful creation with valid skills. - Ensure appropriate exceptions are thrown for missing skills. - Update existing tests to account for new skill-related logic. - Validate that the Job object includes the correct number of associated skills.
- Adjusted the indentation level for the `.orElseThrow()` line to improve code readability. - Ensures consistent formatting and alignment with the project's coding standards.
Feature: Job Posting Functionality
Closes #37
Closes #51
This PR introduces the core functionality for job posting, including:
To test:
/api/jobs/postwith a valid JSON payload.Please review the code changes and unit tests.