mantisbt-dev — MantisBT development discussions

Re: [mantisbt-dev] Issue on committing changes to a fork (mantisbt-plugins)

[Louis B. <lba...@gm...>]

Hi,
You may also consider using the following plugin:

http://codevtt.org

Best regards,
Louis

Louis BAYLE
Tel: +33 (0)4.42.604.734
lba...@gm...

On Tue, Dec 30, 2014 at 5:33 AM, Manilal K M <ma...@ej...> wrote:

> Damien,
>
> Thanks for the detailed explanation. I thought of having a symbolic link,
> but then I was not very sure whether it will work with Mantis. I will get
> back to you if I have any more questions.
>
> regards
> Manilal
>
> ----- Original Message -----
> > From: "Damien Regad" <dr...@ma...>
> > To: "mantis-dev" <Man...@li...>
> > Sent: Tuesday, December 30, 2014 4:29:19 AM
> > Subject: Re: [mantisbt-dev] Issue on committing changes to a fork
>  (mantisbt-plugins)
>
> > Hi Manilal,
> >
> > On 2014-12-29 16:04, Manilal K M wrote:
> >> I cloned the repository and the source files got downloaded to
> > > timetracking folder within mantisbt/plugins.
> >> Then I moved everything (including .git) folder to the TimeTracking
> > > folder within the timetracking folder.
> >
> > What you did is is basically moving the contents of the TimeTracking
> > directory to the repository's root and removing the directory. In other
> > words, you changed the repo's structure
> >
> > Before:
> > ./timetracking/.git
> > ./timetracking/README
> > ./timetracking/TimeTracking/
> > ./timetracking/TimeTracking/core
> > ./timetracking/TimeTracking/pages
> > ./timetracking/TimeTracking/lang
> >
> > After:
> > ./timetracking/.git
> > ./timetracking/README
> > ./timetracking/core
> > ./timetracking/pages
> > ./timetracking/lang
> >
> >> I have worked with EmailReporting plugin earlier, but didn't have such
> issues.
> >
> > The EmailReporting plugin has all its files at the repository's root,
> > whereas the timetracking stores it in the TimeTracking subdir.
> >
> >> Could someone help me to figure out this?
> >
> > Hope the above explanation was enough...
> >
> > I suggest you checkout the repository outside of Mantis' plugin
> > directory, and create a symbolic link to TimeTracking subdir, e.g.
> >
> > $ cd /path/to/mantis/plugins
> > $ ln -s /path/to/timetracking/TimeTracking
> >
> >> Can I ignore the above messages submit the pull request?
> >
> > No you cant ;-)
> >
> > D
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming! The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take
> a
> > look and join the conversation now. http://goparallel.sourceforge.net
> > _______________________________________________
> > mantisbt-dev mailing list
> > man...@li...
> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

Re: [mantisbt-dev] Frameworks

[Elier D. <eli...@gm...>]

Hello Thomas, thanks for sharing.

I have made public what I did so anyone can contribute.
What you did can be very useful.

https://github.com/elier/mantis5

Thanks, Elier


On Sun, Dec 28, 2014 at 3:11 AM, Thomas Koch <th...@ko...> wrote:

> On Saturday, December 20, 2014 01:56:17 PM Elier Delgado wrote:
> > I did some tests with symfony2 and I was able to generate several CRUD
> > in a
> > few hours
>
> We've ported a legacy PHP non-MVC application to Symfony last year step by
>
> step without downtime. Our strategy was:
>
> a) Move all files in the standard Symfony folders app/,src/, web/
> b) autogenerate Symfony Routes for all PHP files that were formerly
> entered
> directly:
>
>         $collection = new RouteCollection();
>
>         $finder = (new Finder())->in($this->dir)->files()->name('*.php');
>         foreach($finder as $phpFile) {
>             $collection->add(
>                 $this->buildNameFor($phpFile),
>                 $this->buildRouteFor($phpFile)
>             );
>         }
>         return $collection;
>
> c) Add a default controller for all legacy PHP files:
>
> class LegacyRoutesController extends Controller {
>
>     private static $redirect = null;
>
>     public function defaultAction($_route, $_legacyPath)
>    {
>         ob_start();
>         $ret = require $_legacyPath;
>         $out = ob_get_contents();
>         ob_end_clean();
>
>         if($ret instanceof Response) return $ret;
>
>         if(self::$redirect) return $this->redirect(self::$redirect);
>
>         return new Response($out);
>     }
>
> d) The old PHP files now have access to $this and thus can use Symfony
> services like template engine (twig), form handlers, request, response
> objects, database (doctrine), email (swiftmailer)
>
> e) Replace old PHP files with MVC controllers step by step
>
> ...
>
> z) (Port to Java Spring...)
>

