-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Job Posting Functionality Implementation #50
base: main
Are you sure you want to change the base?
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the job post, the client can add required skills for the job, but you missed implementing that
…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. |
|
Feature: Job Posting Functionality
Closes #37
Closes #51
This PR introduces the core functionality for job posting, including:
To test:
/api/jobs/post
with a valid JSON payload.Please review the code changes and unit tests.