Project

General

Profile

Actions

Feature #25561

open

Issues are not tasks: please split them

Added by cyril Thibout over 7 years ago. Updated over 7 years ago.

Status:
Reopened
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Duplicate

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


Related issues

Is duplicate of Redmine - Feature #3068: Generic task management (not issues)New2009-03-28

Actions
Actions #1

Updated by Toshi MARUYAMA over 7 years ago

  • Tracker changed from Defect to Feature
  • Status changed from New to Closed
  • Resolution set to Duplicate

Duplicate of #3068 and etc.

Actions #2

Updated by Toshi MARUYAMA over 7 years ago

  • Is duplicate of Feature #3068: Generic task management (not issues) added
Actions #3

Updated by cyril Thibout over 7 years ago

  • 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

Actions #4

Updated by Holger Just over 7 years ago

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.

Actions

Also available in: Atom PDF