Re: [mantisbt-dev] Issue on committing changes to a fork (mantisbt-plugins)

[Manilal K M <ma...@ej...>]

Damien,

Thanks for the detailed explanation. I thought of having a symbolic link, but then I was not very sure whether it will work with Mantis. I will get back to you if I have any more questions.

regards
Manilal

----- Original Message -----
> From: "Damien Regad" <dr...@ma...>
> To: "mantis-dev" <Man...@li...>
> Sent: Tuesday, December 30, 2014 4:29:19 AM
> Subject: Re: [mantisbt-dev] Issue on committing changes to a fork	(mantisbt-plugins)

> Hi Manilal,
> 
> On 2014-12-29 16:04, Manilal K M wrote:
>> I cloned the repository and the source files got downloaded to
> > timetracking folder within mantisbt/plugins.
>> Then I moved everything (including .git) folder to the TimeTracking
> > folder within the timetracking folder.
> 
> What you did is is basically moving the contents of the TimeTracking
> directory to the repository's root and removing the directory. In other
> words, you changed the repo's structure
> 
> Before:
> ./timetracking/.git
> ./timetracking/README
> ./timetracking/TimeTracking/
> ./timetracking/TimeTracking/core
> ./timetracking/TimeTracking/pages
> ./timetracking/TimeTracking/lang
> 
> After:
> ./timetracking/.git
> ./timetracking/README
> ./timetracking/core
> ./timetracking/pages
> ./timetracking/lang
> 
>> I have worked with EmailReporting plugin earlier, but didn't have such issues.
> 
> The EmailReporting plugin has all its files at the repository's root,
> whereas the timetracking stores it in the TimeTracking subdir.
> 
>> Could someone help me to figure out this?
> 
> Hope the above explanation was enough...
> 
> I suggest you checkout the repository outside of Mantis' plugin
> directory, and create a symbolic link to TimeTracking subdir, e.g.
> 
> $ cd /path/to/mantis/plugins
> $ ln -s /path/to/timetracking/TimeTracking
> 
>> Can I ignore the above messages submit the pull request?
> 
> No you cant ;-)
> 
> D
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Issue on committing changes to a fork (mantisbt-plugins)

[Damien R. <dr...@ma...>]

Hi Manilal,

On 2014-12-29 16:04, Manilal K M wrote:
> I cloned the repository and the source files got downloaded to
 > timetracking folder within mantisbt/plugins.
> Then I moved everything (including .git) folder to the TimeTracking
 > folder within the timetracking folder.

What you did is is basically moving the contents of the TimeTracking 
directory to the repository's root and removing the directory. In other 
words, you changed the repo's structure

Before:
./timetracking/.git
./timetracking/README
./timetracking/TimeTracking/
./timetracking/TimeTracking/core
./timetracking/TimeTracking/pages
./timetracking/TimeTracking/lang

After:
./timetracking/.git
./timetracking/README
./timetracking/core
./timetracking/pages
./timetracking/lang

> I have worked with EmailReporting plugin earlier, but didn't have such issues.

The EmailReporting plugin has all its files at the repository's root, 
whereas the timetracking stores it in the TimeTracking subdir.

> Could someone help me to figure out this?

Hope the above explanation was enough...

I suggest you checkout the repository outside of Mantis' plugin 
directory, and create a symbolic link to TimeTracking subdir, e.g.

