Add view-all-projects check and use in controller - #580

src/Project/Controllers/Project_Controller.php (1)

155-159: ⚠️ Potential issue | 🟠 Major

Update Search_Controller permission checks to match Project_Controller.

The permission function was changed from wedevs_pm_has_manage_capability (includes both admins and managers) to wedevs_pm_can_view_all_projects (admins only) in Project_Controller at line 155, but this change was not applied to Search_Controller. This creates a permission inconsistency: PM Managers will see all projects in search queries but only assigned projects in the project listing, depending on which endpoint they access.

Update the three permission checks in Search_Controller (lines 139, 159, and 422) to use wedevs_pm_can_view_all_projects instead of wedevs_pm_has_manage_capability to ensure consistent behavior across all project-fetching endpoints.

src/Project/Helper/Project.php (2)

1415-1427: ⚠️ Potential issue | 🟡 Minor

Unreachable return 10 at Line 1426.

The return on Line 1424 always exits the function; Line 1426 is dead code.

🧹 Proposed fix

 		$per_page = wedevs_pm_get_setting( 'project_per_page' );

-		return empty( $per_page ) ? 10 : (int) $per_page;
-
-		return 10;
+		return empty( $per_page ) ? 10 : (int) $per_page;
 	}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/Project/Helper/Project.php` around lines 1415 - 1427, The get_per_page()
function contains an unreachable final "return 10" after an earlier return;
remove the dead code and keep a single return path. Specifically, in
Project::get_per_page() remove the trailing "return 10;" and ensure the method
returns (int) $per_page when provided, falls back to
wedevs_pm_get_setting('project_per_page') and finally returns 10 if that setting
is empty—no extra return after those branches.

---

138-198: ⚠️ Potential issue | 🟠 Major

count_project_by_type() is not user-aware — exposes all-project counts to restricted users and breaks pagination.

count_project_by_type() queries the full projects table with no user join or filter:

SELECT DISTINCT COUNT(id) FROM {pm_projects} WHERE status = %d

These unfiltered counts populate total_incomplete, total_complete, total_pending, total_archived, and critically pagination.total (Line 155) in the response metadata. Meanwhile, total_projects and total_pages are derived from $this->found_rows (Line 147/157), which is filtered by the user-aware SQL query in get().

The practical result after this PR's access-control change: a PM Manager restricted to, say, 5 assigned projects will receive a pagination.total of 50 (all system projects), causing broken/phantom pagination pages and leaking the aggregate project count.

count_project_by_type needs to be rewritten to join against pm_role_user and filter by $current_user_id when the user is not an admin — mirroring the filtering logic in where_users().

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/Project/Helper/Project.php` around lines 138 - 198, count_project_by_type
currently counts across the whole pm_projects table and must be made user-aware;
change count_project_by_type($type) to apply the same user filtering used in
where_users() (join pm_role_user and filter by current user id when the current
user is not an admin) so the counts (used by get_pagination_total and
set_projects_meta) match $this->found_rows and the get() results; specifically,
reuse or mirror where_users() logic (join wedevs_pm_tb_prefix() .
'pm_role_user', filter by $this->current_user_id or get_current_user_id(), and
any capability checks) and update the SQL in count_project_by_type to include
that JOIN/WHERE, returning the filtered COUNT(id).