Menu
▾
▴
mantisbt-dev — MantisBT development discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(18) |
Feb
(17) |
Mar
(11) |
Apr
(12) |
May
(21) |
Jun
(76) |
Jul
(8) |
Aug
(156) |
Sep
(117) |
Oct
(67) |
Nov
(122) |
Dec
(134) |
| 2003 |
Jan
(170) |
Feb
(214) |
Mar
(121) |
Apr
(36) |
May
(25) |
Jun
(10) |
Jul
(13) |
Aug
(69) |
Sep
(3) |
Oct
(17) |
Nov
(2) |
Dec
(40) |
| 2004 |
Jan
(34) |
Feb
(50) |
Mar
(69) |
Apr
(10) |
May
(76) |
Jun
(126) |
Jul
(180) |
Aug
(32) |
Sep
(43) |
Oct
(31) |
Nov
(25) |
Dec
(21) |
| 2005 |
Jan
(23) |
Feb
(75) |
Mar
(32) |
Apr
(34) |
May
(23) |
Jun
(34) |
Jul
(25) |
Aug
(21) |
Sep
(31) |
Oct
(34) |
Nov
(6) |
Dec
(16) |
| 2006 |
Jan
(9) |
Feb
(19) |
Mar
(45) |
Apr
(64) |
May
(33) |
Jun
(29) |
Jul
(11) |
Aug
(24) |
Sep
(55) |
Oct
(24) |
Nov
(38) |
Dec
(40) |
| 2007 |
Jan
(47) |
Feb
(28) |
Mar
(89) |
Apr
(35) |
May
(58) |
Jun
(30) |
Jul
(103) |
Aug
(80) |
Sep
(57) |
Oct
(108) |
Nov
(45) |
Dec
(38) |
| 2008 |
Jan
(39) |
Feb
(45) |
Mar
(29) |
Apr
(46) |
May
(39) |
Jun
(20) |
Jul
(19) |
Aug
(38) |
Sep
(40) |
Oct
(49) |
Nov
(64) |
Dec
(31) |
| 2009 |
Jan
(20) |
Feb
(31) |
Mar
(28) |
Apr
(46) |
May
(45) |
Jun
(45) |
Jul
(32) |
Aug
(11) |
Sep
(34) |
Oct
(33) |
Nov
(40) |
Dec
(17) |
| 2010 |
Jan
(28) |
Feb
(55) |
Mar
(23) |
Apr
(78) |
May
(33) |
Jun
(11) |
Jul
(10) |
Aug
(12) |
Sep
(70) |
Oct
(89) |
Nov
(55) |
Dec
(33) |
| 2011 |
Jan
(33) |
Feb
(66) |
Mar
(33) |
Apr
(40) |
May
(20) |
Jun
(29) |
Jul
(199) |
Aug
(42) |
Sep
(76) |
Oct
(10) |
Nov
(29) |
Dec
(38) |
| 2012 |
Jan
(30) |
Feb
(52) |
Mar
(56) |
Apr
(25) |
May
(17) |
Jun
(93) |
Jul
(15) |
Aug
(19) |
Sep
(23) |
Oct
(78) |
Nov
(59) |
Dec
(2) |
| 2013 |
Jan
(62) |
Feb
(18) |
Mar
(12) |
Apr
(119) |
May
(47) |
Jun
(34) |
Jul
(34) |
Aug
(12) |
Sep
(69) |
Oct
(128) |
Nov
(14) |
Dec
(11) |
| 2014 |
Jan
(232) |
Feb
(62) |
Mar
(67) |
Apr
(165) |
May
(82) |
Jun
(54) |
Jul
(26) |
Aug
(70) |
Sep
(56) |
Oct
(59) |
Nov
(3) |
Dec
(16) |
| 2015 |
Jan
(9) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
(17) |
Sep
(6) |
Oct
(4) |
Nov
(2) |
Dec
(3) |
| 2016 |
Jan
(19) |
Feb
(5) |
Mar
(6) |
Apr
(3) |
May
(1) |
Jun
(10) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: P R. <pa...@ma...> - 2014-10-25 09:41:31
|
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 -----Original Message----- From: Robert Munteanu [mailto:rob...@gm...] Sent: 25 October 2014 10:37 To: Roland Becker Cc: developer discussions Subject: Re: [mantisbt-dev] Simplify Target Version/Fixed in Version management for 1.3 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/ ---------------------------------------------------------------------------- -- _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
|
From: Robert M. <rob...@gm...> - 2014-10-25 09:37:32
|
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/ |
|
From: Roland B. <ro...@at...> - 2014-10-25 09:35:54
|
> 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)? > 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 |
|
From: Robert M. <rob...@gm...> - 2014-10-25 09:24:19
|
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/ |
|
From: Louis B. <lba...@gm...> - 2014-10-23 10:46:18
|
The first solution did it ! > set $g_path to external path Mantis is not accessible on the internal, but I don't care, that's the perfect solution for me ! thank you, Louis Louis BAYLE Tel: +33 (0)4.42.604.734 lba...@gm... On Tue, Oct 21, 2014 at 1:54 PM, Paul Richards <pa...@ma...> wrote: > Ok, > > What I think I meant was: > > a) don't apply that patch > b) set $g_path to external path ( assuming that it's a split ip type thing > - i.e. same internal and external name but the IP changes > > So for example: > > bugs.company.com on internal network AD dns goes to 172.16.1.20 > bugs.company.com on external DNS points to 88.88.88.88 > 88.88.88.88 is running some load balance (e.g. kemp or whatever) that is > set up to forward/reverse-proxy traffic hitting 88.888.888.88 to 172.16.1.20 > > In the above scenario, it should only be required to set $g_path and make > no changes to the mantis code base. [By default we try and calculate the > ip etc which could give weird results] > > > The other scenario would be: > > bugs.company.internaldomain on internal network goes to 172.16.1.20 > bugs.company.com on external dns points to 88.88.88.88 > > In this case, I'd be inclined to put a short code block in config_inc.php > that does effectively: > > > if(preg_match('/^(10|192|172)\./', $_SERVER['REMOTE_ADDR'])) > { > $g_path = 'bugs.company.internal.domain'; > } else { > $g_path = 'bugs.company.com'; > } > > I don't believe it should be required to make any changes to the Mantis > Codebase for either of these scenarios to work. > > Paul > > On Tue, Oct 21, 2014 at 11:55 AM, Louis BAYLE <lba...@gm...> > wrote: > >> I applied the pache descriped in issue 13056. >> This patch works "a little" : most URLs are correct, there are bad urls >> when a user disconnects and reconnects on a page that is not the root >> https://host/mantis. >> >> The email pb is because the patch sets $gpath to empty string. Therefore, >> string_get_confirm_hash_url cannot return a complete URL. >> >> ----------------- >> patch applied form 13056: >> >> >> Mantis\config_inc.php >> line 13 >> // modif proxy >> $g_path = ''; >> $t_url = ''; >> >> Mantis\core\string_api.php >> line 292 >> //return $t_path . '/' . $t_script . $t_query . $t_anchor; >> // modif proxy >> return $t_path . $t_script . $t_query . $t_anchor; >> >> Mantis\core\helper_api.php >> line 482 >> //return config_get_global( 'short_path' ) . $p_url; >> // modif proxy >> return $p_url; >> >> Louis BAYLE >> Tel: +33 (0)4.42.604.734 >> lba...@gm... >> >> On Sun, Oct 19, 2014 at 12:25 PM, P Richards <pa...@ma...> >> wrote: >> >>> In what bit of the generated email? >>> >>> >>> >>> From what I can see at first glance (in master at least): >>> >>> >>> >>> function string_get_confirm_hash_url( $p_user_id, $p_confirm_hash ) { >>> >>> $t_path = config_get( 'path' ); >>> >>> return $t_path . 'verify.php?id=' . string_url( >>> $p_user_id ) . '&confirm_hash=' . string_url( $p_confirm_hash ); >>> >>> } >>> >>> We always make use of config_get(‘path’) to get the value >>> >>> >>> >>> Paul >>> >>> >>> >>> *From:* Louis BAYLE [mailto:lba...@gm...] >>> *Sent:* 19 October 2014 09:29 >>> >>> *To:* developer discussions >>> *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy >>> >>> >>> >>> also, I had to hardcode the path in the login confirmation email, as >>> there is no way for mantis to know the external URL. >>> >>> >>> Louis BAYLE >>> Tel: +33 (0)4.42.604.734 >>> lba...@gm... >>> >>> >>> >>> On Sun, Oct 19, 2014 at 10:26 AM, Louis BAYLE <lba...@gm...> >>> wrote: >>> >>> In deed, we have mantis listening internal on http://172.x.x.x and >>> accessible on the external with https://88.x.x.x (the reverse-proxy). >>> >>> I'm fine if users access only via https, that's what I did for CodevTT. >>> I'll try the $g_path patch asap. >>> >>> >>> >>> >>> Louis BAYLE >>> Tel: +33 (0)4.42.604.734 >>> lba...@gm... >>> >>> >>> >>> On Sun, Oct 19, 2014 at 1:06 AM, P Richards <pa...@ma...> >>> wrote: >>> >>> If I’m correct about what the issue is likely to be, the problem might >>> actually be ‘worse’ in 1.3-dev – however unless I’m mistaken here: >>> >>> >>> >>> Unless you are saying that the INTERNAL and EXTERNAL path to mantis is >>> different, it should be a case of setting $g_path to the final path: >>> >>> >>> >>> $g_path = $t_protocol . '://' . $t_host . $t_path; >>> >>> >>> >>> i.e. >>> >>> >>> >>> if you have mantis listening on http, with a loadbalancing reverse proxy >>> in front running https, whilst Mantis will detect http://www.foo.com, >>> if you set >>> >>> >>> >>> $g_path = https://www.foo.com in the config file that should work I >>> believe. >>> >>> >>> >>> >>> >>> If you are saying that you use http://mantis.internal and www.foo.org >>> depending on whether users are internal or external to the corporate >>> network, then this might be more of an issue. >>> >>> >>> >>> Looking at the code, we seem to generate a mixture of absolute and >>> relative links within a page in both 1.2 and 1.3 – the $g_path fix should >>> be fine for the reverse proxy case, however, the absolute links will need >>> to go to deal with the split-dns case. >>> >>> >>> >>> Paul >>> >>> >>> >>> >>> >>> *From:* Louis BAYLE [mailto:lba...@gm...] >>> *Sent:* 18 October 2014 23:16 >>> *To:* developer discussions >>> *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy >>> >>> >>> >>> Yes, I can install a mantis 1.3-dev on our server and test it. >>> >>> I'm not sure I'll have time to do that next week, but I'll let you know. >>> >>> >>> Louis BAYLE >>> Tel: +33 (0)4.42.604.734 >>> lba...@gm... >>> >>> >>> >>> On Sat, Oct 18, 2014 at 11:55 PM, Paul Richards < >>> gra...@bl...> wrote: >>> >>> Are you able to test if the situation is any better with 1.3-dev? >>> >>> >>> >>> If this is an absolute vs relative link type issue, (which I’m guessing >>> it is) I’m not sure if the situation is improved in 1.3 >>> >>> >>> >>> Paul >>> >>> >>> >>> *From:* Louis BAYLE [mailto:lba...@gm...] >>> *Sent:* 18 October 2014 22:44 >>> *To:* developer discussions >>> *Subject:* [mantisbt-dev] Mantis not working behind a reverse-proxy >>> >>> >>> >>> Is there a 'good patch' to fix this realy problematic bug in Mantis ? >>> >>> The patch I applied to our installation does not work very well. >>> IMHO this is realy a critical bug. >>> >>> >>> http://www.mantisbt.org/bugs/view.php?id=13056 >>> http://www.mantisbt.org/bugs/view.php?id=9333 >>> >>> Louis BAYLE >>> Tel: +33 (0)4.42.604.734 >>> lba...@gm... >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > > ------------------------------------------------------------------------------ > 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 > > |
|
From: Paul R. <pa...@ma...> - 2014-10-21 11:54:17
|
Ok, What I think I meant was: a) don't apply that patch b) set $g_path to external path ( assuming that it's a split ip type thing - i.e. same internal and external name but the IP changes So for example: bugs.company.com on internal network AD dns goes to 172.16.1.20 bugs.company.com on external DNS points to 88.88.88.88 88.88.88.88 is running some load balance (e.g. kemp or whatever) that is set up to forward/reverse-proxy traffic hitting 88.888.888.88 to 172.16.1.20 In the above scenario, it should only be required to set $g_path and make no changes to the mantis code base. [By default we try and calculate the ip etc which could give weird results] The other scenario would be: bugs.company.internaldomain on internal network goes to 172.16.1.20 bugs.company.com on external dns points to 88.88.88.88 In this case, I'd be inclined to put a short code block in config_inc.php that does effectively: if(preg_match('/^(10|192|172)\./', $_SERVER['REMOTE_ADDR'])) { $g_path = 'bugs.company.internal.domain'; } else { $g_path = 'bugs.company.com'; } I don't believe it should be required to make any changes to the Mantis Codebase for either of these scenarios to work. Paul On Tue, Oct 21, 2014 at 11:55 AM, Louis BAYLE <lba...@gm...> wrote: > I applied the pache descriped in issue 13056. > This patch works "a little" : most URLs are correct, there are bad urls > when a user disconnects and reconnects on a page that is not the root > https://host/mantis. > > The email pb is because the patch sets $gpath to empty string. Therefore, > string_get_confirm_hash_url cannot return a complete URL. > > ----------------- > patch applied form 13056: > > > Mantis\config_inc.php > line 13 > // modif proxy > $g_path = ''; > $t_url = ''; > > Mantis\core\string_api.php > line 292 > //return $t_path . '/' . $t_script . $t_query . $t_anchor; > // modif proxy > return $t_path . $t_script . $t_query . $t_anchor; > > Mantis\core\helper_api.php > line 482 > //return config_get_global( 'short_path' ) . $p_url; > // modif proxy > return $p_url; > > Louis BAYLE > Tel: +33 (0)4.42.604.734 > lba...@gm... > > On Sun, Oct 19, 2014 at 12:25 PM, P Richards <pa...@ma...> wrote: > >> In what bit of the generated email? >> >> >> >> From what I can see at first glance (in master at least): >> >> >> >> function string_get_confirm_hash_url( $p_user_id, $p_confirm_hash ) { >> >> $t_path = config_get( 'path' ); >> >> return $t_path . 'verify.php?id=' . string_url( >> $p_user_id ) . '&confirm_hash=' . string_url( $p_confirm_hash ); >> >> } >> >> We always make use of config_get(‘path’) to get the value >> >> >> >> Paul >> >> >> >> *From:* Louis BAYLE [mailto:lba...@gm...] >> *Sent:* 19 October 2014 09:29 >> >> *To:* developer discussions >> *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy >> >> >> >> also, I had to hardcode the path in the login confirmation email, as >> there is no way for mantis to know the external URL. >> >> >> Louis BAYLE >> Tel: +33 (0)4.42.604.734 >> lba...@gm... >> >> >> >> On Sun, Oct 19, 2014 at 10:26 AM, Louis BAYLE <lba...@gm...> >> wrote: >> >> In deed, we have mantis listening internal on http://172.x.x.x and >> accessible on the external with https://88.x.x.x (the reverse-proxy). >> >> I'm fine if users access only via https, that's what I did for CodevTT. >> I'll try the $g_path patch asap. >> >> >> >> >> Louis BAYLE >> Tel: +33 (0)4.42.604.734 >> lba...@gm... >> >> >> >> On Sun, Oct 19, 2014 at 1:06 AM, P Richards <pa...@ma...> wrote: >> >> If I’m correct about what the issue is likely to be, the problem might >> actually be ‘worse’ in 1.3-dev – however unless I’m mistaken here: >> >> >> >> Unless you are saying that the INTERNAL and EXTERNAL path to mantis is >> different, it should be a case of setting $g_path to the final path: >> >> >> >> $g_path = $t_protocol . '://' . $t_host . $t_path; >> >> >> >> i.e. >> >> >> >> if you have mantis listening on http, with a loadbalancing reverse proxy >> in front running https, whilst Mantis will detect http://www.foo.com, if >> you set >> >> >> >> $g_path = https://www.foo.com in the config file that should work I >> believe. >> >> >> >> >> >> If you are saying that you use http://mantis.internal and www.foo.org >> depending on whether users are internal or external to the corporate >> network, then this might be more of an issue. >> >> >> >> Looking at the code, we seem to generate a mixture of absolute and >> relative links within a page in both 1.2 and 1.3 – the $g_path fix should >> be fine for the reverse proxy case, however, the absolute links will need >> to go to deal with the split-dns case. >> >> >> >> Paul >> >> >> >> >> >> *From:* Louis BAYLE [mailto:lba...@gm...] >> *Sent:* 18 October 2014 23:16 >> *To:* developer discussions >> *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy >> >> >> >> Yes, I can install a mantis 1.3-dev on our server and test it. >> >> I'm not sure I'll have time to do that next week, but I'll let you know. >> >> >> Louis BAYLE >> Tel: +33 (0)4.42.604.734 >> lba...@gm... >> >> >> >> On Sat, Oct 18, 2014 at 11:55 PM, Paul Richards < >> gra...@bl...> wrote: >> >> Are you able to test if the situation is any better with 1.3-dev? >> >> >> >> If this is an absolute vs relative link type issue, (which I’m guessing >> it is) I’m not sure if the situation is improved in 1.3 >> >> >> >> Paul >> >> >> >> *From:* Louis BAYLE [mailto:lba...@gm...] >> *Sent:* 18 October 2014 22:44 >> *To:* developer discussions >> *Subject:* [mantisbt-dev] Mantis not working behind a reverse-proxy >> >> >> >> Is there a 'good patch' to fix this realy problematic bug in Mantis ? >> >> The patch I applied to our installation does not work very well. >> IMHO this is realy a critical bug. >> >> >> http://www.mantisbt.org/bugs/view.php?id=13056 >> http://www.mantisbt.org/bugs/view.php?id=9333 >> >> Louis BAYLE >> Tel: +33 (0)4.42.604.734 >> lba...@gm... >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > > ------------------------------------------------------------------------------ > 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 > > |
|
From: Robert M. <rob...@gm...> - 2014-10-21 11:05:40
|
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/ |
|
From: Louis B. <lba...@gm...> - 2014-10-21 10:56:16
|
I applied the pache descriped in issue 13056.
This patch works "a little" : most URLs are correct, there are bad urls
when a user disconnects and reconnects on a page that is not the root
https://host/mantis.
The email pb is because the patch sets $gpath to empty string. Therefore,
string_get_confirm_hash_url cannot return a complete URL.
-----------------
patch applied form 13056:
Mantis\config_inc.php
line 13
// modif proxy
$g_path = '';
$t_url = '';
Mantis\core\string_api.php
line 292
//return $t_path . '/' . $t_script . $t_query . $t_anchor;
// modif proxy
return $t_path . $t_script . $t_query . $t_anchor;
Mantis\core\helper_api.php
line 482
//return config_get_global( 'short_path' ) . $p_url;
// modif proxy
return $p_url;
Louis BAYLE
Tel: +33 (0)4.42.604.734
lba...@gm...
On Sun, Oct 19, 2014 at 12:25 PM, P Richards <pa...@ma...> wrote:
> In what bit of the generated email?
>
>
>
> From what I can see at first glance (in master at least):
>
>
>
> function string_get_confirm_hash_url( $p_user_id, $p_confirm_hash ) {
>
> $t_path = config_get( 'path' );
>
> return $t_path . 'verify.php?id=' . string_url( $p_user_id
> ) . '&confirm_hash=' . string_url( $p_confirm_hash );
>
> }
>
> We always make use of config_get(‘path’) to get the value
>
>
>
> Paul
>
>
>
> *From:* Louis BAYLE [mailto:lba...@gm...]
> *Sent:* 19 October 2014 09:29
>
> *To:* developer discussions
> *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy
>
>
>
> also, I had to hardcode the path in the login confirmation email, as there
> is no way for mantis to know the external URL.
>
>
> Louis BAYLE
> Tel: +33 (0)4.42.604.734
> lba...@gm...
>
>
>
> On Sun, Oct 19, 2014 at 10:26 AM, Louis BAYLE <lba...@gm...>
> wrote:
>
> In deed, we have mantis listening internal on http://172.x.x.x and
> accessible on the external with https://88.x.x.x (the reverse-proxy).
>
> I'm fine if users access only via https, that's what I did for CodevTT.
> I'll try the $g_path patch asap.
>
>
>
>
> Louis BAYLE
> Tel: +33 (0)4.42.604.734
> lba...@gm...
>
>
>
> On Sun, Oct 19, 2014 at 1:06 AM, P Richards <pa...@ma...> wrote:
>
> If I’m correct about what the issue is likely to be, the problem might
> actually be ‘worse’ in 1.3-dev – however unless I’m mistaken here:
>
>
>
> Unless you are saying that the INTERNAL and EXTERNAL path to mantis is
> different, it should be a case of setting $g_path to the final path:
>
>
>
> $g_path = $t_protocol . '://' . $t_host . $t_path;
>
>
>
> i.e.
>
>
>
> if you have mantis listening on http, with a loadbalancing reverse proxy
> in front running https, whilst Mantis will detect http://www.foo.com, if
> you set
>
>
>
> $g_path = https://www.foo.com in the config file that should work I
> believe.
>
>
>
>
>
> If you are saying that you use http://mantis.internal and www.foo.org
> depending on whether users are internal or external to the corporate
> network, then this might be more of an issue.
>
>
>
> Looking at the code, we seem to generate a mixture of absolute and
> relative links within a page in both 1.2 and 1.3 – the $g_path fix should
> be fine for the reverse proxy case, however, the absolute links will need
> to go to deal with the split-dns case.
>
>
>
> Paul
>
>
>
>
>
> *From:* Louis BAYLE [mailto:lba...@gm...]
> *Sent:* 18 October 2014 23:16
> *To:* developer discussions
> *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy
>
>
>
> Yes, I can install a mantis 1.3-dev on our server and test it.
>
> I'm not sure I'll have time to do that next week, but I'll let you know.
>
>
> Louis BAYLE
> Tel: +33 (0)4.42.604.734
> lba...@gm...
>
>
>
> On Sat, Oct 18, 2014 at 11:55 PM, Paul Richards <
> gra...@bl...> wrote:
>
> Are you able to test if the situation is any better with 1.3-dev?
>
>
>
> If this is an absolute vs relative link type issue, (which I’m guessing it
> is) I’m not sure if the situation is improved in 1.3
>
>
>
> Paul
>
>
>
> *From:* Louis BAYLE [mailto:lba...@gm...]
> *Sent:* 18 October 2014 22:44
> *To:* developer discussions
> *Subject:* [mantisbt-dev] Mantis not working behind a reverse-proxy
>
>
>
> Is there a 'good patch' to fix this realy problematic bug in Mantis ?
>
> The patch I applied to our installation does not work very well.
> IMHO this is realy a critical bug.
>
>
> http://www.mantisbt.org/bugs/view.php?id=13056
> http://www.mantisbt.org/bugs/view.php?id=9333
>
> Louis BAYLE
> Tel: +33 (0)4.42.604.734
> lba...@gm...
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
|
|
From: Louis B. <lba...@gm...> - 2014-10-21 08:56:22
|
Hi, Of course it's always sad to see a teem split because it's often a waste of energy. But forks are part of open-source project's life and sometime the best thing to go forward. Also, I'm new to the Mantis community and I have absolutely no judgement on this. I just wanted to thank you for your interest to CodevTT, and I hope that you will not too much change the database in your fork, so that CodevTT can be compatible with both :-) I'm looking forward to see your patches, best regards Louis Louis BAYLE Tel: +33 (0)4.42.604.734 lba...@gm... On Tue, Oct 21, 2014 at 1:04 AM, Damien Regad <dr...@ma...> wrote: > Paul > > Despite our arguments, I valued your contributions to Mantis and > sincerely regret your decision to leave the team. > > I wish you luck in your endeavor, but strongly suggest you pick a > different name and logo, to make sure you do not create any confusion in > the minds of users. > > I also hope that your fork will remain close enough to Mantis that we > can benefit from each other, à la MySQL/MariaDB. > > It also would be nice before you go, if you could release back to the > public all of the code you're currently holding in the mantisforge > archive, which you've been promising to do for nearly a year now (if not > more). > > > I’ve marked all my Pull requests on github as closed – some of them > > contained ideas that may or may not be worth implementing, however where > > everyone has seen them, whilst I’d be more than happy to help get them > > merged, it does not make sense to me to live them open at this time. > > I wish you hadn't done that - especially considering the recent "PR > spam" you generated, it will be more difficult and time-consuming to > retrieve them for an eventual merge. > > > Damien: Come and find me on IRC and we can go through security patches > > for 1.2.18 and work out who is due credit where for finding > > vulnerabilities. > > Will do. Until then, do try and send the patches to me (with additional > relevant info as needed) - I assure you my email works just fine. > > Damien > > > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Damien R. <dr...@ma...> - 2014-10-20 23:04:50
|
Paul Despite our arguments, I valued your contributions to Mantis and sincerely regret your decision to leave the team. I wish you luck in your endeavor, but strongly suggest you pick a different name and logo, to make sure you do not create any confusion in the minds of users. I also hope that your fork will remain close enough to Mantis that we can benefit from each other, à la MySQL/MariaDB. It also would be nice before you go, if you could release back to the public all of the code you're currently holding in the mantisforge archive, which you've been promising to do for nearly a year now (if not more). > I’ve marked all my Pull requests on github as closed – some of them > contained ideas that may or may not be worth implementing, however where > everyone has seen them, whilst I’d be more than happy to help get them > merged, it does not make sense to me to live them open at this time. I wish you hadn't done that - especially considering the recent "PR spam" you generated, it will be more difficult and time-consuming to retrieve them for an eventual merge. > Damien: Come and find me on IRC and we can go through security patches > for 1.2.18 and work out who is due credit where for finding > vulnerabilities. Will do. Until then, do try and send the patches to me (with additional relevant info as needed) - I assure you my email works just fine. Damien |
|
From: Damien R. <dr...@ma...> - 2014-10-20 21:54:22
|
On 2014-10-20 19:25, P Richards wrote: > Damien doesn't accept a patch via email ??? I repeatedly asked you to send me the patches by e-mail, so why do you say I don't accept them ? > The last security update that I did for 1.2 and got put into a release was > credited to someone else and I wasn't acknowledged for it in any way, so, > hence wanting to push a git branch somewhere where the same thing won't be > done again. That's somewhat out of topic, but I find your comment amusing, coming from someone who frequently commits other people's work under their own name... > When I did try sending an email to dr...@ma... it returned a > permanent failure, so... Strangely enough, you seem to be the only person having issues with my e-mail - I'm receving plenty of messages from many people on this address everyday, so I'm quite sure there are no issues on my end. And I'd say the problems are seemingly random, too, since I've even received 2 e-mails from you on 19-Oct (subject 'moo1' and 'FW: Delivery Status Notification (Failure)') So I suggest you try to send these patches again. Alternatively, as suggested by someone else before, fix your mantisforge gitlab, and give me access to whatever private branch you want over there. |
|
From: P R. <pa...@ma...> - 2014-10-20 21:50:38
|
And replying to my own post: I've marked all my Pull requests on github as closed - some of them contained ideas that may or may not be worth implementing, however where everyone has seen them, whilst I'd be more than happy to help get them merged, it does not make sense to me to live them open at this time. Roland: Thanks for your support and advice and hopefully keep in touch. Louis Bayle: I'll probably sent you a few patches over the coming months. Victor: I suspect you've wanted to get rid of me for a while, so this should make life easier for you. If you do want to discuss anything you know where to find me. Rombert: keep in touch. IT would be good to see you send your thoughts on the SOAP API to the list one day Damien: Come and find me on IRC and we can go through security patches for 1.2.18 and work out who is due credit where for finding vulnerabilities. I believe I'm currently aware of 2 vulnerabilities that are not yet in bugs in the bug tracker, as well as having fixes for the others. I *think* I may be missing 1 patch across the known issues. To make life simple, we'll treat the relationship for now as that of a security researcher and plan it as a "joint disclosure" where proper credit and any announcements are released in sync. Paul From: P Richards [mailto:pa...@ma...] Sent: 20 October 2014 22:24 To: 'developer discussions' Subject: [mantisbt-dev] Hi All - A change of direction for me. 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 |
|
From: P R. <pa...@ma...> - 2014-10-20 21:24:36
|
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 |
|
From: P R. <pa...@ma...> - 2014-10-20 20:55:42
|
As promised, here is my analysis for discussion on PR’s regarding Date and timezone Handling in Mantis: Victor generated a commit on 13th October 2014 - https://github.com/vboctor/mantisbt/commit/6e85426cce9bad63e632d82ebe0b44e6a99c7df4.patch This commit was to make 2 changes: a) Add date_default_timezone_set( ‘UTC’ ) in install.php to override date time handling b) Add a similar date_default_timezone_Set(‘UTC’) in testconfig.php Atrol gave this commit a +1 Rombert gave this commit a +1 I gave this commit a -1, and started looking at a solution within core.php Damien also gave a -1 and stated he’d submit a PR. Victor stated: “I'm not attached to any solution here, so feel free to suggest alternatives or even submit an alternate pull request.” I believe victor’s and damien’s statement that both myself and him made the same incorrect assumption may be correct. [Edit: Whilst I didn’t respond to this comment, as I’d already started looking at core.php, I’d probably be inclined to question where the reliance on adding the default timezone in testconfig.php was actually kicking in, as neither Damien’s or my PR requires changes to testconfig.php] Moving on to the 2 pull requests: Firstly we have damien’s request which makes the following changes: It fixes an issue (#17751) raised by damien at point of coding to add UTC to the timezone selection list. At the moment, in the current master branch we display timezones to user via “Continent” and then the actual timezone/city/place – this gives just under ~415 timezones. The patched code gives ~430 timezones. Ignoring the UTC addition - It fixes a bug in the initial generation of timezones and introduces a new bug. Points on this: • UTC Addition – whilst it looks a bit strange having UTC\UTC in the list, and part of me would like to say “it’s a list of continents with locations for timezones, that UTC is neither, and therefore shouldn’t be included as people should select their actual location. However, equally I can imagine that some people would prefer to go for UTC for simplicity. • On the basis of the above, I wonder if UTC should be at the top of the list without a subheading i.e. just UTC and not indented, and positioned first for easy access for people. • In terms of the bug it fixes – the existing timezone code in Mantis generates “America\Argentina\Costas Ricos” and “America\Argentina\Somewhere else” as a single timezone entry. This would be technically incorrect as there’s about 7 timezones in argentina etc. • In terms of the new bug it introduces; the code does not correctly account for the additional \, so the list now displays Argentina 7 times to the end user. As an aside point on timezones, the timezone database has been known to change – there are documented issues on the internet with other projects e.g. wordpress when a timezone disappeared from the database or got renamed. Whilst I think it’s nice to be able to select a timezone ( I added the initial support including the bug above in 2009 - https://github.com/mantisbt/mantisbt/commit/a058e7596193f2fecb0e14786f68a9171c216fdf ), I do wonder whether we would hit similar issues if a timezone ceased to be available following a PHP upgrade etc like users found with wordpress, and whether a ‘simpler list’ of timezones should exist. (24 hours a day most timezones are to nearest hour with or without daylight savings time, so you should only need ~48 entries to represent all timezones vs 430) The remaining changes in dregad’s patch add alter: a) Admin checks for timezone handling b) Comment within config_defaults_inc.php c) Move date time setting to date_api.php Victor makes a comment that the functionality moved to date_api.php may be better staying in core.php And equally in damien’s PR, we simplify the code to skip the function_exists(timezone_identifiers_list) call given we no longer support php 5.1 The second pull request that I submitted, following victor’s original suggestion to submit our own alternatives ( and I’ll requote here: ““I'm not attached to any solution here, so feel free to suggest alternatives or even submit an alternate pull request.”, tries to simplify the process completely. As both Damien and myself have identified, the timezone_identifiers_list function check is no longer relevant in newer php’s, so that check is removed from accounts_prefs_update.php and print_api.php At this point, is where the changes in the PR differ: The default Mantis installer now ask an admin to set a timezone. This means that as part of the installation a timezone should be set into config_inc.php Therefore, we can simplify the code trying to distinguish between php 5.3 and php 5.4 etc to just use the value supplied into config_inc.php by the admin. The end result of this being that if a mantis installation is moved between servers, i.e. a user running a mantis instance moves Service/Hosting provider etc, the behaviour of their mantis instance remains static, unless they change the default timezone. This is a more consistent approach for the end user, and enables the admin checks to be simplified to request that a default timezone is always set as part of this. The remaining change in the PR I submitted is to the install.php file (https://github.com/mantisbt/mantisbt/pull/387/files#diff-72e6d26b8cc2f41c566e16681a191667L53 ) to temporarily set a default timezone for the legacy admin user creation code (Which is the issue victor was initially facing). The 3rd change in this PR is to just use the value of MANTIS_MAINTENANCE_MODE as opposed to trying to calculate basename from a path, as for both the installer and the admin checks, we set MANTIS_MAINTENANCE_MODE to true. Whilst I believe that we should pull in a fixed version of damien’s UTC addition, I believe we should look at using the code that I’ve come up with as a simpler version of core.php, as opposed to moving the logic into date api, and ensuring that config_inc.php always contains a valid timezone. From: Paul Richards [mailto:pa...@ma...] Sent: 20 October 2014 07:39 To: developer discussions Subject: [mantisbt-dev] Fwd: FW: [mantisbt] Simplify timezone configuration within Mantis (#387) ---------- Forwarded message ---------- Date: Mon, Oct 20, 2014 at 12:35 AM Subject: FW: [mantisbt] Simplify timezone configuration within Mantis (#387) To: developer discussions <man...@li... <mailto:man...@li...> > Victor, that's just silly. If you look at the pull request, my point before was that our date handling is over complicated. On the initial PR that you raised, https://github.com/mantisbt/mantisbt/pull/380 Atrol/Rombert said +1 to your PR aka #380 I said "definitely a -1 to this, but before I go into details, are you hitting it on Centos/RHEL" Damien also said -1, and then also said he’d do a PR. Hence there are now 2 PR’s following up your initial work. In the case of damien’s request, as I say I believe it overcomplicates our handling of date times and that we should look at simplifying the functionality. If you actually spent the time to look, you may see my point. Anyway, Given that I’ve got a -1 to Damien’s pull request and you’ve now given a -1 to my pull request, and both myself and damien gave a -1 to your pull request, we have now hit a situation where to move forward, I’d like to request a mailing list discussion on both Pull requests, as it seems we are not going to get agreement via Github. It’s 12:30AM now so don’t have time now, I will write up arguments for and against the PR’s tomorrow, and then we can discuss, and if need be have a vote at the end. Hopefully Damien will be more mature then yourself, and actually take the time to look and consider what we are actually trying to do. Thanks Paul From: Victor Boctor [mailto:not...@gi... <mailto:not...@gi...> ] Sent: 20 October 2014 00:07 To: mantisbt/mantisbt Cc: grangeway Subject: Re: [mantisbt] Simplify timezone configuration within Mantis (#387) -1 - I'm not even going to review this. We don't need 3 pull requests for a fix. If you have feedback give it to Damien who spent the time to write a thorough fix. There are two options here: * Give him the feedback that he can incorporate. * If you want to go further than he has the bandwidth to do as part of his checkin, then do follow up pull requests after his work is checked in. — Reply to this email directly or view it on GitHub <https://github.com/mantisbt/mantisbt/pull/387#issuecomment-59669774> . <https://github.com/notifications/beacon/434241__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyOTM3OTIyOCwiZGF0YSI6eyJpZCI6NDYxODMzNTF9fQ==--56b890c08fb21ae4ed4f85213e8d51fd019cdbdf.gif> |
|
From: P R. <pa...@ma...> - 2014-10-20 18:43:25
|
ERROR: Permission to mantisbt/mantisbt.git denied to grangeway. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. And still unable to email dr...@ma... <mailto:dr...@ma...> |
|
From: P R. <pa...@ma...> - 2014-10-20 17:28:03
|
ERROR: Permission to mantisbt/mantisbt.git denied to grangeway. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. |
|
From: P R. <pa...@ma...> - 2014-10-20 17:25:59
|
Damien doesn't accept a patch via email, and I'm hesistant to put in a PR for a security issue. Someone(damien) removed by access to github on Saturday (and still hasn't said anything) - so it's not possible to even commit security fixes. The last security update that I did for 1.2 and got put into a release was credited to someone else and I wasn't acknowledged for it in any way, so, hence wanting to push a git branch somewhere where the same thing won't be done again. When I did try sending an email to dr...@ma... it returned a permanent failure, so... Paul -----Original Message----- From: Robert Munteanu [mailto:rob...@gm...] Sent: 20 October 2014 15:36 To: developer discussions Subject: Re: [mantisbt-dev] 1.2.18 release (Sorry for asking but not contributing to this fix, but .... ) do we need to wait for Paul's patches or can someone come up with a security fix? I think it's not reponsibile towards our users to wait for someone to produce a security fix for such a long time. Cheers, Robert On Sun, Oct 19, 2014 at 2:09 AM, P Richards <pa...@ma...> wrote: > Apparently your email address doesn't work correctly - at least > (rather > amusingly) google isn't allowing a google user to email another google user: > > Delivery to the following recipient failed permanently: > > dr...@ma... > > Technical details of permanent failure: > Message rejected by Google Groups. Please visit > http://mail.google.com/support/bin/answer.py?hl=en&answer=188131 to > review our Bulk Email Senders Guidelines. > > ----- Original message ----- > > X-Received: by 10.180.85.102 with SMTP id g6mr8889617wiz.54.1413672671965; > Sat, 18 Oct 2014 05:51:11 -0700 (PDT) > Return-Path: <pa...@ma...> > Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com. > [209.85.212.175]) > by mx.google.com with ESMTPS id > r8si3539198wiy.73.2014.10.18.15.51.11 > for <dr...@ma...> > (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); > Sat, 18 Oct 2014 05:51:11 -0700 (PDT) > Received-SPF: none (google.com: pa...@ma... does not > designate permitted sender hosts) client-ip=209.85.212.175; > Authentication-Results: mx.google.com; > spf=neutral (google.com: pa...@ma... does not > designate permitted sender hosts) smtp.mail=pa...@ma... > Received: by mail-wi0-f175.google.com with SMTP id d1so4483466wiv.14 > for <dr...@ma...>; Sat, 18 Oct 2014 05:51:11 -0700 > (PDT) > > -----Original Message----- > From: Damien Regad [mailto:dr...@ma...] > Sent: 18 October 2014 23:23 > To: Man...@li... > Subject: [mantisbt-dev] 1.2.18 release > > Paul, > > As you know we have several open security issues including some fairly > critical ones. I have fixes ready to go for the most recent ones, and > to close the loop I want to release 1.2.18 as soon as possible. > > *I remind you that you owe us a series of security fixes since May*, > and you agreed earlier this week on IRC [1] to send them to me via e-mail by Friday. > > It is now late Saturday (early Sunday actually), and I still haven't > received anything from you. To be blunt: > > YOU ARE BLOCKING A SECURITY RELEASE > > This is really unprofressional. Please act responsibly, and put on > hold some of the trivialities you've been working on for the past few > weeks/months for the few minutes it will take to send me patches. And > please don't give me any of that shit again about your SSH access. > > Damien > > [1] > http://www.mantisbt.org/irclogs/mantisbt/2014/mantisbt.2014-10-15.log. > html > > > ---------------------------------------------------------------------- > ------ > -- > 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 > > > ---------------------------------------------------------------------- > -------- 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 |
|
From: Robert M. <rob...@gm...> - 2014-10-20 14:36:15
|
(Sorry for asking but not contributing to this fix, but .... ) do we need to wait for Paul's patches or can someone come up with a security fix? I think it's not reponsibile towards our users to wait for someone to produce a security fix for such a long time. Cheers, Robert On Sun, Oct 19, 2014 at 2:09 AM, P Richards <pa...@ma...> wrote: > Apparently your email address doesn't work correctly - at least (rather > amusingly) google isn't allowing a google user to email another google user: > > Delivery to the following recipient failed permanently: > > dr...@ma... > > Technical details of permanent failure: > Message rejected by Google Groups. Please visit > http://mail.google.com/support/bin/answer.py?hl=en&answer=188131 to review > our Bulk Email Senders Guidelines. > > ----- Original message ----- > > X-Received: by 10.180.85.102 with SMTP id g6mr8889617wiz.54.1413672671965; > Sat, 18 Oct 2014 05:51:11 -0700 (PDT) > Return-Path: <pa...@ma...> > Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com. > [209.85.212.175]) > by mx.google.com with ESMTPS id > r8si3539198wiy.73.2014.10.18.15.51.11 > for <dr...@ma...> > (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); > Sat, 18 Oct 2014 05:51:11 -0700 (PDT) > Received-SPF: none (google.com: pa...@ma... does not designate > permitted sender hosts) client-ip=209.85.212.175; > Authentication-Results: mx.google.com; > spf=neutral (google.com: pa...@ma... does not designate > permitted sender hosts) smtp.mail=pa...@ma... > Received: by mail-wi0-f175.google.com with SMTP id d1so4483466wiv.14 > for <dr...@ma...>; Sat, 18 Oct 2014 05:51:11 -0700 (PDT) > > -----Original Message----- > From: Damien Regad [mailto:dr...@ma...] > Sent: 18 October 2014 23:23 > To: Man...@li... > Subject: [mantisbt-dev] 1.2.18 release > > Paul, > > As you know we have several open security issues including some fairly > critical ones. I have fixes ready to go for the most recent ones, and to > close the loop I want to release 1.2.18 as soon as possible. > > *I remind you that you owe us a series of security fixes since May*, and you > agreed earlier this week on IRC [1] to send them to me via e-mail by Friday. > > It is now late Saturday (early Sunday actually), and I still haven't > received anything from you. To be blunt: > > YOU ARE BLOCKING A SECURITY RELEASE > > This is really unprofressional. Please act responsibly, and put on hold some > of the trivialities you've been working on for the past few weeks/months for > the few minutes it will take to send me patches. And please don't give me > any of that shit again about your SSH access. > > Damien > > [1] > http://www.mantisbt.org/irclogs/mantisbt/2014/mantisbt.2014-10-15.log.html > > > ---------------------------------------------------------------------------- > -- > 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 > > > ------------------------------------------------------------------------------ > 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/ |
|
From: Paul R. <pa...@ma...> - 2014-10-20 06:39:00
|
---------- Forwarded message ---------- Date: Mon, Oct 20, 2014 at 12:35 AM Subject: FW: [mantisbt] Simplify timezone configuration within Mantis (#387) To: developer discussions <man...@li...> Victor, that's just silly. If you look at the pull request, my point before was that our date handling is over complicated. On the initial PR that you raised, https://github.com/mantisbt/mantisbt/pull/380 Atrol/Rombert said +1 to your PR aka #380 I said "definitely a -1 to this, but before I go into details, are you hitting it on Centos/RHEL" Damien also said -1, and then also said he’d do a PR. Hence there are now 2 PR’s following up your initial work. In the case of damien’s request, as I say I believe it overcomplicates our handling of date times and that we should look at simplifying the functionality. If you actually spent the time to look, you may see my point. Anyway, Given that I’ve got a -1 to Damien’s pull request and you’ve now given a -1 to my pull request, and both myself and damien gave a -1 to your pull request, we have now hit a situation where to move forward, I’d like to request a mailing list discussion on both Pull requests, as it seems we are not going to get agreement via Github. It’s 12:30AM now so don’t have time now, I will write up arguments for and against the PR’s tomorrow, and then we can discuss, and if need be have a vote at the end. Hopefully Damien will be more mature then yourself, and actually take the time to look and consider what we are actually trying to do. Thanks Paul *From:* Victor Boctor [mailto:not...@gi...] *Sent:* 20 October 2014 00:07 *To:* mantisbt/mantisbt *Cc:* grangeway *Subject:* Re: [mantisbt] Simplify timezone configuration within Mantis (#387) -1 - I'm not even going to review this. We don't need 3 pull requests for a fix. If you have feedback give it to Damien who spent the time to write a thorough fix. There are two options here: - Give him the feedback that he can incorporate. - If you want to go further than he has the bandwidth to do as part of his checkin, then do follow up pull requests after his work is checked in. — Reply to this email directly or view it on GitHub <https://github.com/mantisbt/mantisbt/pull/387#issuecomment-59669774>. |
|
From: P R. <pa...@ma...> - 2014-10-19 22:53:51
|
If anyone's running 1.3-dev on a 'production box', you might want to read the following: Following Roland's suggestion to victor to think about what config_is_private is "good for" [https://github.com/mantisbt/mantisbt/pull/386#issuecomment-59629700 ], and following reviewing our use of global-only config's - the next logical step was to review config_is_private: I've put in a Pull Request following that (https://github.com/mantisbt/mantisbt/pull/509/files ) One of the changes in that pull request is as follows: - case 'master_crypto_salt': + case 'crypto_master_salt': Within config.api, config_is_private function If you are running a version of 1.3 as a "production" instance somewhere, I'd like to suggest you change your master salt and apply the patch in this Pull Request. Paul |
|
From: P R. <pa...@ma...> - 2014-10-19 16:20:31
|
Apologies if anyone got some github notifications this morning - atrol got a few and gave me a poke so I was able to stop script that was generating them. I've got a simple script that I basically use to automate some merging and testing In essence, I was feeding in a batch of updates to update sql format for the db layer for 2.x to keep it up to date, and trying to do a local build to test. Usually this works quite well, and I've used it multiple times before - it basically takes a change, pushes it into a new local branch, runs a build and then tidies up at end if all builds pass, or leaves files if they don't. This was working its way through ~500 changes: Anyway, What happened here is I had a pending change for master in my local master (https://github.com/mantisbt/mantisbt/pull/378 ) for pushing. So instead of pushing locally, it pushed for a new remote PR (hence as atrol spotted, the reason for 2 commits in the branch) On the bright side, if atrol hadn't have spotted it, there were a considerable number more branches that would have been generated. Paul |
|
From: P R. <pa...@ma...> - 2014-10-19 10:25:24
|
In what bit of the generated email?
>From what I can see at first glance (in master at least):
function string_get_confirm_hash_url( $p_user_id, $p_confirm_hash ) {
$t_path = config_get( 'path' );
return $t_path . 'verify.php?id=' . string_url( $p_user_id ) . '&confirm_hash=' . string_url( $p_confirm_hash );
}
We always make use of config_get(‘path’) to get the value
Paul
From: Louis BAYLE [mailto:lba...@gm...]
Sent: 19 October 2014 09:29
To: developer discussions
Subject: Re: [mantisbt-dev] Mantis not working behind a reverse-proxy
also, I had to hardcode the path in the login confirmation email, as there is no way for mantis to know the external URL.
Louis BAYLE
Tel: +33 (0)4.42.604.734
lba...@gm... <mailto:lba...@gm...>
On Sun, Oct 19, 2014 at 10:26 AM, Louis BAYLE <lba...@gm... <mailto:lba...@gm...> > wrote:
In deed, we have mantis listening internal on http://172.x.x.x and accessible on the external with https://88.x.x.x (the reverse-proxy).
I'm fine if users access only via https, that's what I did for CodevTT. I'll try the $g_path patch asap.
Louis BAYLE
Tel: +33 (0)4.42.604.734
lba...@gm... <mailto:lba...@gm...>
On Sun, Oct 19, 2014 at 1:06 AM, P Richards <pa...@ma... <mailto:pa...@ma...> > wrote:
If I’m correct about what the issue is likely to be, the problem might actually be ‘worse’ in 1.3-dev – however unless I’m mistaken here:
Unless you are saying that the INTERNAL and EXTERNAL path to mantis is different, it should be a case of setting $g_path to the final path:
$g_path = $t_protocol . '://' . $t_host . $t_path;
i.e.
if you have mantis listening on http, with a loadbalancing reverse proxy in front running https, whilst Mantis will detect http://www.foo.com, if you set
$g_path = https://www.foo.com in the config file that should work I believe.
If you are saying that you use http://mantis.internal and www.foo.org <http://www.foo.org> depending on whether users are internal or external to the corporate network, then this might be more of an issue.
Looking at the code, we seem to generate a mixture of absolute and relative links within a page in both 1.2 and 1.3 – the $g_path fix should be fine for the reverse proxy case, however, the absolute links will need to go to deal with the split-dns case.
Paul
From: Louis BAYLE [mailto:lba...@gm... <mailto:lba...@gm...> ]
Sent: 18 October 2014 23:16
To: developer discussions
Subject: Re: [mantisbt-dev] Mantis not working behind a reverse-proxy
Yes, I can install a mantis 1.3-dev on our server and test it.
I'm not sure I'll have time to do that next week, but I'll let you know.
Louis BAYLE
Tel: +33 (0)4.42.604.734
lba...@gm... <mailto:lba...@gm...>
On Sat, Oct 18, 2014 at 11:55 PM, Paul Richards <gra...@bl... <mailto:gra...@bl...> > wrote:
Are you able to test if the situation is any better with 1.3-dev?
If this is an absolute vs relative link type issue, (which I’m guessing it is) I’m not sure if the situation is improved in 1.3
Paul
From: Louis BAYLE [mailto: <mailto:lba...@gm...> lba...@gm...]
Sent: 18 October 2014 22:44
To: developer discussions
Subject: [mantisbt-dev] Mantis not working behind a reverse-proxy
Is there a 'good patch' to fix this realy problematic bug in Mantis ?
The patch I applied to our installation does not work very well.
IMHO this is realy a critical bug.
http://www.mantisbt.org/bugs/view.php?id=13056
http://www.mantisbt.org/bugs/view.php?id=9333
Louis BAYLE
Tel: +33 (0)4.42.604.734
lba...@gm... <mailto:lba...@gm...>
------------------------------------------------------------------------------
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... <mailto:man...@li...>
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
------------------------------------------------------------------------------
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... <mailto:man...@li...>
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
|
|
From: Louis B. <lba...@gm...> - 2014-10-19 08:29:44
|
also, I had to hardcode the path in the login confirmation email, as there is no way for mantis to know the external URL. Louis BAYLE Tel: +33 (0)4.42.604.734 lba...@gm... On Sun, Oct 19, 2014 at 10:26 AM, Louis BAYLE <lba...@gm...> wrote: > In deed, we have mantis listening internal on http://172.x.x.x and > accessible on the external with https://88.x.x.x (the reverse-proxy). > > I'm fine if users access only via https, that's what I did for CodevTT. > I'll try the $g_path patch asap. > > > > Louis BAYLE > Tel: +33 (0)4.42.604.734 > lba...@gm... > > On Sun, Oct 19, 2014 at 1:06 AM, P Richards <pa...@ma...> wrote: > >> If I’m correct about what the issue is likely to be, the problem might >> actually be ‘worse’ in 1.3-dev – however unless I’m mistaken here: >> >> >> >> Unless you are saying that the INTERNAL and EXTERNAL path to mantis is >> different, it should be a case of setting $g_path to the final path: >> >> >> >> $g_path = $t_protocol . '://' . $t_host . $t_path; >> >> >> >> i.e. >> >> >> >> if you have mantis listening on http, with a loadbalancing reverse proxy >> in front running https, whilst Mantis will detect http://www.foo.com, if >> you set >> >> >> >> $g_path = https://www.foo.com in the config file that should work I >> believe. >> >> >> >> >> >> If you are saying that you use http://mantis.internal and www.foo.org >> depending on whether users are internal or external to the corporate >> network, then this might be more of an issue. >> >> >> >> Looking at the code, we seem to generate a mixture of absolute and >> relative links within a page in both 1.2 and 1.3 – the $g_path fix should >> be fine for the reverse proxy case, however, the absolute links will need >> to go to deal with the split-dns case. >> >> >> >> Paul >> >> >> >> >> >> *From:* Louis BAYLE [mailto:lba...@gm...] >> *Sent:* 18 October 2014 23:16 >> *To:* developer discussions >> *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy >> >> >> >> Yes, I can install a mantis 1.3-dev on our server and test it. >> >> I'm not sure I'll have time to do that next week, but I'll let you know. >> >> >> Louis BAYLE >> Tel: +33 (0)4.42.604.734 >> lba...@gm... >> >> >> >> On Sat, Oct 18, 2014 at 11:55 PM, Paul Richards < >> gra...@bl...> wrote: >> >> Are you able to test if the situation is any better with 1.3-dev? >> >> >> >> If this is an absolute vs relative link type issue, (which I’m guessing >> it is) I’m not sure if the situation is improved in 1.3 >> >> >> >> Paul >> >> >> >> *From:* Louis BAYLE [mailto:lba...@gm...] >> *Sent:* 18 October 2014 22:44 >> *To:* developer discussions >> *Subject:* [mantisbt-dev] Mantis not working behind a reverse-proxy >> >> >> >> Is there a 'good patch' to fix this realy problematic bug in Mantis ? >> >> The patch I applied to our installation does not work very well. >> IMHO this is realy a critical bug. >> >> >> http://www.mantisbt.org/bugs/view.php?id=13056 >> http://www.mantisbt.org/bugs/view.php?id=9333 >> >> Louis BAYLE >> Tel: +33 (0)4.42.604.734 >> lba...@gm... >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > |
|
From: Louis B. <lba...@gm...> - 2014-10-19 08:27:09
|
In deed, we have mantis listening internal on http://172.x.x.x and accessible on the external with https://88.x.x.x (the reverse-proxy). I'm fine if users access only via https, that's what I did for CodevTT. I'll try the $g_path patch asap. Louis BAYLE Tel: +33 (0)4.42.604.734 lba...@gm... On Sun, Oct 19, 2014 at 1:06 AM, P Richards <pa...@ma...> wrote: > If I’m correct about what the issue is likely to be, the problem might > actually be ‘worse’ in 1.3-dev – however unless I’m mistaken here: > > > > Unless you are saying that the INTERNAL and EXTERNAL path to mantis is > different, it should be a case of setting $g_path to the final path: > > > > $g_path = $t_protocol . '://' . $t_host . $t_path; > > > > i.e. > > > > if you have mantis listening on http, with a loadbalancing reverse proxy > in front running https, whilst Mantis will detect http://www.foo.com, if > you set > > > > $g_path = https://www.foo.com in the config file that should work I > believe. > > > > > > If you are saying that you use http://mantis.internal and www.foo.org > depending on whether users are internal or external to the corporate > network, then this might be more of an issue. > > > > Looking at the code, we seem to generate a mixture of absolute and > relative links within a page in both 1.2 and 1.3 – the $g_path fix should > be fine for the reverse proxy case, however, the absolute links will need > to go to deal with the split-dns case. > > > > Paul > > > > > > *From:* Louis BAYLE [mailto:lba...@gm...] > *Sent:* 18 October 2014 23:16 > *To:* developer discussions > *Subject:* Re: [mantisbt-dev] Mantis not working behind a reverse-proxy > > > > Yes, I can install a mantis 1.3-dev on our server and test it. > > I'm not sure I'll have time to do that next week, but I'll let you know. > > > Louis BAYLE > Tel: +33 (0)4.42.604.734 > lba...@gm... > > > > On Sat, Oct 18, 2014 at 11:55 PM, Paul Richards < > gra...@bl...> wrote: > > Are you able to test if the situation is any better with 1.3-dev? > > > > If this is an absolute vs relative link type issue, (which I’m guessing it > is) I’m not sure if the situation is improved in 1.3 > > > > Paul > > > > *From:* Louis BAYLE [mailto:lba...@gm...] > *Sent:* 18 October 2014 22:44 > *To:* developer discussions > *Subject:* [mantisbt-dev] Mantis not working behind a reverse-proxy > > > > Is there a 'good patch' to fix this realy problematic bug in Mantis ? > > The patch I applied to our installation does not work very well. > IMHO this is realy a critical bug. > > > http://www.mantisbt.org/bugs/view.php?id=13056 > http://www.mantisbt.org/bugs/view.php?id=9333 > > Louis BAYLE > Tel: +33 (0)4.42.604.734 > lba...@gm... > > > > ------------------------------------------------------------------------------ > 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 > > > > > ------------------------------------------------------------------------------ > 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 > > |
|
From: P R. <pa...@ma...> - 2014-10-18 23:29:23
|
I like your maturity. First you revert a commit that has been in a PR with no feedback for 7 days, without talking to me. Then you remove access. Paul $ git push ERROR: Permission to mantisbt/mantisbt.git denied to grangeway. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. |
132 messages has been excluded from this view by a project administrator.
