Differences

This shows you the differences between two versions of the page.

--- mantisbt:issue:7970 [2007/05/17 12:09] – Martin Fuchs
+++ mantisbt:issue:7970 [2009/01/06 15:46] (current) – update link to the demonstration pages MartinFuchs
@@ Line 2: / Line 2: @@
 **Author**: Martin Fuchs
 ===== Introduction =====
-There has been a recent discussion on the mailing list about synchronization between different mantis instances and "bug replication". There seem exist alreafy a few home brewn tools to full fill the main requirements, but there is still missing a generalized solution. I have also written some utilities for our special environment, but they ae implemented in C++ and Java, as I am not a PHP programmer. They are also using a Web service, but are independent from MantisConnect. This are the reasons why I guess you are not willing to take my code as starting point. ;-)
+There has been a recent discussion on the mailing list about synchronization between different mantis instances and "bug replication". There seem exist already a few home brewn tools to full fill the main requirements, but there is still missing a generalized solution. I have also written some utilities for our special environment, but they are implemented in C++ and Java, as I am not a PHP programmer. They are also using a Web service, but are independent from MantisConnect. This are the reasons why I guess you are not willing to take my code as starting point. ;-)
-So let's start again with the design phase and write down the requirements for a synchronization solution between different Mantis instances in this Wiki page.
+So let's start again with the design phase and write down the requirements for a synchronization solution between different Mantis instances in this Wiki page. In the following descriptions there are some links to my Mantis test installation, which can be used as a reference implementation to see a living example of two connected instances with [[http://shell.franken.de:23080/mantisreports/cross-reference|reporting functionality]]). [[http://www.sky.franken.de/screenshots/mantisws-client.png|Here is a screenshot]] of the client application I am using to manually copy the entries of one instance to another.
 ===== Requirements =====
-  * A common setup is the installation of one Mantis instance (let's call it "**extern**") with customer access and another instance with access for developers also containing some entries hidden from the customer (let's call it "**intern**"), may be also containing notes generated by CVS/SVN commits. The entries of this two Mantis instances should be synchronized. The relationship between the two instances is a master/slave relation: The external instance can be used to enter new issues from the outer side. This should become immediately visible in the internal instance. But the master for the entry status is located in the internal instance. (May it would be useful to be able to configure a master detail chain with more than two instances.)
+  * A common setup is the installation of one Mantis instance (let's call it **[[http://shell.franken.de:23080/mantis_extern/|"extern"]]**) with customer access and another instance with access for developers also containing some entries hidden from the customer (let's call it **[[http://shell.franken.de:23080/mantis_intern/|"intern"]]**), may be also containing notes generated by CVS/SVN commits. The entries of this two Mantis instances should be synchronized. The relationship between the two instances is a master/slave relation: The external instance can be used to enter new issues from the outer side. This should become immediately visible in the internal instance. But the master for the entry status is located in the internal instance. (May it would be useful to be able to configure a master detail chain with more than two instances.)
   * It should be possible to host the two instances on two different machines to separate internal and external networks.
@@ Line 44: / Line 38: @@
    . In the internal instance there are stored the URLs to immediately jump to the external entries.
-  * To be able to divide an external entry into several internal subtasks (maybe with different assignees), it should be possible to associate a slave entry with more than one entry in the master instance. When replicating the status from several master entries to the slave instance, the resulting status is calculated as the maximum value of all associated master status values.
+  * To be able to divide an external entry into several internal subtasks (maybe with different assignees), it should be possible to associate a slave entry with more than one entry in the master instance. When replicating the status from several master entries to the slave instance, the resulting status is calculated as the minimum value of all associated master status values.
-  * There should be an overview page (**Report**) in the master instance showing a cross reference with the list of related entries of both instances side by side:
+  * There should be an overview page (**[[http://shell.franken.de:23080/mantisreports/cross-reference|Report]]**) in the master instance showing a cross reference with the list of related entries of both instances side by side:
   . Following Attributes should be displayed on both sides: ID, Status, Severity, Summary. Other columns to display could be configured optionally.
@@ Line 87: / Line 81: @@
     * Perhaps this is beyond the scope of the immediate goals, but imagine an interface which any bug tracker could implement and allowed replication or query between any tool which implemented it. The Eclipse Mylar project goes part of the way toward this goal, but by creating custom Mylar connectors per bug tracker. If a standard set of interfaces for getTask(id)->task, createTask (task), etc. were created, along with standard definitions of the structure of a task and its relationships, then this would be certainly possible. Interactions could be not just between task trackers, but also between CRM or ERP systems and task trackers. Imagine being able to create a simple dashboard widget (for those OSX users out there) which allowed creating new tasks against a range of task trackers. Or completely abstracting the front end (GUI) from the database and business logic. Mantis attempts this with the API methods, but there isn't always a good separation. From my research, most bug trackers are pretty similar in terms of database structure. Sure, it is more work, but the potential benefits of creating an open generic API are huge. Several transports are possible, but possibly SOAP is one of the easiest and most adaptable. I wonder if developers from other projects would be interested in collaborating. [Aristedes Maniatis]
+    * I think it's important to note that this feature should be part of Mantis, so we should try to solve this with PHP. It Should be VERY interesting to approach this issue looking for a mechanism capable to replicate bugs to other bug trackers (trac ??), so we can expand this idea (in long term) to others bug trackers. A mechanism to verify bugs replication should be developed. [Matias Torchinsky]