Project

General

Profile

Forums » Open discussion »

Multiple project contained multiple modules. (Many-to-many ralation)

Added by Sergey Volkodav over 11 years ago

I want to use reamine, but i can't find how to solve my problem
The problem is i have multiple project which contain multiple modules (Many-to-many ralation).

  • Same modules can be included to different projects;
  • For modules and projects could be assigned version;

For example:
Project 1, Project 2; Modules A (ver 1.0), Modules A (ver. 2.0), Modules B (ver 5.0), Module C (ver 7.0)

Project 1 (ver 1.0) include : Module A (ver 1.0), Module B (ver 5.0)
Project 1 (ver 2.0) include : Module A (ver 2.0), Module B (ver 5.0)
Project 2 (ver 3.5) include : Module A (ver 1.0), Module C (ver 7.0)

Thank's


Replies (3)

RE: Multiple project contained multiple modules. (Many-to-many ralation) - Added by Ralph Twele over 11 years ago

Hi Sergey,

I am currently facing the same problem. I have an idea but not yet verified if it is doable:

Based on your example the idea is to have Redmine projects per module and project. Let's say:

  • Module A (Versions: 1.0 + 2.0)
  • Module B (Versions: 5.0)
  • Module C (Versions: 7.9)
  • Project 1
  • Project 2

E.g. in Project 1 you add all tasks required for this project. Some of them affect Module A, some Module B, some affect no specific module. Wouldn't it be possible via related tickets to copy the Module A tickets into Redmine project Module A, let the developer process and close it in Module A and let the "related ticket functionality" close it automatically in Project 1?

Perhaps you have already found a solution. I would be interested to know.

Regards,
Ralph

RE: Multiple project contained multiple modules. (Many-to-many ralation) - Added by Bernd Worsch over 11 years ago

Hi There,

i've been thinking about ways to solve this but haven't come up with a solution yet. Sharing thoughts non the less.

Situation:
We use Redmine to handle various types of projects. Among them are building solutions based on our software system (customerprojects) and improving the various components of our software system (componentprojects). It is common that a ticket originates from a customerproject but belongs to a compontproject also.

Findings:
First i thought it would do to link the original ticket to one or more other projects but actualy this is too simplistic. Every ticket has certain core attributes that remain the same across projects. Other attributes model the relation or impact a ticket has for a specific project. These attributes change depending on the project context. Currently i think what we need to adress this properly is the possibility to add tickets that are no real tickets but slaves to their ticket master. Slaves lack the core attributes but derive them from their master ticket. They hold attributes that model the relation to some project and behave like real tickets. For usability purposes i think changing core attributes in the slave should change the master ticket.

How to implement:
For the moment i dropped the idea of establishing a global list of which attributes are core attributes and which are not. Instead i favor the option of adding a list of slave attributes to a slave ticket. Slave attributes will inherit their value from the master ticket. One could even think of inheriting values from different tickets.

    (1-3/3)