mantisbt-soap-dev — MantisBT SOAP announcements DL

[Mantisbt-soap-dev] MantisBT plugins - bug tracker project request

[Robert M. <rob...@gm...>]

Hi,

I'd like to track bugs for some plugins which I'm working on


- Related issues export :
http://www.mantisbt.org/wiki/doku.php/mantisbt:relatedissuesexport
- Inline column configuration:
http://www.mantisbt.org/wiki/doku.php/mantisbt:inlinecolumnconfiguration
- Filter page edit:
http://www.mantisbt.org/wiki/doku.php/mantisbt:filterpageedit
- Linked custom fields:
http://www.mantisbt.org/wiki/doku.php/mantisbt:linkedcustomfields

Please add these as MantisBT projects.

Thanks,

Robert

-- 
Sent from my (old) computer

Re: [Mantisbt-soap-dev] using Mantis SOAP from Java without Axis1

[Robert M. <rob...@gm...>]

Hi Alexey,

1. I have used Axis in OSGi environments, Eclipse has such a bundle.
See https://github.com/Mylyn-Mantis/mylyn-mantis for a working
example.

2. Have you tried JAX-WS ? I know Jeremie Lagarde has done some work
in this direction, see https://github.com/jerr/mantis-ws-client

Robert

On Sun, Nov 20, 2011 at 5:18 AM, Alexey Skor <al...@gm...> wrote:
> I added my comment to the old question
> here: http://www.mantisbt.org/forums/viewtopic.php?f=2&t=19571
> Axis1 can't be used in OSGI
> (see http://stackoverflow.com/questions/4566580/strange-interaction-with-axis-osgi ),
> so I'm trying to use Axis2 to generate Java classes from Mantis WSDL, but it
> does not support rcp/encoded.
> Any solutions?
>
> --
> Alex
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Mantisbt-soap-dev mailing list
> Man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-soap-dev
>
>



-- 
Sent from my (old) computer

[Mantisbt-soap-dev] using Mantis SOAP from Java without Axis1

[Alexey S. <al...@gm...>]

I added my comment to the old question here:
http://www.mantisbt.org/forums/viewtopic.php?f=2&t=19571

Axis1 can't be used in OSGI (see
http://stackoverflow.com/questions/4566580/strange-interaction-with-axis-osgi
 ),
so I'm trying to use Axis2 to generate Java classes from Mantis WSDL, but
it does not support rcp/encoded.
Any solutions?

-- 
Alex

Re: [Mantisbt-soap-dev] [mantisbt-dev] RFC: Returning time information in GMT from the SOAP API

[Robert M. <rob...@gm...>]

Actually, you're right. Somehow MySQL nicely converted this for me
into the local timezone. So the data is stored internally as UTC , and
the conversion to the local time zone is (incorrectly) done at a
higher level, probably by NuSOAP. .

