View Issue Details

IDProjectCategoryView StatusLast Update
0023208mantisbtbugtrackerpublic2017-12-05 05:48
Reporterj_schultz Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0023208: Threshold for setting fields such as priority
Description

Many end-users do not really understand what issue priority is (or how we use it). For example, if they find that an issue is important to them, they might set the priority to "immediate". Quite often this does not reflect the reality and it would make more sense that only users above a certain threshold could set the priority (or other fields such as severity). Typically it is the developer who decides what an issue's priority should be.

By looking through the default config variables, I figured that I can completely remove this field but there is no way to set some sort of edit threshold for this and other fields. It would be great if there was a threshold for editing certain fields.

TagsNo tags attached.

Relationships

has duplicate 0017005 closedatrol Allow changing the Priority only above certain permission level 
has duplicate 0023697 closedatrol Not to allow developer role to change the severity of a issue 

Activities

cproensa

cproensa

2017-08-11 04:28

developer   ~0057431

In my configuration, I have priority hidden when reporting, and rporter users cant go into the edit page.
This way only users with permissions to edit issues can update those fields.

The core issue is that native fields can't have a detailed configuration for each one, like custom fields have. Ideally, all field types should be configurable for where to be shown, where to be required, who can view/update them, etc. But that's not an easy change at the moment.
Introducing many new configuration options like the one suggested is not a good idea imho. I'd rather work towards a convergence model instead of having to mantain new options (we have already so many of them...)

j_schultz

j_schultz

2017-08-11 07:29

reporter   ~0057436

I agree that doing it through options is probably not the optimal way (per-project configurations or similar could be better).
In general I would like my users to be able to edit their reports so your configuration won't work for me.

cproensa

cproensa

2017-08-11 08:00

developer   ~0057437

Last edited: 2017-08-11 08:06

In general I would like my users to be able to edit their reports so your configuration won't work for me.

Another workaround:

  • Write a plugin that catch the event EVENT_UPDATE_BUG_DATA, and check if the field has been modified by a user who shouldn't. Then you could either thorw an error, or silently drop the change and keep the previous value.
  • Additionally, you can add JS code to remove that field from the update page. Maybe, use also EVENT_UPDATE_BUG_FORM_TOP to place a hidden element un the update page, only when the user is unprivileged, that triggers the JS to remove the field only in that situation.

I have done something similar in that scenario, so i'm sure that would work in some way.

Another option, but dirtier imo:

  • hijack the $g_bug_update_page_fields with some plugin event to remove that field from the array if current user is unprivileged.
    This event could be one of the layout_output types, that are excuted on every page before the actual edit_page is effectively built.