View Issue Details

IDProjectCategoryView StatusLast Update
0007862mantisbtbugtrackerpublic2016-10-01 12:53
Reporterbpieslak Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0007862: Allow a bug to be in multiple projects
Description

My company provides both product and services.
We are using Mantis to track issues for both product and services, creating individual projects for each product and each customer.

My company has recently gone through an exhaustive review to come up with best process for managing issues.

When a customer files an issue, that issue goes into the project for that customer. If that issue is found to be a product issue, that issue is moved from the customer's project into the product's project. The problem we have here is that the customer loses direct visibility into how that issue is resolved.

We have previously tried cloning the customer's issue and moving the clone into the product's project, but that also limits the customer's visibility into progress, because the product team only statuses the cloned issue and not the original customer issue.

As part of our review, our consensus was to avoid cloning.

The root idea is based on symbolic links in linux or shortcuts in windows.

Can I place an issue in one project that is really just a "link" to another issue in another project? Or can one issue exist in multiple queues?
(the current "related to" capability does not work for us because it requires 2 physically separate issues to be filed)

Yes - this has huge regression issues with reporting, since you could now introduce double-counting, but I believe that this capability would be massively valuable.

Please let me know if there is anything else I can provide to help explain my ideas in more detail.

TagsNo tags attached.

Relationships

has duplicate 0007165 closeddregad assign issue to multiple projects 
has duplicate 0011707 closeddregad Add possibility to have the same bug in several projects (bug reference) 
has duplicate 0019864 closeddregad Multiprogram issue 

Activities

giallu

giallu

2007-03-28 09:50

reporter   ~0014265

What if you try to use the subproject feature to accomplish what you trying to do?

Lets say you have the projects: USER1, USER2, PRODUCT1

Issues in subprojects shows up on the parent project, so you add the projects USER1 and USER2 as a subproject for PRODUCT1.

Developers browsing bugs for PRODUCT1 sees all issues coming from the USER1 and USER2 subprojects and could interact with them as you expect

bpieslak

bpieslak

2007-03-28 11:41

reporter   ~0014267

Thank you for the quick response.

We had looked into building our project structure that way, but we ran into limitations with the RoadMap.

If I contained the following project structure:
PRODUCT1
issue 0000001
CUSTOMER1
issue 0000002
CUSTOMER2
issue 0000003

can I use the RoadMap feature for PRODUCT1 to include all 3 issues?
I believe that we looked into this scenario and found that the RoadMap can only be applied to 1 project, and cannot include issues in subprojects. Is that correct?

If we can maintain 1 RoadMap for a parent project and include issues in subprojects, then what you proposed would work perfectly.

Thanks again,
Brian

giallu

giallu

2007-03-29 03:35

reporter   ~0014268

Unfortunately I can not really test how this works, because I have not access to a 1.1.x mantis installation with subprojects.

However, I had a look at sources for roadmap_page.php and AFAICT issues from subprojects should correctly show on the parent project roadmap, provided the user browsing it has the rights to access all of them.

If it does not work, that sounds like a (different) bug

bpieslak

bpieslak

2007-03-29 11:00

reporter   ~0014274

I talked with my colleague and we found that the RoadMap may have a bug in it.

From what we have found, if I want to create a RoadMap for PRODUCT1, that RoadMap cannot include issues from the CUSTOMER1 or CUSTOMER 2 subprojects.
Conversely, PRODUCT1 can see the roadmaps of the 2 subprojects, but then we'd have to maintain separate roadmaps for each subproject, which is not what we're looking for.

Another observation that a colleague made that makes the subproject approach problematic is that we want our CUSTOMER1 and CUSTOMER2 projects to also contain service-only issues, that have nothing to do with PRODUCT1.

Using the subproject approach, PRODUCT1 will report on issues in the CUSTOMER1 and CUSTOMER 2 subprojects that aren't related to PRODUCT1.

Here's our ideal scenario:

PRODUCT1
issue 0000001
issue #46
issue #47

CUSTOMER1
issue 0000002
<link to issue 0000001>

CUSTOMER2
issue 0000003
<link to issue #47>

This approach allows me to use isolated projects, and I can see all of the issues with PRODUCT1, CUSTOMER1, and CUSTOMER2.

Our thinking is that if CUSTOMER1 files a bug with PRODUCT1, it is filed into the CUSTOMER1 project. Our services team analyzes the bug and agrees that it is an issue with PRODUCT1. Our services team then moves that bug into the PRODUCT1 project. But by moving the issue, the CUSTOMER1 project no longer has any direct visibility into that bug. Our next thought was to "clone" the issue into the PRODUCT1 project, but you still lose visibility into the progress of the actual work being done to resolve the issue.

