View Issue Details

IDProjectCategoryView StatusLast Update
0010543mantisbtrelationshipspublic2010-02-09 04:40
Reporteroberger Assigned To 
Status acknowledgedResolutionopen 
Summary0010543: Proposal: Relationships to external bugs in remote bugtrackers

We propose to add to mantis a plug-in which could help managing relationships between bugs in a Mantis instance, and external bugs in remote bugtrackers (not necessarily mantis)

Additional Information

Will be described in the wiki (link to be added later)



related to 0009940 closedvboctor Create on Integration Plugin for Launchpad 




2009-05-27 08:42

reporter   ~0021936

We'd be delighted to Create a new dokuwiki page, but currently can't (insufficient privileges ?)

In the meantime, here's what was drafted internally :

Should someone please copy that to so that all can amend the proposal ?



2009-05-27 12:54

manager   ~0021943

I haven't reviewed the drafted requirements yet, but I've created a wiki page for this issue. You should have enough access to edit it.



2009-05-27 13:40

reporter   ~0021944

Thanks Victor.



2009-05-28 09:04

reporter   ~0021956

FYI, is ready for review... feel free to comment here or in the wiki page.



2009-05-28 09:06

reporter   ~0021957

See also some related discussions initially sent on the ML :

2009-05-29 09:23


snapshot1.png (77,198 bytes)   
snapshot1.png (77,198 bytes)   


2009-06-10 10:17

reporter   ~0022069

oberger, sorry if I've missed this, but is the source code for the plugin (or whatever you used to make your screenshot) publicly available? If so, where at, and would you considering making it available on MantisForge? [1]





2009-06-10 10:53

reporter   ~0022071

This is a great idea.

I've read through your proposal on the Wiki and have some comments and discussion to add.

  1. It sounds like this feature is going to require so much modification to the current relationships feature built into Mantis, that it is essentially a rewrite? I'm unsure on whether this new proposal would be best placed in a plugin because it sounds like it'll still need some heavy modifications to the Mantis core. And there is ongoing discussion at the moment about where plugins are hosted, who maintains them, etc. IMO it is best if the Mantis project took on some key plugins as "official plugins" to help guarantee that they don't die or become unmaintained, as is often the case with plugins in other applications.

  2. I think the only new relationships needed are "upstream bug" and "downstream bug" or something along those lines. As you stated, it is best if the existing "related to", "child of" and "parent of" relationships also work remotely.

  3. What do you do if a ticket has a relationship to each of two different upstream bugs on different trackers? You'd need to wait for all upstream bugs to report the same status before automatically closing the local Mantis ticket. This also poses the problem of needing the user to specify the relation between statuses on a remote tracker, and the local Mantis tracker. Essentially you'll need to have user-adjustable thresholds for each upstream tracker linked to the local Mantis install to define what the closed/resolved/open statuses are on the remote trackers.

  4. From (3) I propose that it is necessary for this new feature to have a database table that stores configuration data on each remote tracker linked to the current Mantis install. The user can then specify the method used for accessing the remote bug tracker (SOAP, etc) where a choice exists, the URL, username, password, whether to use TLS, the remote status that corresponds to a closed/resolved/etc ticket, etc.

  5. Because (4) is a lot of work for users who just want to report a bug, should the new feature you're developing try to figure things out by itself (assuming default settings on the remote tracker)? At the least it should simply not poll or push updates to the remote tracker unless the remote bug tracker has been properly configured. Maybe it'd be a good idea to include some popular defaults as part of the feature (Ubuntu, Debian, Gentoo, etc) to give users a quick head start (and some examples to work off)?

  6. Should this new feature push changes to a remote tracker, or pull changes... or both? This sounds like something that needs to be configured on a per-remote-tracker basis in case your remote tracker happens to be a similar Mantis install. You don't want tracker 1 to push changes to tracker 2 while tracker 2 concurrently duplicates that effort by pulling the changes from tracker 1.

  7. Custom fields - how to synchronise or use custom fields when the remote trackers may not support the custom field being used locally?

  8. I disagree with the proposal to log "agent events" when the remote bug tracker is polled. This information should already be viewable on the remote bug tracker if the user clicks the link to view the remote bug report. There is no need to duplicate this existing information.

  9. Regarding the whole concept of polling other tracker - doing this on a cycle sounds like bad form to me. It simply doesn't scale, and will always be a long way off being real time. Imagine having 1000 bugs on your local install of Mantis and each of them is linked to a remote bug. Do you really want to make 1000 remote requests to those trackers every hour (or whatever your interval is)? You'd need to check both open and closed bugs to see if bugs have both been resolved or reopened.

  10. I think you'd need to check the relationships of remote bugs before showing a local Mantis bug to the user. This takes time... maybe 2-3 seconds per remote bug you're checking (to see if it has been resolved/reopened/etc). You'd also need to have a minimum time between checks to prevent flooding and DoS attacks on smaller trackers. If you have a bug on your local install of Mantis that tracks a security flaw, it will most likely be linked to 0000007:0000015-20 remote bug trackers for all the main Linux distributions that create a new security ticket for each CVE/etc number. Can you check the status of all 15-20 remote bugs asynchronously when viewing the local bug on Mantis? Or do you have to wait while all 20 bugs are checked in a serial blocking way?



