View Issue Details

IDProjectCategoryView StatusLast Update
0023570mantisbtbugtrackerpublic2020-02-09 07:03
Reportercproensa Assigned Tocproensa  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Target Version2.24.0Fixed in Version2.24.0 
Summary0023570: Implement limit_reporters as a threshold
Description

There are some issues with the limit_reporters option:

  • It's an on/off flag, so the behaviour is not very configurable.
  • The meaning of reporter, is based on the ability of a user to create issues, so it depends on report_bug_threshold for each project.
  • The access level that is not limited by this option is not well defined, when report_bug_threshold is an array threshold with gaps.

A more standard approach is to have an option representing a threshold, the meaning should be inverted though: "access levels that CAN view other reporters' issues"
Being a threshold, the behaviour is well defined and would use the standard access api conventions.
However, a disadvantage is that the dynamic "who is a reporter" discovery is lost, so if report_bug_threshold is modified for some project, this options should be modified accordingly.

There are related requests to have a limitation for users to view only issues assigned to him, which can be implemented in the same way as the "reporter" threshold limit.

Thoughts?

TagsNo tags attached.

Relationships

related to 0010831 resolvedcproensa how can I allow user to view only the issue that assigned to them 

Activities

Related Changesets

MantisBT: master 46dff48e

2017-10-30 19:57:19

cproensa

Details Diff
New option limit_reporter_unless_threshold

Currently the option 'limit_reporters' is used to only allow viewing
issues reported by the user. This is an on/off option, and not a
threshold, and when enabled it applies the restriction to those user
that are calculated to be reporters.
The problem is that a user can report issues based on
'report_bug_threshold'. With the option enabled, users with an access
level (AL) greater than the minumim AL needed to report, are those that
can view all issues. This is a weak implementation that causes
inconsistencies, for example, when the report threshold is a
non-contiguous array of ALs.

A new option is created: limit_reporter_unless_threshold which is a real
threshold option. Any user that meets that threshold will see any issue,
otherwise the view is limited to only own reported issues (working like
the old option 'limit_reporters')
The meaning of the option has a inverse logic, because we don't support
negative thresholds. Setting ANYBODY as the value for this option is the
equivalent of 'limit_reporters' having OFF value.

To add a transitional workaround from the old to new logic:
When 'limit_reporters' option is ON, which according to previous
functionality, should be a global configuration (ALL_PROJECTS), the new
option is not evaluated, neither will be shown in configuration pages.
Once 'limit_reporters' is OFF at global level, the new option
'limit_reporter_unless_threshold' will be shown on pages and be
effective al global or project level.

Fixes: 0023570
Affected Issues
0023570
mod - config_defaults_inc.php Diff File
mod - core/access_api.php Diff File
mod - lang/strings_english.txt Diff File
mod - manage_config_work_threshold_page.php Diff File
mod - manage_config_work_threshold_set.php Diff File

Issue History

Date Modified Username Field Change
2017-10-31 19:02 cproensa New Issue
2019-07-06 08:15 cproensa Relationship added related to 0010831
2019-07-08 19:04 cproensa Note Added: 0062368
2019-07-08 19:04 cproensa Assigned To => cproensa
2019-07-08 19:04 cproensa Status new => assigned
2020-02-05 09:01 cproensa Changeset attached => MantisBT master 46dff48e
2020-02-05 09:01 cproensa Status assigned => resolved
2020-02-05 09:01 cproensa Resolution open => fixed
2020-02-05 09:01 cproensa Fixed in Version => 2.24.0
2020-02-09 07:03 atrol Target Version => 2.24.0