From: Torchinsky, M. <ma...@ca...> - 2007-05-14 00:00:45
|
Hi List I'm looking for a tool or plugin/addon/config (is there is one) which help = me with this problem. One of our clients has his own implementation of mantis. What i'm looking f= or is to know if there is a way to do the following : Every time someone post a new bug in certain issue on our client mantis im= plementation, automatically propagate this request to our own mantis implem= entataion.Them, when any developer (from our side do something about the ne= w bug) automatically propagate the new status to our client , so , we could= remain "synchronized". I had seen some plugins or tools (http://www.futureware.biz/mantisconnect/= ), but none of them seems to fix the problem. Any ideas ? It's important to note. I'm not looking for a tool to synchronize 2 mantis,= just to keep syncrhonize 2 mantis about certain bugs. Hope i explain mysel= f. thanks ! matt.- Visite http://www.cablevision.com.ar Visite http://www.fibertel.com.ar ___________________________________________________________________________ Este mensaje es confidencial. Puede contener informacion amparada por el se= creto comercial. Si usted ha recibido este e-mail por error, debera eliminarlo de su sistem= a. No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muc= has gracias. This message is confidential. It may also contain information that is privi= leged or not authorized to be disclosed. If you have received it by mistake, delete it = from your system. You should not copy the messsage nor disclose its contents to anyone. Many = thanks. ___________________________________________________________________________ |
From: Victor B. <vb...@gm...> - 2007-05-14 06:14:04
|
Hi Matt, Your best bet is to download the latest code of MantisConnect and it's sample. There is a PHP sample that uses Mantis to export issues from one installation to another. However, it doesn't sync back. You can build on top of this so that it works both ways. If you do anything interesting in this area, please consider contributing back. Also don't forget to check the MantisConnect license. On 5/13/07, Torchinsky, Matias <ma...@ca...> wrote: > > > > Hi List > I'm looking for a tool or plugin/addon/config (is there is one) which help > me with this problem. > One of our clients has his own implementation of mantis. What i'm looking > for is to know if there is a way to do the following : > Every time someone post a new bug in certain issue on our client mantis > implementation, automatically propagate this request to our own mantis > implementataion.Them, when any developer (from our side do something about > the new bug) automatically propagate the new status to our client , so , we > could remain "synchronized". > I had seen some plugins or tools > (http://www.futureware.biz/mantisconnect/), but none of > them seems to fix the problem. Any ideas ? > It's important to note. I'm not looking for a tool to synchronize 2 mantis, > just to keep syncrhonize 2 mantis about certain bugs. Hope i explain myself. > > thanks ! > matt.- > > > > > > Visite http://www.cablevision.com.ar > > Visite http://www.fibertel.com.ar > > > > > > ___________________________________________________________________________ > > Este mensaje es confidencial. Puede contener informacion amparada por el > secreto comercial. > > Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema. > > No debera copiar el mensaje ni divulgar su contenido a ninguna persona. > Muchas gracias. > > > > > > This message is confidential. It may also contain information that is > privileged or not > > authorized to be disclosed. If you have received it by mistake, delete it > from your system. > > You should not copy the messsage nor disclose its contents to anyone. Many > thanks. > > ___________________________________________________________________________ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: Torchinsky, M. <ma...@ca...> - 2007-05-14 14:44:39
|
Done ! Thank you the orientation. I Will try to do something with that.=20 =20 matt.- -----Original Message----- From: man...@li... on behalf of Victor = Boctor Sent: Mon 5/14/2007 3:13 AM To: developer discussions Subject: Re: [mantisbt-dev] bug replication =20 Hi Matt, Your best bet is to download the latest code of MantisConnect and it's sample. There is a PHP sample that uses Mantis to export issues from one installation to another. However, it doesn't sync back. You can build on top of this so that it works both ways. If you do anything interesting in this area, please consider contributing back. Also don't forget to check the MantisConnect license. On 5/13/07, Torchinsky, Matias <ma...@ca...> wrote: > > > > Hi List > I'm looking for a tool or plugin/addon/config (is there is one) which = help > me with this problem. > One of our clients has his own implementation of mantis. What i'm = looking > for is to know if there is a way to do the following : > Every time someone post a new bug in certain issue on our client = mantis > implementation, automatically propagate this request to our own mantis > implementataion.Them, when any developer (from our side do something = about > the new bug) automatically propagate the new status to our client , so = , we > could remain "synchronized". > I had seen some plugins or tools > (http://www.futureware.biz/mantisconnect/), but none of > them seems to fix the problem. Any ideas ? > It's important to note. I'm not looking for a tool to synchronize 2 = mantis, > just to keep syncrhonize 2 mantis about certain bugs. Hope i explain = myself. > > thanks ! > matt.- > > > > > > Visite http://www.cablevision.com.ar > > Visite http://www.fibertel.com.ar > > > > > > = _________________________________________________________________________= __ > > Este mensaje es confidencial. Puede contener informacion amparada por = el > secreto comercial. > > Si usted ha recibido este e-mail por error, debera eliminarlo de su = sistema. > > No debera copiar el mensaje ni divulgar su contenido a ninguna = persona. > Muchas gracias. > > > > > > This message is confidential. It may also contain information that is > privileged or not > > authorized to be disclosed. If you have received it by mistake, delete = it > from your system. > > You should not copy the messsage nor disclose its contents to anyone. = Many > thanks. > > = _________________________________________________________________________= __ > > > = -------------------------------------------------------------------------= > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -------------------------------------------------------------------------= This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Glenn H. <thr...@lo...> - 2007-05-14 19:32:48
|
On 13-May-07, at 8:00 PM, Torchinsky, Matias wrote: > Hi List > I'm looking for a tool or plugin/addon/config (is there is one) > which help me with this problem. > One of our clients has his own implementation of mantis. What i'm > looking for is to know if there is a way to do the following : > Every time someone post a new bug in certain issue on our client > mantis implementation, automatically propagate this request to our > own mantis implementataion.Them, when any developer (from our side > do something about the new bug) automatically propagate the new > status to our client , so , we could remain "synchronized". > I had seen some plugins or tools (http://www.futureware.biz/ > mantisconnect/), but none of them seems to fix the problem. Any > ideas ? > It's important to note. I'm not looking for a tool to synchronize 2 > mantis, just to keep syncrhonize 2 mantis about certain bugs. Hope > i explain myself. > I built a similar customization for a client recently. They had an external database copy that was the slave to a master internal database. Bugs updated in the external database were synchronized to the internal one. I'm thinking about generalizing it if there is interest. -- Glenn Henshaw Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User |
From: Martin F. <mar...@gm...> - 2007-05-14 19:45:12
|
Hello, > I built a similar customization for a client recently. They had an > external database copy that was the slave to a master internal > database. Bugs updated in the external database were synchronized to > the internal one. > I'm thinking about generalizing it if there is interest. This seems to be a very common setup: an external Mantis instance with access for the cusomer and an internal Mantis installation for developer access and internal bug tracking. We are using this schema and I wrote a little utility to copy entries between the different Mantis instances (using a C++ web service on a server and a Windows client for the user interface). Here we are also using a Tomcat servlet to display the entries of the two connected Mantis instances, compare the different states and provide a meaniungful overview of the active entries. It's all not quite ready to be made public - but may be we could share some ideas to build a general solution? Regards, Martin |
From: Torchinsky, M. <ma...@ca...> - 2007-05-14 20:52:49
|
Well,=20 I'm interested to open a discussion and help to contribute for a good desig= n. Meanwhile, will be helpfull if there is any implementation that could be ma= de public to start looking over it.=20 How Should be proceed ? regards=20 matt.- -----Original Message----- From: man...@li... on behalf of Martin Fuchs Sent: Mon 5/14/2007 3:37 PM To: developer discussions Subject: Re: [mantisbt-dev] bug replication =20 Hello, > I built a similar customization for a client recently. They had an =20 > external database copy that was the slave to a master internal =20 > database. Bugs updated in the external database were synchronized to =20 > the internal one. > I'm thinking about generalizing it if there is interest. This seems to be a very common setup: an external Mantis instance with access for the cusomer and an internal Mantis installation for developer access and internal bug tracking. We are using this schema and I wrote a little utility to copy entries between the different Mantis instances (using a C++ web service on a server and a Windows client for the user interface). Here we are also using a Tomcat servlet to display the entries of the two connected Mantis instances, compare the different states and provide a meaniungful overview of the active entries. It's all not quite ready to be made public - but may be we could share some ideas to build a general solution? Regards, Martin ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev Visite http://www.cablevision.com.ar Visite http://www.fibertel.com.ar ___________________________________________________________________________ Este mensaje es confidencial. Puede contener informacion amparada por el se= creto comercial. Si usted ha recibido este e-mail por error, debera eliminarlo de su sistem= a. No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muc= has gracias. This message is confidential. It may also contain information that is privi= leged or not authorized to be disclosed. If you have received it by mistake, delete it = from your system. You should not copy the messsage nor disclose its contents to anyone. Many = thanks. ___________________________________________________________________________ |
From: Victor B. <vb...@gm...> - 2007-05-14 20:57:13
|
How about creating an issue in the bug tracker and attaching implementations to it. The wiki page associated with the issue can be used to document the current solution and what would be a good generalized solution. On 5/14/07, Torchinsky, Matias <ma...@ca...> wrote: > Well, > I'm interested to open a discussion and help to contribute for a good design. > Meanwhile, will be helpfull if there is any implementation that could be made public to start looking over it. > > How Should be proceed ? > regards > matt.- > > > > -----Original Message----- > From: man...@li... on behalf of Martin Fuchs > Sent: Mon 5/14/2007 3:37 PM > To: developer discussions > Subject: Re: [mantisbt-dev] bug replication > > Hello, > > > I built a similar customization for a client recently. They had an > > external database copy that was the slave to a master internal > > database. Bugs updated in the external database were synchronized to > > the internal one. > > > I'm thinking about generalizing it if there is interest. > > This seems to be a very common setup: an external Mantis instance > with access for the cusomer and an internal Mantis installation for > developer access and internal bug tracking. > We are using this schema and I wrote a little utility to copy entries > between the different Mantis instances (using a C++ web service on > a server and a Windows client for the user interface). > > Here we are also using a Tomcat servlet to display the entries of the > two connected Mantis instances, compare the different states and > provide a meaniungful overview of the active entries. > > It's all not quite ready to be made public - but may be we could share > some ideas to build a general solution? > > Regards, > > Martin > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > Visite http://www.cablevision.com.ar > Visite http://www.fibertel.com.ar > > ___________________________________________________________________________ > Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial. > Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema. > No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. > > This message is confidential. It may also contain information that is privileged or not > authorized to be disclosed. If you have received it by mistake, delete it from your system. > You should not copy the messsage nor disclose its contents to anyone. Many thanks. > ___________________________________________________________________________ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > |
From: Martin F. <mar...@gm...> - 2007-05-15 07:02:03
|
OK, I started by entering a mantis issue and would like to write down the requirements for a generlized solution in the Wiki. Would you please create the new associated page http://www.mantisbt.org/wiki/doku.php?id=mantisbt%3Aissue%3A7970 for the entry http://bugs.mantisbt.org/view.php?id=7970 or give me the permissions to create it myself? Thanks, Martin On 14.05.2007 13:57:12 Victor Boctor wrote: > How about creating an issue in the bug tracker and attaching > implementations to it. The wiki page associated with the issue can be > used to document the current solution and what would be a good > generalized solution. > On 5/14/07, Torchinsky, Matias <ma...@ca...> wrote: > > Well, > > I'm interested to open a discussion and help to contribute for a good > design. > > Meanwhile, will be helpfull if there is any implementation that could be > made public to start looking over it. > > > > How Should be proceed ? > > regards > > matt.- > > > > > > > > -----Original Message----- > > From: man...@li... on behalf of Martin Fuchs > > Sent: Mon 5/14/2007 3:37 PM > > To: developer discussions > > Subject: Re: [mantisbt-dev] bug replication > > > > Hello, > > > > > I built a similar customization for a client recently. They had an > > > external database copy that was the slave to a master internal > > > database. Bugs updated in the external database were synchronized to > > > the internal one. > > > > > I'm thinking about generalizing it if there is interest. > > > > This seems to be a very common setup: an external Mantis instance > > with access for the cusomer and an internal Mantis installation for > > developer access and internal bug tracking. > > We are using this schema and I wrote a little utility to copy entries > > between the different Mantis instances (using a C++ web service on > > a server and a Windows client for the user interface). > > > > Here we are also using a Tomcat servlet to display the entries of the > > two connected Mantis instances, compare the different states and > > provide a meaniungful overview of the active entries. > > > > It's all not quite ready to be made public - but may be we could share > > some ideas to build a general solution? > > > > Regards, > > > > Martin > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > mantisbt-dev mailing list > > man...@li... > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > > > Visite http://www.cablevision.com.ar > > Visite http://www.fibertel.com.ar > > > > > ___________________________________________________________________________ > > Este mensaje es confidencial. Puede contener informacion amparada por el > secreto comercial. > > Si usted ha recibido este e-mail por error, debera eliminarlo de su > sistema. > > No debera copiar el mensaje ni divulgar su contenido a ninguna persona. > Muchas gracias. > > > > This message is confidential. It may also contain information that is > privileged or not > > authorized to be disclosed. If you have received it by mistake, delete > it from your system. > > You should not copy the messsage nor disclose its contents to anyone. > Many thanks. > > > ___________________________________________________________________________ > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > mantisbt-dev mailing list > > man...@li... > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Victor B. <vb...@gm...> - 2007-05-15 07:50:33
|
Hi Martin, On 5/14/07, Martin Fuchs <mar...@gm...> wrote: > OK, I started by entering a mantis issue and would like to write down the > requirements for a generlized solution in the Wiki. Would you please > create the new associated page > http://www.mantisbt.org/wiki/doku.php?id=mantisbt%3Aissue%3A7970 > for the entry http://bugs.mantisbt.org/view.php?id=7970 > or give me the permissions to create it myself? Page created. Regards, Victor |
From: Aristedes M. <ar...@is...> - 2007-05-15 23:35:38
|
Perhaps this is beyond the scope of your 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. Cheers Ari Maniatis On 15/05/2007, at 3:59 PM, Martin Fuchs wrote: > OK, I started by entering a mantis issue and would like to write > down the > requirements for a generlized solution in the Wiki. Would you please > create the new associated page > http://www.mantisbt.org/wiki/doku.php?id=mantisbt%3Aissue%3A7970 > for the entry http://bugs.mantisbt.org/view.php?id=7970 > or give me the permissions to create it myself? > > Thanks, > > Martin > > On 14.05.2007 13:57:12 Victor Boctor wrote: >> How about creating an issue in the bug tracker and attaching >> implementations to it. The wiki page associated with the issue >> can be >> used to document the current solution and what would be a good >> generalized solution. > >> On 5/14/07, Torchinsky, Matias <ma...@ca...> wrote: >>> Well, >>> I'm interested to open a discussion and help to contribute for a >>> good >> design. >>> Meanwhile, will be helpfull if there is any implementation that >>> could be >> made public to start looking over it. >>> >>> How Should be proceed ? >>> regards >>> matt.- >>> >>> >>> >>> -----Original Message----- >>> From: man...@li... on behalf of >>> Martin Fuchs >>> Sent: Mon 5/14/2007 3:37 PM >>> To: developer discussions >>> Subject: Re: [mantisbt-dev] bug replication >>> >>> Hello, >>> >>>> I built a similar customization for a client recently. They had an >>>> external database copy that was the slave to a master internal >>>> database. Bugs updated in the external database were >>>> synchronized to >>>> the internal one. >>> >>>> I'm thinking about generalizing it if there is interest. >>> >>> This seems to be a very common setup: an external Mantis instance >>> with access for the cusomer and an internal Mantis installation for >>> developer access and internal bug tracking. >>> We are using this schema and I wrote a little utility to copy >>> entries >>> between the different Mantis instances (using a C++ web service on >>> a server and a Windows client for the user interface). >>> >>> Here we are also using a Tomcat servlet to display the entries of >>> the >>> two connected Mantis instances, compare the different states and >>> provide a meaniungful overview of the active entries. >>> >>> It's all not quite ready to be made public - but may be we could >>> share >>> some ideas to build a general solution? >>> >>> Regards, >>> >>> Martin >>> >>> -------------------------------------------------------------------- >>> ----- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> mantisbt-dev mailing list >>> man...@li... >>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >>> >>> >>> Visite http://www.cablevision.com.ar >>> Visite http://www.fibertel.com.ar >>> >>> >> _____________________________________________________________________ >> ______ >>> Este mensaje es confidencial. Puede contener informacion amparada >>> por el >> secreto comercial. >>> Si usted ha recibido este e-mail por error, debera eliminarlo de su >> sistema. >>> No debera copiar el mensaje ni divulgar su contenido a ninguna >>> persona. >> Muchas gracias. >>> >>> This message is confidential. It may also contain information >>> that is >> privileged or not >>> authorized to be disclosed. If you have received it by mistake, >>> delete >> it from your system. >>> You should not copy the messsage nor disclose its contents to >>> anyone. >> Many thanks. >>> >> _____________________________________________________________________ >> ______ >>> >>> >>> -------------------------------------------------------------------- >>> ----- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> mantisbt-dev mailing list >>> man...@li... >>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >>> >>> >>> > >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A |
From: Martin F. <mar...@gm...> - 2007-05-16 07:00:06
|
Hello Aristedes, yes it would be a good thing to use an interface capable to be used also for connecting other systems like e.g. Bugzilla. A web service using standard SOAP messages would be a way toachieve this goal. So I added your ideas to the Wiki page. Regards, Martin On 16.05.2007 09:35:01 Aristedes Maniatis wrote: > Perhaps this is beyond the scope of your 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. > Cheers > Ari Maniatis |
From: Gianluca S. <gi...@gm...> - 2007-05-16 07:25:25
|
On 5/16/07, Martin Fuchs <mar...@gm...> wrote: > yes it would be a good thing to use an interface capable to be used also for connecting other systems like e.g. Bugzilla. A web service using standard SOAP messages would be a way toachieve this goal. So I added your ideas to the Wiki page. Thanks for your work. I actually think we should "borrow" more ideas like this from bugzilla. I am not sure how exactly things works there, but bugzilla has both a XML-RPC interface and a simple(?) way to link bugs in different instances. IMHO, creating an interface compatible with that would be a really nice feature. |
From: Gianluca S. <gi...@gm...> - 2007-05-16 07:19:25
|
Please everyone avoid top-posting. On 5/16/07, Aristedes Maniatis <ar...@is...> wrote: > Perhaps this is beyond the scope of your immediate goals, but imagine > an interface which any bug tracker could implement and allowed > replication or query between any tool which implemented it. XML-RPC or something? This is actually what I was thinking about lately. I don't think we need to reinvent the wheel here, and some work on this side would allow a lot of other things. For example, if there was a RPC call for adding a version to a project, a "cvs tag" operation could be linked to that in few lines of code. (this is bug 6506 BTW...) |
From: Gianluca S. <gi...@gm...> - 2007-05-15 08:02:35
|
On 5/14/07, Martin Fuchs <mar...@gm...> wrote: > Hello, > > > I built a similar customization for a client recently. They had an > > external database copy that was the slave to a master internal > > database. Bugs updated in the external database were synchronized to > > the internal one. > > > I'm thinking about generalizing it if there is interest. > > This seems to be a very common setup: an external Mantis instance > with access for the cusomer and an internal Mantis installation for > developer access and internal bug tracking. This setup sounds like a workaround for some missing flexibility in the access/permissions handling logic. For example: http://bugs.mantisbt.org/view.php?bug_id=7862 would probably benefit from such a setup. That said, I think the outcome from this will be quite also useful for other features, so let's start hacking... |
From: Fetzik, J. <JF...@sa...> - 2007-05-16 13:33:02
|
=20 > > Hello, > > > > > I built a similar customization for a client recently. They had an=20 > > > external database copy that was the slave to a master internal=20 > > > database. Bugs updated in the external database were synchronized to=20 > > > the internal one. > > > > > I'm thinking about generalizing it if there is interest. > > > > This seems to be a very common setup: an external Mantis instance with=20 > > access for the cusomer and an internal Mantis installation for=20 > > developer access and internal bug tracking. >=20 > This setup sounds like a workaround for some missing flexibility in the access/permissions handling logic. I've been following this discussion and have one more situation where replication, in a generic manner would be useful. We use Mantis only internally, but we do have people in widely separate geographical locations that could use access to Mantis. The problem is the groups in Russia and China do not always have the best connectivity to us in the USA and when they do what gets transfer over such links needs to be prioritized. So it would be very useful for them to have a local copy of Mantis so they could add notes and updates, then synchronize with the primary Mantis installation when connectivity and/or bandwidth is available. John S. Fetzik S&C Electric Company jf...@sa... |
From: Roel V. <ro...@ri...> - 2007-05-15 08:47:40
|
Glenn Henshaw wrote: > I built a similar customization for a client recently. They had an > external database copy that was the slave to a master internal > database. Bugs updated in the external database were synchronized to > the internal one. > I'm thinking about generalizing it if there is interest. FWIW, we have a similar setup and it'd be great for us/me if this functionality could make it into the mantis core. I'd like the synchronization to be possible not only for single bugs but also for all bugs of a certain project. cheers, roel |
From: Torchinsky, M. <ma...@ca...> - 2007-05-15 14:26:37
|
Glenn Henshaw wrote: >> I built a similar customization for a client recently. They had an =20 >> external database copy that was the slave to a master internal =20 >> database. Bugs updated in the external database were synchronized to =20 >> the internal one. >> I'm thinking about generalizing it if there is interest. >FWIW, we have a similar setup and it'd be great for us/me if this=20 >functionality could make it into the mantis core. I'd like the=20 >synchronization to be possible not only for single bugs but also for all=20 >bugs of a certain project. Exactly. I guess it's time to write down those features to the wiki page ! Let's start hacking ! matt.- Visite http://www.cablevision.com.ar Visite http://www.fibertel.com.ar ___________________________________________________________________________ Este mensaje es confidencial. Puede contener informacion amparada por el se= creto comercial. Si usted ha recibido este e-mail por error, debera eliminarlo de su sistem= a. No debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muc= has gracias. This message is confidential. It may also contain information that is privi= leged or not authorized to be disclosed. If you have received it by mistake, delete it = from your system. You should not copy the messsage nor disclose its contents to anyone. Many = thanks. ___________________________________________________________________________ |
From: Martin F. <mar...@gm...> - 2007-05-15 21:01:43
|
Hello, > >FWIW, we have a similar setup and it'd be great for us/me if this > >functionality could make it into the mantis core. I'd like the > >synchronization to be possible not only for single bugs but also for all > >bugs of a certain project. > Exactly. I guess it's time to write down those features to the wiki page ! > Let's start hacking ! > matt.- OK - please go on. I already wrote down the requirements, which I think are necessary for a generalized Mantis synchronization: http://www.mantisbt.org/wiki/doku.php?id=mantisbt%3Aissue%3A7970 You can add your own requirements, comments and suggestions there. Regards, Martin |
From: Glenn H. <thr...@lo...> - 2007-05-16 01:51:42
|
On 15-May-07, at 4:01 AM, Gianluca Sforna wrote: > On 5/14/07, Martin Fuchs <mar...@gm...> wrote: >> Hello, >> >>> I built a similar customization for a client recently. They had an >>> external database copy that was the slave to a master internal >>> database. Bugs updated in the external database were synchronized to >>> the internal one. >> >>> I'm thinking about generalizing it if there is interest. >> >> This seems to be a very common setup: an external Mantis instance >> with access for the cusomer and an internal Mantis installation for >> developer access and internal bug tracking. > > This setup sounds like a workaround for some missing flexibility in > the access/permissions handling logic. > 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 Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User |
From: Gianluca S. <gi...@gm...> - 2007-05-16 07:07:20
|
On 5/16/07, Glenn Henshaw <thr...@lo...> wrote: > >> This seems to be a very common setup: an external Mantis instance > >> with access for the cusomer and an internal Mantis installation for > >> developer access and internal bug tracking. > > > > This setup sounds like a workaround for some missing flexibility in > > the access/permissions handling logic. > > > > 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, > That's fine. I'm just waiting to see how the details this is supposed to work will be ironed out. So far there were already different ideas that I could hardly see fullfilled by a single solution, but of course it is not necessary to cover every imaginable use case. |