2009-06-10 10:55

reporter   ~0022072

Also in terms of architecture, you should check out the source-integration plugin at for a good example of how to use plugins. I was thinking that each remote bug tracker type would need its own plugin (mantis, launchpad, bugzilla, trac, etc) to handle the communication and interface with the remote tracker.



2009-07-03 10:49

reporter   ~0022365

jreese, please find here the link to our on-going work:;h=refs/heads/ext_plugin



2009-07-03 12:06

reporter   ~0022366

dhx, thanks for your comments and suggestions.

Currently, we are trying to keep the external relationship similar to, but separate from, the in-built mantis relationships. However, it is true that making it viewable along with the other bug information, requires a certain amount of modification. We await the response of others in the mantis community to see their view. Our work has been added to the mantis git repository and the link provided in my previous post.

The initial version of our feature will have a link to the external bug whose status would be tracked by an external agent, bts-link, in this case. There would be some functionality provided like, automatic closing of a local bug when its corresponding external bugs are closed. We are not looking at customised settings and behaviour for each remote tracker for the first version.

Nothing will be pushed to remote trackers. Bts-link, running on the local mantis, will poll the remote trackers and update the changes in the local one.

Regarding logging agent events, we will look into whether to keep previous change information or not. Like you said, as the information is already available, we might drop the idea.

As for the polling of remote bugtrackers, things have to be finalised still. There might be a special status for bugs tracking security flaws, which will have their corresponding external bugs' tracked asynchronously.



2009-08-04 11:19

reporter   ~0022658

FYI, a similar feature (although less advanced ;) has been implemented in bugzilla 3.4, apparently :

Issue History

Date Modified Username Field Change
2009-05-27 08:37 oberger New Issue
2009-05-27 08:42 oberger Note Added: 0021936
2009-05-27 08:53 jreese Relationship added related to 0009940
2009-05-27 12:54 vboctor Note Added: 0021943
2009-05-27 13:40 oberger Note Added: 0021944
2009-05-28 09:04 oberger Note Added: 0021956
2009-05-28 09:06 oberger Note Added: 0021957
2009-05-28 09:06 oberger Tag Attached: bts_link
2009-05-29 09:23 mdhar File Added: snapshot1.png
2009-06-10 10:17 jreese Note Added: 0022069
2009-06-10 10:53 dhx Note Added: 0022071
2009-06-10 10:55 dhx Note Added: 0022072
2009-07-03 10:49 mdhar Note Added: 0022365
2009-07-03 12:06 mdhar Note Added: 0022366
2009-07-03 14:02 vboctor Status new => acknowledged
2009-08-04 11:19 oberger Note Added: 0022658