mantisbt:issue:7970
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:issue:7970 [2007/05/17 05:03] – name column added 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 | **Author**: Martin Fuchs | ||
+ | |||
===== Introduction ===== | ===== Introduction ===== | ||
- | There has been a recent discussion on the mailing list about synchronization between different mantis instances and "bug replication" | + | There has been a recent discussion on the mailing list about synchronization between different mantis instances and "bug replication" |
- | 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, |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
===== Requirements ===== | ===== 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/ | + | * A common setup is the installation of one Mantis instance (let's call it **[[http:// |
* It should be possible to host the two instances on two different machines to separate internal and external networks. | * It should be possible to host the two instances on two different machines to separate internal and external networks. | ||
Line 23: | Line 19: | ||
* The configuration of replication features should be on a per project base, so it's possible for example to activate synchronization only for part of the existing projects. | * The configuration of replication features should be on a per project base, so it's possible for example to activate synchronization only for part of the existing projects. | ||
- | * There should be the possibility to configure a mapping for different attributes between the two instances like category, assignees and may be status. | + | * There should be the possibility to configure a **mapping** for different attributes between the two instances like category, assignees and may be status. |
- | * Configuration should be available via web forms for users with administrator access. | + | |
- | * There should be an user interface to synchronize entries in both directions. | + | * There should be an user interface to **manually** |
* When duplicating entries from the external to the internal instance, it is sufficient to insert HTML links to attached files instead of copying the whole data. | * When duplicating entries from the external to the internal instance, it is sufficient to insert HTML links to attached files instead of copying the whole data. | ||
- | * The following things should be synchronized automatically when altering an entry: | + | * The following things should be synchronized |
. new entries from slave to master | . new entries from slave to master | ||
Line 42: | Line 38: | ||
. In the internal instance there are stored the URLs to immediately jump to the external entries. | . In the internal instance there are stored the URLs to immediately jump to the external entries. | ||
- | * There should be an overview page (**Report**) in the master instance showing 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. | . Following Attributes should be displayed on both sides: ID, Status, Severity, Summary. Other columns to display could be configured optionally. | ||
Line 48: | Line 46: | ||
. Filtering functionality at least for the status is very useful in this list, for example to get a quick overview of open issues. | . Filtering functionality at least for the status is very useful in this list, for example to get a quick overview of open issues. | ||
+ | ===== Implementation ===== | ||
+ | * As Mantis is a PHP application, | ||
+ | * To store the configuration data of external systems there could be created a new table ' | ||
- | ===== Implementation ===== | + | . system_id - integer |
+ | . name - string | ||
+ | . url - string | ||
+ | . username - string | ||
+ | . password - string | ||
- | * As Mantis is a PHP application, | + | * new columns in table ' |
+ | |||
+ | . master_system_id | ||
+ | . slave_system_id - integer | ||
+ | |||
+ | * new columns in table ' | ||
+ | |||
+ | . master_system_id - integer | ||
+ | . slave_system_id - integer | ||
+ | . master_bug_ids - string (list of associated master bug IDs separated by spaces) | ||
+ | . slave_bug_id - integer | ||
- | * To store the configuration data of external systems there could be created a new table ' | + | * FIXME There are needed one or more new tables |
- | * new columns in table ' | + | |
- | * new columns in table ' | + | |
* FIXME more details... | * FIXME more details... | ||
Line 68: | 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)-> | * 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)-> | ||
+ | |||
+ | * 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] | ||
+ |
mantisbt/issue/7970.1179392592.txt.gz · Last modified: 2008/10/29 04:36 (external edit)