$ cd /path/to/mantis/plugins
$ ln -s /path/to/timetracking/TimeTracking

> Can I ignore the above messages submit the pull request?

No you cant ;-)

D

Re: [mantisbt-dev] Frameworks

[Damien R. <dr...@ma...>]

Although it's not exactly what you're referring to, I just thought I'd 
mention that we do have plans to revamp the Mantis UI using bootstrap, 
see https://github.com/mantisbt/mantisbt/pull/272

[mantisbt-dev] Issue on committing changes to a fork (mantisbt-plugins)

[Manilal K M <ma...@ej...>]

Hello,

This is slightly offtopic, but since it's related to mantisbt-plugins I thought someone may have a quick solution for the following issue.

I tried to fork the timetracking plugin in mantisbt-plugins and had some issues in setting up the development environment. I cloned the repository and the source files got downloaded to timetracking folder within mantisbt/plugins. Then I moved everything (including .git) folder to the TimeTracking folder within the timetracking folder. I modified some of the files and committed the changes, but I got the following suspicious output:

[root@es032 TimeTracking]# git commit -a
[master 3b0abfe] Included jscalendar datepicker widget to input date Added new table to store factors and reference field in the data table
 14 files changed, 1092 deletions(-)
 delete mode 100644 README
 delete mode 100644 TimeTracking/LICENSE-2.0.txt
 delete mode 100644 TimeTracking/TimeTracking.php
 delete mode 100644 TimeTracking/core/timetracking_api.php
 delete mode 100644 TimeTracking/lang/strings_catalan.txt
 delete mode 100755 TimeTracking/lang/strings_english.txt
 delete mode 100755 TimeTracking/lang/strings_french.txt
 delete mode 100755 TimeTracking/lang/strings_german.txt
 delete mode 100644 TimeTracking/lang/strings_spanish.txt
 delete mode 100644 TimeTracking/pages/add_record.php
 delete mode 100644 TimeTracking/pages/config_page.php
 delete mode 100644 TimeTracking/pages/config_update.php
 delete mode 100644 TimeTracking/pages/delete_record.php
 delete mode 100644 TimeTracking/pages/show_report.php

I have worked with EmailReporting plugin earlier, but didn't have such issues. 

Could someone help me to figure out this? Can I ignore the above messages submit the pull request?

I would like to submit couple of feature enhancements to the TimeTracking plugin.

regards
Manilal

Re: [mantisbt-dev] Frameworks

[Thomas K. <th...@ko...>]

On Saturday, December 20, 2014 01:56:17 PM Elier Delgado wrote:
> I did some tests with symfony2 and I was able to generate several CRUD
> in a
> few hours

We've ported a legacy PHP non-MVC application to Symfony last year step by

step without downtime. Our strategy was:

a) Move all files in the standard Symfony folders app/,src/, web/
b) autogenerate Symfony Routes for all PHP files that were formerly
entered 
directly:

        $collection = new RouteCollection();

        $finder = (new Finder())->in($this->dir)->files()->name('*.php');
        foreach($finder as $phpFile) {
            $collection->add(
                $this->buildNameFor($phpFile),
                $this->buildRouteFor($phpFile)
            );
        }
        return $collection;

c) Add a default controller for all legacy PHP files:

class LegacyRoutesController extends Controller {

    private static $redirect = null;

    public function defaultAction($_route, $_legacyPath)
   {
        ob_start();
        $ret = require $_legacyPath;
        $out = ob_get_contents();
        ob_end_clean();

        if($ret instanceof Response) return $ret;

        if(self::$redirect) return $this->redirect(self::$redirect);

        return new Response($out);
    }

d) The old PHP files now have access to $this and thus can use Symfony 
services like template engine (twig), form handlers, request, response
objects, database (doctrine), email (swiftmailer)

e) Replace old PHP files with MVC controllers step by step

...

z) (Port to Java Spring...)

Re: [mantisbt-dev] Frameworks

[Elier D. <eli...@gm...>]

