Differences

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

--- mantisbt:issue:7970 [2007/05/19 16:50] – links to the reference implementation of a MantisWS report 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
@@ Line 7: / Line 8: @@
 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. 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 reporting functionality.
+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**" [[http://shell.franken.de/~sky/mantis_extern/]]) with customer access and another instance with access for developers also containing some entries hidden from the customer (let's call it "**intern**" [[http://shell.franken.de/~sky/mantis_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 36: / 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** [[http://shell.franken.de:23090/mantisreports/cross-reference]]) 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.