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/15 16:50] – Configuration forms Martin Fuchs | mantisbt:issue:7970 [2009/01/06 15:46] (current) – update link to the demonstration pages MartinFuchs | ||
---|---|---|---|
Line 3: | Line 3: | ||
**Author**: Martin Fuchs | **Author**: Martin Fuchs | ||
- | |||
- | ===== Introduction ===== | ||
- | |||
- | 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. | ||
+ | ===== Introduction ===== | ||
+ | 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. 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 " | + | * 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 21: | 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 40: | 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**) 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. | ||
+ | . The list items should contain HTML links to go directly to the related Mantis entries. | ||
. 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 ===== | ===== Implementation ===== | ||
- | | + | |
+ | |||
+ | * To store the configuration data of external systems there could be created a new table ' | ||
+ | |||
+ | . system_id - integer | ||
+ | . name - string | ||
+ | . url - string | ||
+ | . username - string | ||
+ | . password - string | ||
+ | |||
+ | * new columns in table ' | ||
+ | |||
+ | . master_system_id - integer | ||
+ | . 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 | ||
+ | |||
+ | * FIXME There are needed one or more new tables to store the mapping definitions for automatically inserted new entries. | ||
+ | |||
+ | * FIXME more details... | ||
===== Feedback ===== | ===== Feedback ===== | ||
Line 54: | Line 78: | ||
Please add your comments and feedback in this section. | Please add your comments and feedback in this section. | ||
- | * | + | * The rationale for the external system is based on IT security issues. With internal and external issues in the same tracker, there is some possibility that external people might see these issues. [Glenn Henshaw] |
+ | |||
+ | * 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.1179262235.txt.gz · Last modified: 2008/10/29 04:36 (external edit)