-
Suggestion
-
Resolution: Unresolved
-
138
-
84
-
Problem
The "Default issue type" dropdown is only honoured when the user has not previously selected an issue type, so only works once after logging in.
It'd be useful to have a hard default that is always used with every new issue created.
The current functionality should be retained and be the default configuration, to avoid backwards compatibility problems and to avoid making one group happy at a loss to another.
Suggested solution
- Add a new checkbox underneath the "Default issue type" dropdown with the label: "Re-use the previously selected issue type"
- New checkbox checked by default to retain current functionality and BC
Outcome
- When checkbox is checked (and previously chosen issue type exists)
-
- The user's previously chosen issue type will be used
- Current functionality retained
- Backwards compatible
- When checkbox not checked (or previously chosen issue type doesn't exist)
-
- The "Default issue type" will be used
- New functionality gained for users wanting it
- The "Default issue type" wording is now a bit more accurate/meaningful
- duplicates
-
JRACLOUD-62990 Default issue type behavior options
- Closed
-
JRACLOUD-74525 Possibility to Set Default Issue Type as "None"
- Closed
- is related to
-
JRACLOUD-79915 Issue type is not reset to the default one when creating ticket in a new session
-
- Closed
-
-
JRACLOUD-85750 Ability to set default issue type in team-managed projects
- Closed
- relates to
-
JRACLOUD-87418 Inconsistent default issue type behaviour when Enhanced backlog is enabled
-
- Closed
-
- mentioned in
-
Page Loading...
Form Name |
---|
The suggestion makes the most sense to me, however I could see using the "last used" Issue Type on the "Create Another" feature. "Create Another" seems like the sequence that would be used most in brainstorming, testing, or elaboration sessions and that's where you want to rapid-fire a lot of issues. Using the generic "Create" button on the form should respect the project settings as described above.
The current behavior results in a lot of issues reported as bugs instead of improvements or vice versa, based on whatever that user did the last usage. The users enter these issues as they come across them either by usage problems (bugs) or inspiration (improvements). Erroneous entries impact our triage effectiveness and responsiveness. In our case, we would set the default to "None" but make the field required. The user would have to at least choose between these two options, and we may re-categorize upon triage.