Don't allow users to set certain fields in issues
Users are misusing some fields in issues. As an example, in issue 8936, the OS is set to Windows despite there not being anything Windows-specific about the issue, "Relates to usability" being set to Yes is slightly doubtful but not entirely wrong, and the issue type is set to Other for no apparent reason. In fact, about half of the issues made by non-developers since the issue tracker move have the OS set to Windows even though they haven't been shown to be Windows-specific (other than D3D-related ones). I suggest that these fields are to be made developer-only, like on Google Code. Users are always going to mess something up regardless of how well we describe the options, and it's easier for developers to set fields like OS for issues that need it than to check all new issues for incorrect fields.
#1 Updated by JosJuice over 5 years ago
"Relates to usability" seems to be even more misused than OS. Users are applying it to emulation bugs and crashes, probably with the logic that things like that make Dolphin harder to use... While it makes sense considering the meaning of the word, using that logic would mean that every issue is a usability issue, and then the field would be pointless.
#2 Updated by BhaaL over 5 years ago
I do see why they select their OS tho - because they experienced the issue on that particular OS. Back with our old issue tracker at work, there was an OS field aswell, which was used to track the system specs where it actually occurred (ie. Reporter uses WinXP SP1, someone else with Win7 can't reproduce) rather than the OS the report is specific (like a D3D issue can't be specific to Linux or OSX).
This probably ties in with the issue templates; but the only field a plain user should be allowed to set is the issue type (is it a Bug, or maybe a Feature request?) - erverything should be dev-only. Doesn't Redmine have permission sets or screen layouts which can be assigned to the various user groups?
#4 Updated by JosJuice almost 3 years ago
- Status changed from Fixed to Work started
Reopening because this still is a problem on the infrastructure tracker, mainly when it comes to the priority field. See issue 11218 for an example.
(For some reason, it doesn't seem to be possible to change the status of this issue back to New, so let's go with Work started...)