View Issue Details

IDProjectCategoryView StatusLast Update
0025637mantisbtbugtrackerpublic2019-04-02 03:19
Reporterobmsch Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Summary0025637: Inconsistency: user_get_all_accessible_(sub)projects forces exclusion of disabled projects
Description

Currently threre are four related functions:

  1. user_get_all_accessible_projects( $p_user_id = null, $p_project_id = ALL_PROJECTS )
  2. user_get_all_accessible_subprojects( $p_user_id, $p_project_id )
  3. user_get_accessible_projects( $p_user_id, $p_show_disabled = false )
  4. 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.

TagsNo tags attached.

Relationships

related to 0025641 new Refactor project hierarchy 

Activities

obmsch

obmsch

2019-03-23 04:52

reporter   ~0061743

PR https://github.com/mantisbt/mantisbt/pull/1488

cproensa

cproensa

2019-03-23 06:54

developer   ~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

Issue History

Date Modified Username Field Change
2019-03-22 18:48 obmsch New Issue
2019-03-23 04:52 obmsch Note Added: 0061743
2019-03-23 06:54 cproensa Note Added: 0061745
2019-03-23 07:31 cproensa Relationship added related to 0025641
2019-04-02 03:18 dregad Description Updated View Revisions
2019-04-02 03:19 dregad Description Updated View Revisions