View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007862 | mantisbt | bugtracker | public | 2007-03-28 08:56 | 2016-10-01 12:53 |
Reporter | bpieslak | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | new | Resolution | open | ||
Summary | 0007862: Allow a bug to be in multiple projects | ||||
Description | My company provides both product and services. 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? 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. | ||||
Tags | No tags attached. | ||||
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 |
|
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: can I use the RoadMap feature for PRODUCT1 to include all 3 issues? If we can maintain 1 RoadMap for a parent project and include issues in subprojects, then what you proposed would work perfectly. Thanks again, |
|
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 |
|
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. 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 CUSTOMER1 CUSTOMER2 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? |
|
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. |
|
ave, 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. Let me know if you still have questions, and I can provide more details. Thanks, |
|
hmmm ... synchronization would be the wrong approach in my eyes. 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. |
|
Hi, any updates on this issue ? |
|
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. |
|
up ! |
|
up |
|
Any chance to see this soon ? |
|