So the core idea for this feature request is that linking or sharing issues across multiple projects allows me to look at CUSTOMER1 and see ALL of the issues that CUSTOMER1 has, including both service and product related issues, from 1 single view.

Thoughts?
-Brian

ave

ave

2007-03-29 13:48

reporter   ~0014275

To me, at least, it seems to be strange that the service issues are appeared on the roadmap page because they may be not tied to particular versions.

I guess what you want is to define filters in the 'view issues' page of PRODUCT1, such as searching (1) issues targeted for particular version (you will have to define the same version in all projects) or (2) all the open issues.

Sorry if I missed your point.

bpieslak

bpieslak

2007-03-30 10:33

reporter   ~0014291

ave,
Thanks for the input.

The idea I'm looking for is actually the inverse of what you described.

Service issues would not appear in the Product's roadmap, but Product issues could appear in the Service's roadmap.

If CUSTOMER1 can have a link to issue 0000001 in PRODUCT1's queue, then I can use all of the built-in Mantis features, like standard reports and the new RoadMap feature for BOTH product & services by looking directly into 1 place for each.

The main reason why I want CUSTOMER1 to retain a link to issue#1 is because they filed it. If a customer files an issue to a services team, the services team is responsible for staying on-top of that issue and resolving it for the customer. But if the services team says that its a product issue, then the product team needs to address it.

I want my services team looking in 1 place for everything they are responsible for, and I want my product team to do the same.

Previously, the only way to accomplish this was to clone the original issue in the CUSTOMER1 project, and to move the clone over into PRODUCT1 project.

The downside I see to cloning is that the original issue in CUSTOMER1 is not updated when child issue in PRODUCT1 is updated. So CUSTOMER1 doesn't see that the product team is actively working on their issue.

Another idea that we came up with was to add a "synchronization" feature to the links between issues.
If I could "synchronize" the original issue with the cloned issue, then cloning would work for our needs.

Let me know if you still have questions, and I can provide more details.

Thanks,
-Brian

steffel

steffel

2009-01-22 02:45

reporter   ~0020681

hmmm ... synchronization would be the wrong approach in my eyes.
because you have two separate issues and when someone changes one of them, the other one will be changed, too - this could be confusing.
and on the other hands - this is a kind of replication and may be tricky to implement ... moreover there is a danger of inconsistency ... (?)

i would really prefer a solution with some kind of linking (thus, just one unique issue), so that we just see 1 issue linked to more project patches in the roadmap.

chrisdi

chrisdi

2010-11-10 08:54

reporter   ~0027328

Hi, any updates on this issue ?

bpieslak

bpieslak

2010-11-10 08:58

reporter   ~0027329

It's been a long time since I looked at this issue, so I didn't see steffel's comment.

I agree with steffel that we don't want to have to synchronize 2 issues, since it really is just 1 unique issue.

I like the idea of allowing an issue from 1 project to be visible on another project's roadmap.

Kyle_Katarn

Kyle_Katarn

2016-05-04 16:45

reporter   ~0053061

up !

Kyle_Katarn

Kyle_Katarn

2016-07-20 18:31

reporter   ~0053671

up

Kyle_Katarn

Kyle_Katarn

2016-09-29 16:19

reporter   ~0054097

Any chance to see this soon ?

Issue History

Date Modified Username Field Change
2007-03-28 08:56 bpieslak New Issue
2007-03-28 09:50 giallu Note Added: 0014265
2007-03-28 11:41 bpieslak Note Added: 0014267
2007-03-29 03:35 giallu Note Added: 0014268
2007-03-29 11:00 bpieslak Note Added: 0014274
2007-03-29 13:48 ave Note Added: 0014275
2007-03-30 10:33 bpieslak Note Added: 0014291
2009-01-22 02:45 steffel Note Added: 0020681
2009-02-19 16:03 giallu Relationship added related to 0007165
2010-11-10 08:54 chrisdi Note Added: 0027328
2010-11-10 08:58 bpieslak Note Added: 0027329
2012-02-27 20:18 dregad Relationship replaced has duplicate 0007165
2012-02-27 20:19 dregad Relationship added has duplicate 0011707
2015-06-21 14:40 atrol Relationship added related to 0019864
2016-05-04 16:45 Kyle_Katarn Note Added: 0053061
2016-07-20 18:31 Kyle_Katarn Note Added: 0053671
2016-09-29 16:19 Kyle_Katarn Note Added: 0054097
2016-10-01 12:53 dregad Relationship replaced has duplicate 0019864