Feature #3101

Ticket assigned to many subprojects.

Added by Adam Kubica over 12 years ago. Updated over 8 years ago.

Status:NewStart date:2009-04-02
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:

Description

Very big problem occurs when main project has a ticket that should be assigned to several subprojects.

Now, we must create one main ticket, some tickets for subprojects and depedencies between that tickets (we waste of our time).

It's works but is serious problem when occurs many times in week !!!

This case should be simplified, one ticked should be assigned to may subprojects at once.

History

#1 Updated by Zarooba Rozruba over 12 years ago

Can't you split the main ticket into sub tickets?

So main project gets a main ticket while subprojects have more specific tickets to their domain.

For example;
'Main' project has ticket ''Integrate with system X''
Subproject 'Email Notification' has a ticket ''include information gleamed from system X''
Subproject 'Daily database cache update' has a ticket ''read data from System X''
Subproject 'User interface' has two tickets ''show data read from System X'' and second ticket ''on update, also update System X''

Finally, you setup all subproject tickets as blocking the main project ticket.

This way, main project ticket can not be closed until sub project tickets are closed.


What I am trying to say is that, how can a ticket be assigned to many projects at once?
This makes little sense, unless ticket was too vague.

Kind regards

pl:Serdecznie Pozdrawiam

#2 Updated by Adam Kubica over 12 years ago

In common case you're right.

Try imagine situation when three times in week you have task that affected 4 subprojects.

For example (in real world it's in big scale): Main task: "Additional informations in the client data", this task affected subprojects:
  • subproject 1, (common: large database DDL) - new fields, tables, something
  • subproject 2, (staff/workers: backend, rails) - create new form to manage additional informations
  • subproject 3, (clients: frontend, Pylons) - display additional information
  • subproject 4, (common, some live business logic, JAVA) - make boo boo on that informations ;-p

Of course, when we have that situation from time to time or/and task is enough large to split into 4 smaller task then all works fine but when task is small and situations occurs many times we must for example create 5 tickets (about 30 min work time) for job that 2-3 peoples make in 2 hours :-)

pl: pozdrawiam również, redmine jest świetny (ale ssie troszkę przy podprojektach).

#3 Updated by Adam Kubica over 12 years ago

This is not ideology problem, it's time waste/task management problem in daily use.

#4 Updated by Zarooba Rozruba over 12 years ago

Then maybe a quick and easy way to create secondary related blocking issues ??

So someone creates a big Issue on main project.
and then with a single button creates sub issues in sub projects.

Each sub issue is flagged as an issue blocking the main project issue. ?

#5 Updated by Adam Kubica over 12 years ago

Zarooba Rozruba wrote:

Then maybe a quick and easy way to create secondary related blocking issues ??

So someone creates a big Issue on main project.
and then with a single button creates sub issues in sub projects.

Each sub issue is flagged as an issue blocking the main project issue. ?

Yes, this is quite good solution but save some time every week :-).

One click, might add one related ticked in subproject (AJAX of course).

+1000 for that :-)

#6 Updated by Zarooba Rozruba over 12 years ago

Just noticed a related issue #443 . See if this helps.

Pozdrawiam

#7 Updated by Dipan Mehta over 8 years ago

+1. Given that now sub tasks exists - and they can be part of sub projects, I think essential thing here is that we should have a quick access UI which "create a copy as a sub ticket" and assign it to respective sub-project right away.

Actually the bigger challenge (and that might be useful) is that some specific fields of the main ticket controls the respective field of the sub-ticket. For example, if the customer info changes in the main ticket - the same should be reflected in this "sub-ticket". Currently, only such "controlled" fields are Start-Date Due-dates which are actually linked and cannot be changed arbitrarily. What you really want is that a set of fields, (and may be issue statuses) should also be changed once, say in main ticket and reflected everywhere.

Also available in: Atom PDF