> Re: [mantisbt-dev] Frameworks
> From: Damien Regad <dregad@ma...> - 2014-12-14 21:25:13
>  On 2014-12-13 04:15, Elier Delgado wrote:
> > I recently had to go through the code debugging an issue and I was
> > wondering if you ever have think on porting progressively Mantis into
> > any framework?
>
> Not that I know of.
>
> D

Thanks Damien,

I did some tests with symfony2 and I was able to generate several CRUD in a
few hours. I used a very nice bootstrap theme, so the UI is different but
great, mobile friendly etc.
Here what I have working so far:
- User CRUD, login, logout
- Project CRUD
- Tag CRUD
- Custom fields CRUD

I think it is an interesting result that can help to revamp the system with
an affordable effort.
It could create the base to make more easy and standard to developers add
new features.

With a good and popular framework, Mantis could become the open source
equivalent to JIRA.

What the community think?

Regards, Elier


On Fri, Dec 12, 2014 at 10:15 PM, Elier Delgado <eli...@gm...>
wrote:
>
> Hello all,
>
> First at all, I want to thank you for your great contribution. You can
> feel good because many people are thankful for having Mantis.
> I was happy to introduced it in several places :)
>
> I recently had to go through the code debugging an issue and I was
> wondering if you ever have think on porting progressively Mantis into any
> framework?
>
> Regards, Elier
>

Re: [mantisbt-dev] Frameworks

[Damien R. <dr...@ma...>]

On 2014-12-13 04:15, Elier Delgado wrote:
> I recently had to go through the code debugging an issue and I was
> wondering if you ever have think on porting progressively Mantis into
> any framework?

Not that I know of.

D

[mantisbt-dev] Frameworks

[Elier D. <eli...@gm...>]

Hello all,

First at all, I want to thank you for your great contribution. You can feel
good because many people are thankful for having Mantis.
I was happy to introduced it in several places :)

I recently had to go through the code debugging an issue and I was
wondering if you ever have think on porting progressively Mantis into any
framework?

Regards, Elier

Re: [mantisbt-dev] [New Plugin] FilterBugList

[Damien R. <dr...@ma...>]

On 2014-12-07 16:01, Alain D'EURVEILHER wrote:
> Thank you Damien,
> Everything is in order now.

Great. And thank you for the plugin.
D

Re: [mantisbt-dev] [New Plugin] FilterBugList

[Alain D'E. <ala...@gm...>]

Thank you Damien,
Everything is in order now.
Regards,

AlainD.

On Sun, Dec 7, 2014 at 3:22 PM, Damien Regad <dr...@ma...> wrote:

> On 2014-12-05 16:48, Alain D'EURVEILHER wrote:
> > Can you please:
> > 1) Review
>
> Not done, don't have time to do it atm.
>
> > 2) if OK, add me the rights to create the wiki page (for the user 'Bozz'
> > of the bugtracker)
>
> Page created
>
> > 3) allow me to transfer the ownership on github to your organization.
>
> Created a group for the plugin, try to transfer now.
>
> D
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>



-- 

AlainD.

Re: [mantisbt-dev] [New Plugin] FilterBugList

[Damien R. <dr...@ma...>]

On 2014-12-05 16:48, Alain D'EURVEILHER wrote:
> Can you please:
> 1) Review

Not done, don't have time to do it atm.

> 2) if OK, add me the rights to create the wiki page (for the user 'Bozz'
> of the bugtracker)

Page created

> 3) allow me to transfer the ownership on github to your organization.

Created a group for the plugin, try to transfer now.

D

[mantisbt-dev] MantisBT 1.2.18 Released

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