On Wed, Nov 9, 2011 at 3:04 PM, Paul Richards <pa...@ma...> wrote:
> Unless i'm going mad...
> 1300003755 is Sun Mar 13 08:09:15 2011 ?
> Bucharest is GMT/UTC+2hours [without DST] hence your 10am?
> Paul
>
> On Wed, Nov 9, 2011 at 12:50 PM, Robert Munteanu <rob...@gm...>
> wrote:
>>
>> On Tue, Nov 8, 2011 at 10:50 PM, Paul Richards <pa...@ma...>
>> wrote:
>> > David/Rob: your both slightly wrong here from what I recall of what I
>> > originally implemented, and what then happened in trunk [dhx:
>> > remember your
>> > fixes to redhat crapiness]
>> > I personally feel this is probably something we should ensure is fixed
>> > for
>> > the next major release of mantis as opposed trying to "bugfix" in now.
>> >
>> > To put another way, it would be nice to look at getting a 1.3/2.0/name
>> > 'alpha' out around December/January time - as the focus to this would
>> > seem
>> > to be a mixture of work to DB Api, Objects, Exceptions, Templating, New
>> > webservice api as 'ideas/work in progress', now is probably not a good
>> > time
>> > to do patches to adodb/mantis to change how we store timestamps.
>>
>> Here's my simple test:
>>
>> 1. On a bugtracker instance, running in Europe/Bucharest time mode, I
>> have the following data in the database
>>
>> mysql> select date_submitted, from_unixtime(date_submitted) from
>> mantis_bug_table where id = 4;
>> +----------------+-------------------------------+
>> | date_submitted | from_unixtime(date_submitted) |
>> +----------------+-------------------------------+
>> |     1300003755 | 2011-03-13 10:09:15           |
>> +----------------+-------------------------------+
>>
>>
>> 2. I have set my Mantis user's time zone to Europe/Bucharest
>>
>> 3. I have viewed the bug in the web interface
>>
>> The creation date shown is 2011-03-13 10:09
>>
>> Therefore the database will store the times in the local time zone,
>> and not in UTC . When the next major release is available, I will be
>> happy to update the SOAP API to be in line with the core APIs . Until
>> then, I will adjust the SOAP API to remove this offset and send times
>> in GMT.
>>
>> Thanks,
>>
>> Robert
>>
>> >
>> > Paul
>> > On Tue, Nov 8, 2011 at 1:15 PM, David Hicks <d...@hx...> wrote:
>> >>
>> >> On Tue, 2011-11-08 at 15:07 +0200, Robert Munteanu wrote:
>> >> > Are you sure that the time in the database is set in UTC? If that's
>> >> > true, I'm trying to solve a problem which does not exist.
>> >>
>> >> Perhaps not in every case. I only checked the function in bug_api that
>> >> is called to insert a new issue into the database - and I only checked
>> >> against the submission timestamp field.
>> >>
>> >> The SOAP API or other parts of MantisBT may feed in something other
>> >> than
>> >> db_now() or time() for timestamps. It might be worth grepping the
>> >> source
>> >> code for SQL statements that refer to timestamp columns and working
>> >> backwards to ensure that db_now() or time() is being used to provide
>> >> the
>> >> value.
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> RSA(R) Conference 2012
>> >> Save $700 by Nov 18
>> >> Register now
>> >> http://p.sf.net/sfu/rsa-sfdev2dev1
>> >> _______________________________________________
>> >> mantisbt-dev mailing list
>> >> man...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > RSA(R) Conference 2012
>> > Save $700 by Nov 18
>> > Register now
>> > http://p.sf.net/sfu/rsa-sfdev2dev1
>> > _______________________________________________
>> > mantisbt-dev mailing list
>> > man...@li...
>> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>> >
>> >
>>
>>
>>
>> --
>> Sent from my (old) computer
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> mantisbt-dev mailing list
>> man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>



-- 
Sent from my (old) computer

Re: [Mantisbt-soap-dev] [mantisbt-dev] RFC: Returning time information in GMT from the SOAP API

[Robert M. <rob...@gm...>]

On Tue, Nov 8, 2011 at 10:50 PM, Paul Richards <pa...@ma...> wrote:
> David/Rob: your both slightly wrong here from what I recall of what I
> originally implemented, and what then happened in trunk [dhx: remember your
> fixes to redhat crapiness]
> I personally feel this is probably something we should ensure is fixed for
> the next major release of mantis as opposed trying to "bugfix" in now.
>
> To put another way, it would be nice to look at getting a 1.3/2.0/name
> 'alpha' out around December/January time - as the focus to this would seem
> to be a mixture of work to DB Api, Objects, Exceptions, Templating, New
> webservice api as 'ideas/work in progress', now is probably not a good time
> to do patches to adodb/mantis to change how we store timestamps.

Here's my simple test:

1. On a bugtracker instance, running in Europe/Bucharest time mode, I
have the following data in the database

mysql> select date_submitted, from_unixtime(date_submitted) from
mantis_bug_table where id = 4;
+----------------+-------------------------------+
| date_submitted | from_unixtime(date_submitted) |
+----------------+-------------------------------+
|     1300003755 | 2011-03-13 10:09:15           |
+----------------+-------------------------------+


2. I have set my Mantis user's time zone to Europe/Bucharest

3. I have viewed the bug in the web interface

The creation date shown is 2011-03-13 10:09

Therefore the database will store the times in the local time zone,
and not in UTC . When the next major release is available, I will be
happy to update the SOAP API to be in line with the core APIs . Until
then, I will adjust the SOAP API to remove this offset and send times
in GMT.

Thanks,

Robert

>
> Paul
> On Tue, Nov 8, 2011 at 1:15 PM, David Hicks <d...@hx...> wrote:
>>
>> On Tue, 2011-11-08 at 15:07 +0200, Robert Munteanu wrote:
>> > Are you sure that the time in the database is set in UTC? If that's
>> > true, I'm trying to solve a problem which does not exist.
>>
>> Perhaps not in every case. I only checked the function in bug_api that
>> is called to insert a new issue into the database - and I only checked
>> against the submission timestamp field.
>>
>> The SOAP API or other parts of MantisBT may feed in something other than
>> db_now() or time() for timestamps. It might be worth grepping the source
>> code for SQL statements that refer to timestamp columns and working
>> backwards to ensure that db_now() or time() is being used to provide the
>> value.
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> mantisbt-dev mailing list
>> man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>



