Feature #25561
open
Issues are not tasks: please split them
Added by cyril Thibout about 7 years ago.
Updated about 7 years ago.
Description
Hi
I know it has already been addressed but issues are not tasks and renaming issues to task is not enough because we need both !
I'm in favor of renaming the current issues module as tasks module since it is connected to the Gantt which has nothing to do with issues / tickets. Even if we think differently we do need to separate issues that are mainly submitted by the end user , from tasks that are generally submitted by the internal staff.
This issues / task confusion is the source of most rebukes from our customers.
What do think if this proposal please? I'm sure many already thought about it already
thanks
cyril
- Tracker changed from Defect to Feature
- Status changed from New to Closed
- Resolution set to Duplicate
Duplicate of #3068 and etc.
- Is duplicate of Feature #3068: Generic task management (not issues) added
- Status changed from Closed to Reopened
Hi
Though the initial question may feel the same this is not real duplicate of Feature #3068 where the topic was only how should we rename issues.
Here I'm talking about a real difference between tasks and issues (tickets). In most projects we have end users submitting issues that have very few relationships with tasks we find in the gantt.
therefore I suggest a real split between those two different domains
Thanks
cyril
You can define different trackers which can exhibit widely different behavior (e.g different workflows, different fields, ...). You can then filter in about all views based in the tracker. That way, you can right now distinguish between your tasks and issues. You can even create different projects for development (with "issues") and user-support (with "tasks") where you just enable one of these trackers.
If this is not enough for your use-case, please describe in detail what is missing and how this could be solved in Redmine. Also please describe how this applies to the general audience.
Also available in: Atom
PDF
Updated by Toshi MARUYAMA 
Updated by 
Updated by