MantisBT 1.2.18 is an important security update for the stable 1.2.x branch.
 <>All installations that are currently running any 1.2.x version are strongly
 <>advised to upgrade to this release. Download it from [2].
 <>
 <>This release resolves a total of 43 issues, including fixes for 23 security-
 <>related bugs and vulnerabilities:
 <>
 <>- 7 Cross-Site Scripting (XSS) issues: #17297/CVE-2014-9272,
 <>  #17583/CVE-2014-9270, #17870/CVE-2014-8987, #17874/CVE-2014-9271,
 <>  #17876/CVE-2014-9281, #17889/CVE-2014-8986, #17890/CVE-2014-9269
 <>
 <>- 2 Code injection issues: #17725/CVE-2014-7146, #17875/CVE-2014-9280
 <>
 <>- 2 SQL injection (XSS) issues: #17812/CVE-2014-8554, #17841/CVE-2014-9089
 <>
 <>- 5 Information disclosure issues: #9885, #17744, #17877/CVE-2014-9279,
 <>  #17742/CVE-2014-8988, #17243/CVE-2014-8553
 <>
 <>- 7 Other security issues: #10966, #17338, #17640/CVE-2014-6387,
 <>  #17648/CVE-2014-6316, #17780/CVE-2014-8598, #17811/CVE-2014-9117, #17878
 <>
 <>Please refer to the changelog [1] on the MantisBT web site for complete details
 <>on each of these issues.
 <>
 <>We would like to thank the following individuals and organizations for their
 <>valued contribution in discovering and fixing these issues, in no particular
 <>order: Mati Aharoni from Offensive Security and their bug bounty program,
 <>Matthias Karlsson, Matthew Daley, Egidio Romano, Florian Fuchs, Shahee Mirza,
 <>Oleg K, Alejo Popovici, Edwin Gozeling, Paul Richards, Roland Becker,
 <>Victor Boctor and Damien Regad.

[1] http://www.mantisbt.org/bugs/changelog_page.php?version_id=191
[2] http://sourceforge.net/projects/mantisbt/files/mantis-stable/

Thanks,
MantisBT Team

[mantisbt-dev] [New Plugin] FilterBugList

[Alain D'E. <ala...@gm...>]

Hi,
I would like a new plugin to be hosted, but I'm facing some difficulties
with writting the page on the wiki and transfering the ownership on github.

The plugin is currently hosted there on github:
https://github.com/AlainD-/FilterBugList
(FYI the plugin allow to filter by giving a list of bug ids)

Can you please:
1) Review
2) if OK, add me the rights to create the wiki page (for the user 'Bozz' of
the bugtracker)
3) allow me to transfer the ownership on github to your organization.

Thank you very much in advance.

-- 

AlainD.

Re: [mantisbt-dev] Is there an API Doc on custom filters ?