-- 
Sent from my (old) computer

Re: [Mantisbt-soap-dev] RFC: Returning time information in GMT from the SOAP API

[Robert M. <rob...@gm...>]

Damien, Victor,

Thanks for your comments.

I will go through with 3b as outlined by Victor below , see

13496: Send all dates in the GMT timezone
http://www.mantisbt.org/bugs/view.php?id=13496

I have added a comment to

13445: mc_user_get() to get user data
http://www.mantisbt.org/bugs/view.php?id=13445

regarding the timezone information so that we implement it when we
implement mc_user_get .

I believe that 1 be done independently of this change, possibly as a
cleanup effort. And I was under the impression that we already had
per-user timezone information in 1.2.x .

Thanks,

Robert

On Tue, Nov 8, 2011 at 8:39 AM, Victor Boctor <vb...@gm...> wrote:
>
> On Mon, Nov 7, 2011 at 4:47 AM, Damien Regad <dam...@me...>
> wrote:
>>
>> On 07/11/11 11:46, Robert Munteanu wrote:
>> > I prefer sending dates as GMT, as this is the least ambiguous and
>> > sidesteps around thorny issues such as DST with dates jumping back and
>> > forth.
>>
>>  From my experience, it's always best to stick with UTC for dates, this
>> way as you rightly pointed out, it's never ambiguous. Any timezone
>> conversions happen on the client/user side as appropriate.
>>
>> Just my 2 cents.
>> Damien
>>
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Mantisbt-soap-dev mailing list
>> Man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-soap-dev
>
>



-- 
Sent from my (old) computer

Re: [Mantisbt-soap-dev] RFC: Returning time information in GMT from the SOAP API

[Victor B. <vb...@gm...>]

I would suggest the following:

1. Change MantisBT to use UTC internally and provide a migration step to
migrate existing data.
2. Add support for per user timezone.  All timestamps are to be displayed
in the user's time zone.
3. SOAP API can return timezones in...
a. UTC, but also provide an API to get the user's timezone as part of the
user info.
b. user's time zone of the logged in user.

We can potentially do 3 before 1 and 2.  The easiest approach for the
clients is 3b since it provides the appropriate behavior by default, but
also makes it possible to use a user with timezone UTC.

On Mon, Nov 7, 2011 at 4:47 AM, Damien Regad <dam...@me...>wrote:

>
> On 07/11/11 11:46, Robert Munteanu wrote:
> > I prefer sending dates as GMT, as this is the least ambiguous and
> > sidesteps around thorny issues such as DST with dates jumping back and
> > forth.
>
>  From my experience, it's always best to stick with UTC for dates, this
> way as you rightly pointed out, it's never ambiguous. Any timezone
> conversions happen on the client/user side as appropriate.
>
> Just my 2 cents.
> Damien
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Mantisbt-soap-dev mailing list
> Man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-soap-dev
>

Re: [Mantisbt-soap-dev] RFC: Returning time information in GMT from the SOAP API

[Damien R. <dam...@me...>]

On 07/11/11 11:46, Robert Munteanu wrote:
> I prefer sending dates as GMT, as this is the least ambiguous and
> sidesteps around thorny issues such as DST with dates jumping back and
> forth.

 From my experience, it's always best to stick with UTC for dates, this 
way as you rightly pointed out, it's never ambiguous. Any timezone 
conversions happen on the client/user side as appropriate.

Just my 2 cents.
Damien

[Mantisbt-soap-dev] RFC: Returning time information in GMT from the SOAP API

[Robert M. <rob...@gm...>]

Hi,

Currently the SOAP API returns dates ( creation, last modification,
comment dates ) in the repository's local time zone, e.g.

<last_updated xsi:type="xsd:dateTime">2011-09-23T07:29:18Z</last_updated>

This is inconvenient because the client needs to know beforehand the
timezone of the Mantis installation, which is not available using the
SOAP API.

There are multiple possibilities here:

- add a new SOAP API call which would return the timezone of the
Mantis repository
- send all dates as GMT

I prefer sending dates as GMT, as this is the least ambiguous and
sidesteps around thorny issues such as DST with dates jumping back and
forth.

