Skip to content
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

Open
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

AhmedFatthy1040
Copy link
Collaborator

@AhmedFatthy1040 AhmedFatthy1040 commented Oct 28, 2024

Feature: Job Posting Functionality

Closes #37
Closes #51

This PR introduces the core functionality for job posting, including:

  • Job Entity: Defines the structure of a job.
  • Job Repository: Provides data access for jobs.
  • Job Service: Handles job-related business logic.
  • Job Controller: Exposes REST endpoints for job management.
  • Job DTO: Defines data transfer objects for jobs.
  • Security: Implements role-based access control for job operations.

To test:

  1. Start the application.
  2. Send a POST request to /api/jobs/post with a valid JSON payload.
  3. Verify job creation and retrieval.

Please review the code changes and unit tests.

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.
AhmedMohamedAbdelaty

This comment was marked as resolved.

Copy link
Collaborator

@AhmedMohamedAbdelaty AhmedMohamedAbdelaty left a 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.

Copy link
Collaborator

@AhmedYahia74 AhmedYahia74 left a 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.
- 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.
@AhmedFatthy1040
Copy link
Collaborator Author

In the job post, the client can add required skills for the job, but you missed implementing that

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.

@AhmedMohamedAbdelaty
Copy link
Collaborator

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.

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.

@AhmedFatthy1040
Copy link
Collaborator Author

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.

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.
GE7ZklXXcAAY3Ug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SQL migration file does not follow the Flyway filename convention Implement Job Posting Functionality
3 participants