[Alain D'E. <ala...@gm...>]

I have created a plugin for that matter, I have difficulties posting it in
my github from my office (probably policy restrictions). I'll try again
later at home.

Regards,
AlainD.

On Fri, Dec 5, 2014 at 10:44 AM, Alain D'EURVEILHER <
ala...@gm...> wrote:

> I don't know if there is an API for that but you can create a plugin to
> add a custom filter field using the event ''EVENT_FILTER_FIELDS'', which
> will be available in the filter createria selection.
>
> Then after that maybe you call 'view_all_set.php?' with your custom filter
> (I did not try, it is just supposition based on the way the [ view issues ]
> link is implemented in the Roadmap page.
>
> On Fri, Dec 5, 2014 at 10:08 AM, Louis BAYLE <lba...@gm...>
> wrote:
>
>> Hi,
>> I would like to open the view_all_bug_page.php with a set of issues that
>> are not defined by any of the current Mantis fields. Basicaly, I need to
>> specify a list of bug_id.
>>
>> Is it possible ? Is there a doc that describes how to do that ?
>>
>> I was thinking of building an URL like this
>> mantis/view_all_bug_page.php?bug_id=12,54,65,567,534
>>
>> If it does not exist, would you be interested in a PR with such a feature
>> ? have you any hints on how to do it ?
>>
>> Thank you,
>> Best regards,
>>
>> Louis BAYLE
>>
>> <lba...@gm...>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> mantisbt-dev mailing list
>> man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>>
>>
>
>
> --
>
> AlainD.
>



-- 

AlainD.

Re: [mantisbt-dev] Is there an API Doc on custom filters ?

[Alain D'E. <ala...@gm...>]

I don't know if there is an API for that but you can create a plugin to add
a custom filter field using the event ''EVENT_FILTER_FIELDS'', which will
be available in the filter createria selection.

Then after that maybe you call 'view_all_set.php?' with your custom filter
(I did not try, it is just supposition based on the way the [ view issues ]
link is implemented in the Roadmap page.

On Fri, Dec 5, 2014 at 10:08 AM, Louis BAYLE <lba...@gm...> wrote:

> Hi,
> I would like to open the view_all_bug_page.php with a set of issues that
> are not defined by any of the current Mantis fields. Basicaly, I need to
> specify a list of bug_id.
>
> Is it possible ? Is there a doc that describes how to do that ?
>
> I was thinking of building an URL like this
> mantis/view_all_bug_page.php?bug_id=12,54,65,567,534
>
> If it does not exist, would you be interested in a PR with such a feature
> ? have you any hints on how to do it ?
>
> Thank you,
> Best regards,
>
> Louis BAYLE
>
> <lba...@gm...>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>


-- 

AlainD.

[mantisbt-dev] Is there an API Doc on custom filters ?

[Louis B. <lba...@gm...>]

Hi,
I would like to open the view_all_bug_page.php with a set of issues that
are not defined by any of the current Mantis fields. Basicaly, I need to
specify a list of bug_id.

Is it possible ? Is there a doc that describes how to do that ?

I was thinking of building an URL like this
mantis/view_all_bug_page.php?bug_id=12,54,65,567,534

If it does not exist, would you be interested in a PR with such a feature ?
have you any hints on how to do it ?

Thank you,
Best regards,

Louis BAYLE

<lba...@gm...>

Re: [mantisbt-dev] 1.2.18

[Damien R. <dr...@ma...>]

Gianluca Sforna <giallu@...> writes:

> what are there plans for the 1.2.18 release?

Almost there. Hopefully this weekend or sometime next week if all goes
according to plan.

[mantisbt-dev] 1.2.18

[Gianluca S. <gi...@gm...>]

Hi all
what are there plans for the 1.2.18 release?

I am receiving many security issues reports for the RPM package in
Fedora/EPEL repos and it would be great if I could just rebase the
package from the upstream tarball instead of chasing the correct patch
set to apply.

Thanks

G.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://plus.google.com/+gianlucasforna - http://twitter.com/giallu

[mantisbt-dev] Preparing blog post for 1.3.0-beta.1

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

Hi all,

I’ve put together some thoughts relating to the points we want to communicate in the post.  I would appreciate if you can provide your thoughts about the same. I’ve created a gist to make discussing and evolving this easier.

https://gist.github.com/vboctor/07679f52733c149c5a94 <https://gist.github.com/vboctor/07679f52733c149c5a94>

Thanks,
-Victor

[mantisbt-dev] FW: Hi All - A change of direction for me.

[P R. <pa...@ma...>]

Robert, Damien, 

Before I send anything to the list regarding fork (which may be over weekend),  I'm sending you two privately the some of the security patches that I have for 1.2.18

001: I deem to be minor - it's a 'safety' catch for if someone accidently configures a server incorrectly - in reality, unlikely to ever be an issue as mantis isn't userable in the state needed to trigger this.

002 - not a security fix as a such, but seemed to fix javascript errors that were making it hard to identify 3

003 - Fixes XSS issue in the extended browser - this only needs to be back ported to 1.2 as the code has gone from master

004 - Fixes a SQL injection issue in the SOAP api - I've emailed cve...@mi... asking  for them to reserve a CVE for this (And also emailed them asking them to reserve a CVE for the other issues we've got patches in progress for. I've not yet emailed cve-assign for the 01 or 03 above. I'm wondering for both whether it's necessarily to bother - in the first case (001), I don’t think you'd even be able to use mantis properly in the state needed to hit this issue, and in the 2nd case (003) , given you'd need the extended project browser to be on, and be able to set a project name - the first of which I've never seen anyone use...

Once I get a reply with CVE number, I'll forward it to you two again so a complete set of patches can be properly co-ordinated, and we can make sure nothing is missing. And then I'll reply publically to your list-mail rombert about names (don't worry, I've not picked something that will breed confusion), and further details.

Paul


-----Original Message-----
From: Robert Munteanu [mailto:rob...@gm...] 
Sent: 21 October 2014 12:06
To: developer discussions
Subject: Re: [mantisbt-dev] Hi All - A change of direction for me.

Hi Paul,

Let me start by acknowledging all the work you did on MantisBT - you definitely contributed a lot and MantisBT is today better due to your contributions, so a big thank you goes out for that.

I wish you good luck with your fork - and hope you don't mind if we cherry-pick fixes that we find useful :-)

On a related note, I echo Damien's comment on naming - it would breed confusion to name your project Mantis Issue Tracker ( MantisIT? ) so please pick another name that

Cheers,

Robert

On Tue, Oct 21, 2014 at 12:24 AM, P Richards <pa...@ma...> wrote:
> Hi All,
>
>
>
> Just to let you know that I’m going to embark on a new project – 
> “Mantis Issue Tracker”. This will be a fork from the Mantis Bug 
> Tracker project with a goal for being used for a helpdesk focus – this 
> is the environment I currently work in.
>
>
>
> After 10 years spent working on Mantis Bug Tracker, it has become 
> clear that Victor’s planned direction with moving towards a hosted 
> MantisHub and trying to make a financial return out of Mantis is not 
> aligned with the goal’s that I set myself for involvement with an open 
> source project. I’d like to wish him success with those aims.
>
>
>
> Myself, I’m keen to ensure that in todays hosted world with cloud 
> services etc, that it’s possible to run a freely available issue tracker for all.
>
>
>
> I’ll post more details in a few days.
>
>
>
> I still plan to continue to follow the project and submit any pull 
> requests, but I need to align my coding time with the needs for which 
> I use Mantis – which is as an issue checker in a MSSQL shop.
>
>
>
> In the meantime, please let me know as soon as damien has fixed his 
> email address, as it’s still broken and it would be good to do a joint 
> security release.
>
>
>
> Paul
>
>
> ----------------------------------------------------------------------
> -------- Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>



--
http://robert.muntea.nu/

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
mantisbt-dev mailing list
man...@li...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Simplify Target Version/Fixed in Version management for 1.3

[Roland B. <ro...@at...>]

> I realise that we possibly have one edge case here - users who desire
> to have target_version set but fix_in_version empty. However, I hope
> that's not really happening in practice.

This is exactly what's the plan for 1.3.x after the first release is out:
Set fixed_in_version empty where version is 1.3.0dev to exclude the regressions
from changelog.

> I would prefer this to happen in the core
Such kind of hidden data change will confuse users.

> Robert Munteanu <rob...@gm...> hat am 25. Oktober 2014 um 11:37
> geschrieben:
> 
> 
> On Sat, Oct 25, 2014 at 12:35 PM, Roland Becker <ro...@at...> wrote:
> >> Then automatically set the fixed_in_version to be equal to the
> >> target_version.
> > Do you want this to take place in the UI or in the core (bug_api.php)?
> 
> I would prefer this to happen in the core so that it's available to
> the SOAP API as well.
> 
> I realise that we possibly have one edge case here - users who desire
> to have target_version set but fix_in_version empty. However, I hope
> that's not really happening in practice.
> 
> Robert
> 
> >
> >> Robert Munteanu <rob...@gm...> hat am 25. Oktober 2014 um
> >> 11:24
> >> geschrieben:
> >>
> >>
> >> Hi,
> >>
> >> I was thinking that having two different version fields ( target
> >> version and fixed in version ) in a bug can be confusing for some
> >> users. I understand that there are some advanced use cases, but IMO we
> >> should also optimize for the simple workflow, where fix version should
> >> be the same as the target version.
> >>
> >> For that I suggest the following enhancement for 1.3:
> >>
> >> When modifying a bug such that
> >> - status >= bug_resolved_status_threshold
> >> - resolution >= bug_resolution_fixed_threshold
> >> - target_version exists
> >> - fixed_in_version is empty
> >>
> >> Then automatically set the fixed_in_version to be equal to the
> >> target_version.
> >>
> >> Thoughts?
> >>
> >> Robert
> >>
> >> --
> >> http://robert.muntea.nu/
> >>
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> mantisbt-dev mailing list
> >> man...@li...
> >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> 
> 
> 
> -- 
> http://robert.muntea.nu/

Re: [mantisbt-dev] Simplify Target Version/Fixed in Version management for 1.3

[Alain D'E. <ala...@gm...>]

Hi,I would like to +1 to the simplification of the workflow.

What I personnaly do is:

- create one or several sandbox version(s), such as "Not Planned", or "3.2.x", "3.x", "4.x", where "x" is really the letter x.

- then when we decide the roadmaps of the bug fix versions, for instance 3.2.1, 3.2.2, etc. target the bugs 3.2.1, 3.2.2, etc. instead of 3.2.x

- idem for the other major versions 3.x, 4.x (requirement versions).

And it is often annoying to have to set the fix in version all the time, as for us it is (almost) always the same than the target version.




The only exception is when we reject a bug, the fixed in version is blank (most of the cases we don't want these bugs listed in the changelog)




Regards,

AlainD.


—
Alain D'EURVEILHER

On Sat, Oct 25, 2014 at 11:52 AM, Robert Munteanu
<rob...@gm...> wrote:

> On Sat, Oct 25, 2014 at 12:41 PM, P Richards <pa...@ma...> wrote:
>> Wouldn't you want to do this the other way around?
>>
>> On mantisbt.org for instance, it tends to target 1.3.x
>>
>> Then when an issue is resolved, have user target the actual (future) version
>> it's fixed in i.e. 1.3.0, and at that point update the Target version to the
>> value set for fixed in version.
>>
>> Or even, update the target version to null at the point fixed in version is
>> set.
>>
>> The 2nd case might make more sense - as the target version for bug would
>> technically cease to exist once a bug had been fixed in a version.
>>
>> Paul
> Hm, here's how I tend to do things, not sure if it applies to everyone
> but I've seen this done in practice:
> - target some bugs for the X release so they show up on the roadmap page
> - resolve bugs, set fixed_in_version to the X release so they show up
> on the changelog page
> - when version X is released, mass change all bugs to target the X+1 release
> This is also what I see when working with other trackers ( except
> other trackers don't have two fields ) - issues are targeted to
> versions and moved when the version is released.
> The changes I proposed support this workflow - but we need to make
> sure that we don't invalidate use cases such as the one you outlined
> above.
> Robert
> -- 
> http://robert.muntea.nu/
> ------------------------------------------------------------------------------
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Simplify Target Version/Fixed in Version management for 1.3

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

On Sat, Oct 25, 2014 at 12:41 PM, P Richards <pa...@ma...> wrote:
> Wouldn't you want to do this the other way around?
>
> On mantisbt.org for instance, it tends to target 1.3.x
>
> Then when an issue is resolved, have user target the actual (future) version
> it's fixed in i.e. 1.3.0, and at that point update the Target version to the
> value set for fixed in version.
>
> Or even, update the target version to null at the point fixed in version is
> set.
>
> The 2nd case might make more sense - as the target version for bug would
> technically cease to exist once a bug had been fixed in a version.
>
> Paul

Hm, here's how I tend to do things, not sure if it applies to everyone
but I've seen this done in practice:

- target some bugs for the X release so they show up on the roadmap page
- resolve bugs, set fixed_in_version to the X release so they show up
on the changelog page
- when version X is released, mass change all bugs to target the X+1 release

This is also what I see when working with other trackers ( except
other trackers don't have two fields ) - issues are targeted to
versions and moved when the version is released.

The changes I proposed support this workflow - but we need to make
sure that we don't invalidate use cases such as the one you outlined
above.

Robert


-- 
http://robert.muntea.nu/