Patch #1667
openDefault tracker setting in each project
0%
Description
Hi,
I made a patch which allow administrator to set a default tracker in each project.
A default tracker can be nil.
If a default tracker is nil, the user MUST select one tracker.
This patch solves #1365.
Files
Related issues
Updated by Thomas Lecavelier about 16 years ago
- Target version deleted (
0.8)
The target version field has to be set when it will actually part of the target release.
Updated by Nestor Lobo over 11 years ago
Thomas Lecavelier wrote:
The target version field has to be set when it will actually part of the target release.
I can relate this solution/workaround that works, but it is for the whole instance, not by proyects.
http://www.redmine.org/boards/2/topics/18781?r=36152
Regards.
Nestor
Updated by Go MAEDA over 9 years ago
- Has duplicate Feature #19223: Add option to set default tracker for project on new issue added
Updated by Go MAEDA over 9 years ago
- Related to Feature #11652: configurable issue tracker default added
Updated by Tobias Fischer about 8 years ago
+1
It would be great if this patch can make it in 3.4 release! Now that we have the option to specify a "default version" for new tickets (since 3.2) it makes sense to also add a project setting to chose the default tracker for a new ticket in this project.
Updated by Jean-Philippe Lang about 8 years ago
Now that we can restrict on which trackers the different roles can create issues, wouldn't it make more sense to set the default tracker on each project member? And maybe add an optional default tracker on each role so that members can automatically inherit this default tracker, but still overridable.
Updated by Tobias Fischer about 8 years ago
Jean-Philippe Lang wrote:
[…] wouldn't it make more sense to set the default tracker on each project member?
What would be the use case for default tracker per project member? I don't see such a business case.
If I remember it correctly, there's not a single project setting which can be set per project member – everything is based on the project members role.
And maybe add an optional default tracker on each role so that members can automatically inherit this default tracker, but still overridable.
This makes more sense to me than per project member. Also when taking into account your first statement:
Now that we can restrict on which trackers the different roles can create issues […]
Despite everything, my personal oppinion is that a default tracker per project is enough, because I think the workflow/settings/roles&rights configuration process shouldn't get overconfigured any further.
When talking about default tracker per project member, you could also think about default versions per project member… No… this is just too much…
Updated by Brad Barnett over 7 years ago
This would definitely be quite handy here.
I constantly have users -- heck, even myself occasionally, set the tracker wrong on bug creation.
I'd say that on a given day, out of 100 bugs -- 20 extra emails go out for a tracker change. That's unneeded distraction, so... I throw my vote towards this. If there is a vote.
Just to clarify, it's the 'default of nothing' that is very needed here. To FORCE a user to set something...
Updated by Toshi MARUYAMA over 7 years ago
- Subject changed from Default tracker setting to Default tracker setting in each project
Updated by Gregor Glashüttner over 6 years ago
+1 for "default to nothing, force user to select something".
Would be very useful to prevent creating tickets with wrong tracker.
Updated by J. Pablo Zebraitis over 5 years ago
+1 for "default. If nothing, force user to select one. NOT select the first element with NO real criteria".
Better: set available trackers for project and Rol (with defaults).
Updated by J. Pablo Zebraitis over 3 years ago
+1
Set a default tracker in each project. A default tracker can be nil. If a default tracker is nil, the user MUST select one tracker.
Updated by Albrecht Dreß about 3 years ago
Updated by Minoru Maeda 10 months ago
- File 1667-20231031.patch 1667-20231031.patch added
I attached a patch with the following features:
- Added a default tracker item in the project settings.
- In the "Issue tracking" tab, you can set the default tracker "For all roles" or "By role".
- When adding a new Issue, the default tracker is specified only once.
- If the default tracker is not set or if 'Add issues' is changed to not allowed in the role, the tracker is specified as usual.
However, this patch does not implement the default tracker for the project's REST API .
Looking forward to your valuable feedback. Thanks in advance!
Updated by Mathias Walter 8 months ago
Since there is a patch available now, please schedule it for one of the next releases.
Updated by Dmitry Nekrasov 4 months ago
Mathias Walter wrote in #note-15:
Since there is a patch available now, please schedule it for one of the next releases.
Redmine 5.1.1, patching return error:
root@redmine5:/opt/redmine# patch -p0 < 1667-20231031.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/app/helpers/projects_helper.rb b/app/helpers/projects_helper.rb
|index d4f7339a0..b9867fa3d 100644
|--- a/app/helpers/projects_helper.rb
|+++ b/app/helpers/projects_helper.rb
--------------------------
File to patch:
If i force the path to the file, the following error occurs:
File to patch: /opt/redmine/app/helpers/projects_helper.rb
patching file /opt/redmine/app/helpers/projects_helper.rb
Hunk #1 FAILED at 123 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file /opt/redmine/app/helpers/projects_helper.rb.rej
can't find file to patch at input line 24
Perhaps you used the wrong -p or --strip option?
Updated by Mathias Walter 4 months ago
Dmitry Nekrasov wrote in #note-16:
Hunk #1 FAILED at 123 (different line endings).
This looks like you've downloaded the patch or checked out the repository with different line endings (LF vs CRLF).
Also, the file is indeed there app/helpers/projects_helper.rb
.