But before implementing I'd like to hear others' opinions, if any.

Thanks,

Robert
-- 
Sent from my (old) computer

Re: [Mantisbt-soap-dev] Iterating through all issues

[Robert M. <rob...@gm...>]

On Sun, May 22, 2011 at 11:48 AM, Dirk Haun <68...@gm...> wrote:
> I want to iterate through all the issues in our Mantis instance, using
> the SOAP API. I'm calling mc_project_get_issues, and after lowering
> the number of issues per page (with 50 per page it would always throw
> an exception on page 4, for some reason), I now get all the issues I
> want.

Can you report that exception on mantisbt.org/bugs/ ?

>
> My only problem now: How do I detect the end? It seems that increasing
> the page number will only return the same result for the last page
> over and over again.

This bug will be fixed in the upcoming 1.2.6 release.

12991: mc_filter_get_issues returns incorrect results for page_number
> page_count
http://www.mantisbt.org/bugs/view.php?id=12991

If you need to find out the last page, I suggest you perform a check
on your side. The safest should be remembering the bug id you received
on index 0. If you get the same bug in two consecutive calls, you've
reached the end. Not ideal, but will be fixed in the next release.

>
> I could check if I've seen these issues before but surely there must
> be an easier way? Can I get the total number of issues for a project,
> for example?

There's a feature request for that

8656: please provide function that return issue count of current filter
http://www.mantisbt.org/bugs/view.php?id=8656

But no one has stepped up to implement it yet.

>
> Code snippet:
>
> for ($p = 1; $p <= 1000; $p++) {
>    $issues = $m->mc_project_get_issues($user, $pwd, $project_id, $p, 25);
>    if (! is_array($issues)) {
>        break;
>    }
>    // display issues here
> }
>
> ... and it just goes on and on.
>
> P.S. I didn't know this list existed. It's not listed on
> http://www.mantisbt.org/mailinglists.php but only when you follow the
> link to the SourceForge Mailing lists.

Good point. I'll have this added to that page.

Robert
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Mantisbt-soap-dev mailing list
> Man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-soap-dev
>



-- 
Sent from my (old) computer

[Mantisbt-soap-dev] Iterating through all issues

[Dirk H. <68...@gm...>]

I want to iterate through all the issues in our Mantis instance, using
the SOAP API. I'm calling mc_project_get_issues, and after lowering
the number of issues per page (with 50 per page it would always throw
an exception on page 4, for some reason), I now get all the issues I
want.

My only problem now: How do I detect the end? It seems that increasing
the page number will only return the same result for the last page
over and over again.

I could check if I've seen these issues before but surely there must
be an easier way? Can I get the total number of issues for a project,
for example?

Code snippet:

for ($p = 1; $p <= 1000; $p++) {
    $issues = $m->mc_project_get_issues($user, $pwd, $project_id, $p, 25);
    if (! is_array($issues)) {
        break;
    }
    // display issues here
}

... and it just goes on and on.

P.S. I didn't know this list existed. It's not listed on
http://www.mantisbt.org/mailinglists.php but only when you follow the
link to the SourceForge Mailing lists.

[Mantisbt-soap-dev] Java SOAP stubs

[Robert M. <rob...@gm...>]

Hi,

Jérémie Lagarde and myself have been working on generating and
deploying SOAP Stubs for MantisBT on Maven central. For now we have
deployed the ones generated for Axis 1. You can use it by adding the
following dependency in your pom.xml :

<dependency>
  <groupId>biz.futureware.mantis</groupId>
  <artifactId>mantis-axis-soap-client</artifactId>
  <version>1.2.5</version>
</dependency>

More inclusion snippets are available at
http://search.maven.org/#artifactdetails|biz.futureware.mantis|mantis-axis-soap-client|1.2.5|jar

This is an early version, so all feedback and testing is welcome.

Regards,

Robert

-- 
Sent from my (old) computer

[Mantisbt-soap-dev] MantisBT SOAP API changes for 1.2.6

[Robert M. <rob...@gm...>]

Hi,

All planned SOAP changes for 1.2.6 have been committed. You should be
able to regenerate your SOAP stubs ( if needed ) from a MantisBT
installation started from git branch master -1.2 .

The complete list of SOAP changes can be found at

http://www.mantisbt.org/bugs/search.php?project_id=1&category=api%20soap&resolution_id=20&sticky_issues=1&target_version=1.2.x&sortby=last_updated&dir=DESC&hide_status_id=-2

Regards,

Robert

-- 
Sent from my (old) computer