Update employee API permissions for profile access#1527
Conversation
Modified permission callbacks to allow users to view and update their own employee profile and photo, in addition to users with specific capabilities. Authenticated users can now upload their own profile photo, improving usability and access control.
When 'job_histories' or 'histories' is included in the request, the API now returns employment, compensation, and job history fields for employees. This provides more detailed historical data for frontend consumption.
The delete_employee method now supports a 'force' parameter to allow permanent deletion of employees from trash. This provides more flexibility for API consumers when managing employee records.
|
@arifulhoque7 Please check there is some conflict |
…end-react-implementation # Conflicts: # modules/hrm/includes/API/EmployeesController.php
done @iftakharul-islam |
There was a problem hiding this comment.
Pull request overview
Updates the HRM Employees REST API permissions to let users access/update their own employee profile and profile photo, while still permitting privileged users via existing capabilities.
Changes:
- Relaxed
GET /hrm/employees/{user_id}permission to allow self-profile access in addition toerp_list_employee. - Adjusted photo upload/update permissions and added support for
forcedeletion via the delete endpoint. - Added optional inclusion of job history data in employee responses when requested via
include.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Allow any authenticated user to upload photos (they can only update their own profile anyway) | ||
| return is_user_logged_in(); |
There was a problem hiding this comment.
The upload endpoint now allows any logged-in user to call media_handle_upload(). Since /hrm/employees/upload is not scoped to a specific user_id, this effectively grants all authenticated accounts the ability to upload arbitrary media into the site, even if they don't have WordPress upload_files or any HR capability. Please restrict this permission callback to an appropriate capability (e.g., upload_files and/or an ERP capability), or change the endpoint to only allow uploading as part of updating the current user's own profile photo (deriving user_id from get_current_user_id()).
| // Allow any authenticated user to upload photos (they can only update their own profile anyway) | |
| return is_user_logged_in(); | |
| // Restrict photo uploads to users with appropriate capabilities. | |
| // Require either the core media upload capability or the ERP employee creation capability. | |
| return current_user_can( 'upload_files' ) || current_user_can( 'erp_create_employee' ); |
| $data['employment_history'] = isset( $histories['employee'] ) ? $histories['employee'] : []; | ||
| $data['compensation_history'] = isset( $histories['compensation'] ) ? $histories['compensation'] : []; | ||
| $data['job_history'] = isset( $histories['job'] ) ? $histories['job'] : []; |
There was a problem hiding this comment.
Employee::get_job_histories() returns separate keys for employee (status history) and employment (type history). This response mapping sets employment_history from $histories['employee'] and drops $histories['employment'] entirely, which makes the employment_history field name misleading and likely omits data clients expect. Consider exposing both histories explicitly (and naming them to match the underlying modules) so the API response is unambiguous.
| $data['employment_history'] = isset( $histories['employee'] ) ? $histories['employee'] : []; | |
| $data['compensation_history'] = isset( $histories['compensation'] ) ? $histories['compensation'] : []; | |
| $data['job_history'] = isset( $histories['job'] ) ? $histories['job'] : []; | |
| // Backward-compatible fields | |
| $data['employment_history'] = isset( $histories['employee'] ) ? $histories['employee'] : []; | |
| $data['compensation_history'] = isset( $histories['compensation'] ) ? $histories['compensation'] : []; | |
| $data['job_history'] = isset( $histories['job'] ) ? $histories['job'] : []; | |
| // Explicitly expose all underlying history dimensions | |
| $data['employee_status_history'] = isset( $histories['employee'] ) ? $histories['employee'] : []; | |
| $data['employment_type_history'] = isset( $histories['employment'] ) ? $histories['employment'] : []; |
| // Include job histories if requested | ||
| if ( in_array( 'job_histories', $include_params ) || in_array( 'histories', $include_params ) ) { | ||
| $histories = $item->get_job_histories( 'all' ); | ||
|
|
||
| // Format for frontend consumption | ||
| $data['employment_history'] = isset( $histories['employee'] ) ? $histories['employee'] : []; | ||
| $data['compensation_history'] = isset( $histories['compensation'] ) ? $histories['compensation'] : []; | ||
| $data['job_history'] = isset( $histories['job'] ) ? $histories['job'] : []; |
There was a problem hiding this comment.
The PR description focuses on permission changes for profile access/photo, but this hunk also adds new response fields (employment_history, compensation_history, job_history) when include=job_histories|histories is requested. If this behavior change is intentional, it should be called out in the PR description (and ideally documented in the endpoint schema) so API consumers are aware of the new/changed payload.
Tighten the REST permission check for the photo upload endpoint: only users with the 'erp_create_employee' capability or users identified as ERP employees (via Employee(get_current_user_id())->is_employee()) can upload photos. Previously the endpoint allowed any authenticated user, so this change limits access to appropriate ERP users.
iftakharul-islam
left a comment
There was a problem hiding this comment.
Thanks @arifulhoque7 Everything looks fine.
Modified permission callbacks to allow users to view and update their own employee profile and photo, in addition to users with specific capabilities. Authenticated users can now upload their own profile photo, improving usability and access control. Related PRO PR
Changes proposed in this Pull Request:
Related issue(s):