0025637: Inconsistency: user_get_all_accessible_(sub)projects forces exclusion of disabled projects

ID	Project	Category	View Status	Date Submitted	Last Update
0025637	mantisbt	bugtracker	public	2019-03-22 18:48	2019-04-02 03:19

Reporter	obmsch	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	new	Resolution	open

Summary	0025637: Inconsistency: user_get_allaccessible(sub)projects forces exclusion of disabled projects
Description	Currently threre are four related functions: `user_get_all_accessible_projects( $p_user_id = null, $p_project_id = ALL_PROJECTS )` `user_get_all_accessible_subprojects( $p_user_id, $p_project_id )` `user_get_accessible_projects( $p_user_id, $p_show_disabled = false )` `user_get_accessible_subprojects( $p_user_id, $p_project_id, $p_show_disabled = false )` [3], [4] have a param to enable the inclusion of disabled projects, [1], [2] which eventually call [3], [4] don't. That are odd 'all' s at least.
Tags	No tags attached.

obmsch 2019-03-23 04:52 reporter ~0061743	PR https://github.com/mantisbt/mantisbt/pull/1488

cproensa 2019-03-23 06:54 reporter ~0061745	I agree theres a lot to clean up. But one of the main problems around those functions, and the usage of them is: Is the request for the projects accesible to the user, like, those projects that can be listed. Or is the request to get the actual project structure behind the hierarchy. i think that [1],[2] are intended and user purely for user accesible projects, wich seems like disbaled projects should not be included. And [3] [4] are (prossibly wrongly) used to inspect the hierarchy. In my PR https://github.com/mantisbt/mantisbt/pull/1480 I have tried to start a separation between both scenarios. For some usages, the pure hierarchy should be used, regardless of user permissions, and other things needs to account for user visibility. In fact, i have removed all usages in the codebase for [3] and [4], except for the soap/rest api, so that can be a sign that those api needs also some refactoring