Feature #3068

Generic task management (not issues)

Added by Matthew Dixon over 10 years ago. Updated over 2 years ago.

Status:NewStart date:2009-03-28
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Translations
Target version:-
Resolution:

Description

I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There should be a per-project setting, what to actually call "issue" in that project. And, as a corollary, add a related option that tells what to call "tracker" there, too. (E.g. "task type", if "issue" is renamed to "task".)

If left empty, the generic names are used by default, as before. Otherwise, throughout the whole UI (including emails sent & documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project.

By allowing these more generic descriptions (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew
(Updated as suggested by Szabolcs Szász)

en-tasks.yml Magnifier (27.4 KB) Matthew Dixon, 2009-03-29 14:08


Related issues

Related to Redmine - Feature #2082: Rename Issue as Ticket (or ...) in GUI New 2008-10-24
Related to Redmine - Feature #4636: System-wide Object Label Settings and the general Open Pa... New 2010-01-22
Duplicated by Redmine - Feature #4568: Replace "Issue" for "Task" Closed 2010-01-13
Duplicated by Redmine - Feature #4908: Change Issue for Task Closed 2010-02-23
Duplicated by Redmine - Feature #25561: Issues are not tasks: please split them Reopened

History

#1 Updated by Matthew Dixon over 10 years ago

Hi,

I realised there's a very simple way to do this via the language file. I'm uploading a new English language file which I search and replaced so that it simply calls issues tasks.

Combine that with custom trackers and workflows, and the suggested feature is >90% done.

I'm not really anything on this project (apart from a fussy tester) so if someone thinks it's useful, please feel free to post it where where people can access it.

All the best,

Matt

#2 Updated by Dipan Mehta over 6 years ago

While this is possible through the locale file changes - it might still be not convenient for some organization where the admins do not prefer you to mess with the 'packaged' software.

It might be more desirable to have Application setting such as 'Label used for Issue'.

#3 Updated by Dipan Mehta over 6 years ago

Add related (duplicate) #4568, #4908

#4 Updated by Daniel Felix over 6 years ago

  • Category set to Translations

Added relation to #4568 (which duplicates this) and #4908 (also a duplicate).

#5 Updated by Toshi MARUYAMA over 6 years ago

Is this issue category Translation?

Japanese: チケット = ticket
source:tags/2.3.0/config/locales/ja.yml#L486
Traditional Chinese: 問題 = problem
source:tags/2.3.0/config/locales/zh-TW.yml#L575
Simplified Chinese: 问题 = problem
source:tags/2.3.0/config/locales/zh.yml#L450

#6 Updated by Szabolcs Szasz about 5 years ago

Excellent point!

NOTE: the actually used semantic content of the nicely generic term "issue" varies by project!

Thus, changing it globally on the system-level cannot be a real solution. Also, changing this in the translation layer is even more of a hack to workaround the missing option.

Also:

Please edit the issue description so as to also request an option for changing "Tracker", too! That term resonates with even less people than "issue" (not even developers in general). And changing it globally (to e.g. "Issue type") would be equally wrong, as the term "issue" and "tracker" would usually need to be changed together, in tandem.

Thanks, cheers!

#7 Updated by Toshi MARUYAMA about 5 years ago

Szabolcs Szasz wrote:

Please edit the issue description so as to also request an option for changing "Tracker", too!

Please post what should be added.

#8 Updated by Szabolcs Szasz about 5 years ago

Toshi MARUYAMA wrote:

Szabolcs Szasz wrote:

Please edit the issue description so as to also request an option for changing "Tracker", too!

Please post what should be added.

Thanks for watching, Toshi!

The original issue description says (among other things):

"There could even be a per project toggle setting, whether to call them issues or tasks!"

1. As (I figure) that is the main point, that should stand on a separate paragraph.

2. It should read: "There should be a per-project setting, what to actually call "issues" in that project."

3. And, to cover "Trackers", another sentence should be added, right next to it: "And, as a corollary, add a related option that tells what to call "tracker" in that project."

4. You might also add: "If empty, the current names are used by default. Otherwise, throughout the whole UI (including emails sent and documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project."

5. Break the rest of the text (from "By allowing this more generic description...") to a new paragraph.

(If you wish, I could also post a new issue, setting this as related -- but that would feel duplicating it, and may risk closing it by others.)

Thanks!
Sz.

#9 Updated by Toshi MARUYAMA about 5 years ago

Please post full description to replace for cut and paste.

#10 Updated by Szabolcs Szasz about 5 years ago

BTW, actually, it's an interesting question, how it relates/interferes with the translation layer.

1. This, in fact, appears to be a localization problem. However, not belonging to a given language (translation) or country locale, but to the "locale" of a problem domain.

2. Problem domains exist independently of languages, so this change must also be orthogonal to language translations. It should apply on a different level, being subject to language translations itself.

3. After all, this is actually subclassing: subclassing the generic Redmine tool to apply better to a specific problem domain.

4. As the issue (tracker) data models can already be customized ("subclassed") manually to fit a target domain, it is only natural to make it complete by allowing proper names to reflect those narrowed-down (customized) "issue" concepts better for the participants of that target problem domain.

#11 Updated by Szabolcs Szasz about 5 years ago

(Deleted by note-13 request)

#12 Updated by Szabolcs Szasz about 5 years ago

Toshi MARUYAMA wrote:

Please post full description to replace for cut and paste.

OK, here it goes (with further slight modifications):

----
I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There should be a per-project setting, what to actually call "issue" in that project. And, as a corollary, add a related option that tells what to call "tracker" there, too. (E.g. "task type", if "issue" is renamed to "task".)

If left empty, the generic names are used by default, as before. Otherwise, throughout the whole UI (including emails sent & documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project.

By allowing these more generic descriptions (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew
(Updated as suggested by Szabolcs Szász)

#13 Updated by Szabolcs Szasz about 5 years ago

(Please delete update 11! I thought I was editing it but accidentally posted a new one, sorry!)

#14 Updated by Toshi MARUYAMA about 5 years ago

Szabolcs Szasz wrote:

(Please delete update 11! I thought I was editing it but accidentally posted a new one, sorry!)

Done.

#15 Updated by Toshi MARUYAMA about 5 years ago

  • Description updated (diff)

Original description:


I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There could even be a per project toggle setting, whether to call them issues or tasks! By allowing this more generic description (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew

#16 Updated by Toshi MARUYAMA over 2 years ago

  • Duplicated by Feature #25561: Issues are not tasks: please split them added

#17 Updated by cyril Thibout over 2 years ago

Hi

I don't understand where is the actual status of this issue that has been published 8 years ago.

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.

thanks a lot

cyril

Also available in: Atom PDF