View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0012086mantisbtbugtrackerpublic2010-06-17 21:522014-01-21 18:28
Reporterdhx Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version1.2.15 
Summary0012086: Deprecate $g_allow_reporter_close
Description

The 'allow_reporter_close' option is redundant. We should be using 'status_enum_workflow' instead to determine whether it's OK to change the status of an issue. This will require the addition of a static 'reporter' flag for configuration values (much like the current per-user/per-project options for configuration stored in the database). This approach is obviously much more powerful as it'd be possible to have an 'allow_reporter_close' style option for every status.

TagsNo tags attached.

Relationships

related to 0012085 closeddhx Deprecate $g_allow_close_immediately 
related to 0012087 new Deprecate $g_allow_reporter_reopen 
child of 0010285 confirmed Allow Only Reporters to change the issue status to CLOSED 

Activities

thraxisp

thraxisp

2010-06-17 22:28

reporter   ~0025883

As I recall, there is a subtle difference with this and the $g_allow_reporter_reopen flag. The workflow refers to reporter as a generic term (e.g., any reporter on the project). These flags refer to the specific reporter of this bug. This allows the reporter of the bug to close or reopen the issues they created.
dhx

dhx

2010-06-17 23:17

reporter   ~0025885

Yep I should of clarified above that the proposed 'reporter' (and 'handler', etc) flags for configuration options were referring to the reporter of the current issue (as opposed to the generic 'reporter' access level).

It's just an idea at this stage and I don't have any concrete plans on how to achieve it (yet). The idea was to make a generic way of allowing administrators to set permissions not just on the basis of who (in terms of access levels), where (which project)... but also in terms of whether the user is the reporter or handler of an issue.
cproensa

cproensa

2010-10-20 06:59

developer   ~0027096

the current scheme tracks which "acces level" is allowed to move a bug "into" certain state. (on "Minimum Access Level to Change to this Status" conf page)

that is a general set up which may satisfy most of the cases.
However, if more strict rules are needed, i'd say to extend into: "who (as accesleves + circumstance" can change status "previous" into "next"
This set of specific rules would be evaluated over the generic set of permissions.

for example:
) "reporter" "in its own bug" CAN change status from "RESOLVED" to "CLOSED"
) "updater" "in project" CAN change status from "NEW" to "REJECTED"
etc