You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(14) |
Dec
(12) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(29) |
Feb
(5) |
Mar
(22) |
Apr
(3) |
May
(15) |
Jun
(27) |
Jul
(26) |
Aug
(24) |
Sep
(23) |
Oct
(19) |
Nov
(7) |
Dec
(2) |
2003 |
Jan
(81) |
Feb
(27) |
Mar
(20) |
Apr
(36) |
May
(22) |
Jun
(31) |
Jul
(25) |
Aug
(16) |
Sep
(15) |
Oct
(7) |
Nov
(17) |
Dec
(28) |
2004 |
Jan
(16) |
Feb
(51) |
Mar
(332) |
Apr
(61) |
May
(52) |
Jun
(53) |
Jul
(47) |
Aug
(26) |
Sep
(67) |
Oct
(42) |
Nov
(37) |
Dec
(37) |
2005 |
Jan
(38) |
Feb
(38) |
Mar
(58) |
Apr
(40) |
May
(19) |
Jun
(31) |
Jul
(40) |
Aug
(94) |
Sep
(8) |
Oct
(40) |
Nov
(26) |
Dec
(12) |
2006 |
Jan
(60) |
Feb
(39) |
Mar
(80) |
Apr
(38) |
May
(39) |
Jun
(33) |
Jul
(30) |
Aug
(29) |
Sep
(32) |
Oct
(26) |
Nov
(70) |
Dec
(27) |
2007 |
Jan
(47) |
Feb
(43) |
Mar
(85) |
Apr
(63) |
May
(75) |
Jun
(27) |
Jul
(26) |
Aug
(46) |
Sep
(26) |
Oct
(23) |
Nov
(15) |
Dec
(16) |
2008 |
Jan
(63) |
Feb
(55) |
Mar
(21) |
Apr
(13) |
May
(15) |
Jun
(3) |
Jul
(5) |
Aug
(17) |
Sep
(36) |
Oct
(33) |
Nov
(30) |
Dec
(18) |
2009 |
Jan
(14) |
Feb
(28) |
Mar
(72) |
Apr
(73) |
May
(53) |
Jun
(36) |
Jul
(56) |
Aug
(10) |
Sep
(19) |
Oct
(16) |
Nov
(12) |
Dec
(13) |
2010 |
Jan
(16) |
Feb
(15) |
Mar
(19) |
Apr
(42) |
May
(10) |
Jun
(6) |
Jul
(10) |
Aug
(5) |
Sep
(15) |
Oct
(10) |
Nov
(6) |
Dec
(14) |
2011 |
Jan
(10) |
Feb
(3) |
Mar
(5) |
Apr
(9) |
May
(21) |
Jun
(13) |
Jul
(4) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(7) |
Dec
(3) |
2012 |
Jan
(2) |
Feb
(7) |
Mar
(3) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(14) |
Aug
|
Sep
(3) |
Oct
|
Nov
(2) |
Dec
|
2013 |
Jan
(4) |
Feb
|
Mar
(14) |
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(5) |
Dec
|
2014 |
Jan
|
Feb
(24) |
Mar
(7) |
Apr
(3) |
May
(24) |
Jun
(15) |
Jul
(4) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(13) |
2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(15) |
Sep
|
Oct
(51) |
Nov
|
Dec
(2) |
2016 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
(2) |
Jun
(5) |
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
(6) |
Dec
|
2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(14) |
Oct
|
Nov
|
Dec
|
From: Damien R. <dr...@ma...> - 2023-09-24 13:54:47
|
It would be great if you could follow up on the discussion in the Source Integeration support thread where it belongs, instead of replying to my comment [1] in this mailing list, which makes it difficult to follow the thread for me, and nearly impossible for other readers. [1]: https://github.com/mantisbt-plugins/source-integration/issues/229#issuecomment-1729798955 On Fri, 22 Sept 2023 at 09:07, Fabian Cenedese <Cen...@in...> wrote: > > >>>Hi > >>> > >>>I'm still trying to close mantis issues by committing changes > >>>with a matching "Fixed" message. The changeset is imported > >>>but the issue is not closed. > >> > >>My memory was letting me down. Seems like we already had > >>this problem years ago and I also asked on the mailing list: > >> > >> > https://sourceforge.net/p/mantisbt/mailman/mantisbt-help/thread/20171107095422.061FD31FBDC1%40macserver.private > >> > >>Then I left a code change on github: > >> > >>https://github.com/mantisbt-plugins/source-integration/issues/229 > >> > >>I now applied the same patch to the current version in hopes > >>of getting the behavior back that we were used to. > >> > >>Is there a reason why that shouldn't be applied to the official > >>code as well? I find it misleading that the option "Bug Fixed > >>Assign To Committer" unchecked will completely disable > >>closing of issues. Right now it rather behaves like the "Enabled > >>Features" box to close issues. > > > >The current behavior is by design actually (see < > https://github.com/mantisbt-plugins/source-integration/issues/80>#80), as > documented in the code: > > > >< > https://github.com/mantisbt-plugins/source-integration/blob/e374feca48ddfce87b7d34a628dc370b01e197ba/Source/Source.API.php#L380-L382 > > > https://github.com/mantisbt-plugins/source-integration/blob/e374feca48ddfce87b7d34a628dc370b01e197ba/Source/Source.API.php#L380-L382 > > > >I did not look in detail to confirm for sure, but if I'm not mistaken > what <https://github.com/fcenedese>@fcenedese suggests would allow > resolved issues not to be assigned at all, which feels strange to me. What > do you think ? > > > >Anyway, I'll have a closer look as time allows. > > I just think that the naming of this option doesn't match its function. > Right now it just says "assign name", but unchecking it disables > issue closing completely. So it does (almost?) the same as the > feature box. I find this counter intuitive. > > If you use my code change and enable the "assign name" box by > default then you get the same behavior as it is now I think. However > disabling it allows to close an issue without changing the assignee > which is not possible right now. If that means that an issue might be > closed without a user assigned to it then so be it, that's why we > unchecked this feature. Usually we already assigned the issues > beforehand so they already have an assignee. And if the issue is > closed by a commit then it's also visible who did the commit. The > assignee does not need to be the same as the one fixing/closing > the issue. > > Of course you can keep the current behavior but then at least you > need to change the wording of the check box as it definitely doesn't > describe its function right now. And we'd still keep our local mantis > patched to get the desired functionality. But looking at the comments > in the issues and mailing lists we're not the only ones struggling > with this. > > Thanks > > bye Fabi > > > > _______________________________________________ > mantisbt-help mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-help > |
From: Fabian C. <Cen...@in...> - 2023-09-22 07:07:34
|
>>>Hi >>> >>>I'm still trying to close mantis issues by committing changes >>>with a matching "Fixed" message. The changeset is imported >>>but the issue is not closed. >> >>My memory was letting me down. Seems like we already had >>this problem years ago and I also asked on the mailing list: >> >>https://sourceforge.net/p/mantisbt/mailman/mantisbt-help/thread/20171107095422.061FD31FBDC1%40macserver.private >> >>Then I left a code change on github: >> >>https://github.com/mantisbt-plugins/source-integration/issues/229 >> >>I now applied the same patch to the current version in hopes >>of getting the behavior back that we were used to. >> >>Is there a reason why that shouldn't be applied to the official >>code as well? I find it misleading that the option "Bug Fixed >>Assign To Committer" unchecked will completely disable >>closing of issues. Right now it rather behaves like the "Enabled >>Features" box to close issues. > >The current behavior is by design actually (see <https://github.com/mantisbt-plugins/source-integration/issues/80>#80), as documented in the code: > ><https://github.com/mantisbt-plugins/source-integration/blob/e374feca48ddfce87b7d34a628dc370b01e197ba/Source/Source.API.php#L380-L382>https://github.com/mantisbt-plugins/source-integration/blob/e374feca48ddfce87b7d34a628dc370b01e197ba/Source/Source.API.php#L380-L382 > >I did not look in detail to confirm for sure, but if I'm not mistaken what <https://github.com/fcenedese>@fcenedese suggests would allow resolved issues not to be assigned at all, which feels strange to me. What do you think ? > >Anyway, I'll have a closer look as time allows. I just think that the naming of this option doesn't match its function. Right now it just says "assign name", but unchecking it disables issue closing completely. So it does (almost?) the same as the feature box. I find this counter intuitive. If you use my code change and enable the "assign name" box by default then you get the same behavior as it is now I think. However disabling it allows to close an issue without changing the assignee which is not possible right now. If that means that an issue might be closed without a user assigned to it then so be it, that's why we unchecked this feature. Usually we already assigned the issues beforehand so they already have an assignee. And if the issue is closed by a commit then it's also visible who did the commit. The assignee does not need to be the same as the one fixing/closing the issue. Of course you can keep the current behavior but then at least you need to change the wording of the check box as it definitely doesn't describe its function right now. And we'd still keep our local mantis patched to get the desired functionality. But looking at the comments in the issues and mailing lists we're not the only ones struggling with this. Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2023-09-21 07:09:10
|
At 14:58 20.09.2023, you wrote: >Hi > >I'm still trying to close mantis issues by committing changes >with a matching "Fixed" message. The changeset is imported >but the issue is not closed. My memory was letting me down. Seems like we already had this problem years ago and I also asked on the mailing list: https://sourceforge.net/p/mantisbt/mailman/mantisbt-help/thread/20171107095422.061FD31FBDC1%40macserver.private Then I left a code change on github: https://github.com/mantisbt-plugins/source-integration/issues/229 I now applied the same patch to the current version in hopes of getting the behavior back that we were used to. Is there a reason why that shouldn't be applied to the official code as well? I find it misleading that the option "Bug Fixed Assign To Committer" unchecked will completely disable closing of issues. Right now it rather behaves like the "Enabled Features" box to close issues. Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2023-09-20 12:59:16
|
Hi I'm still trying to close mantis issues by committing changes with a matching "Fixed" message. The changeset is imported but the issue is not closed. This is the "Resolved Issues references RegEx (Pass 1)": /\bfix(?:ed|es|)\s+(?:bug|issue)?\s*#(\d+)/i The commit message starts with: "! Fix #2252: Bla bla." Checking with https://regex101.com/ The regex does match the commit message. The changeset is added as "Related Changesets" to issue 2252, with "Affected Issues 2252". But it is still open. Where can I look to see what's going on, why this issue (and any other) is not closed? Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2023-09-15 07:09:44
|
At 18:23 14.09.2023, you wrote: >If you have a correctly setup and working Source Integration plugin, then you should be all set. > >For the record, the legacy source_* configs were already obsolete in 1.3.0 (see <https://mantisbt.org/bugs/view.php?id=11732>https://mantisbt.org/bugs/view.php?id=11732). What about top_include_page? It doesn't seem to make a difference as there's no icon on top anyway. Even without include_page or logo_image set the mantis logo doesn't show up (on top). I also tried logo_image but that wasn't shown either. >As for automatic resolution of issues, this is controlled by an option in the Source Integration plugin's config (Resolve Fixed Issues). I think it should work also when importing changesets initially, but to be honest I am not really sure... I would have to look at the plugin's source code to confirm, but don't have time for that at the moment. Also keep in mind that the source integration plugin has 2 distinct regex, one for identifying issues and one for resolving them. I know, we've been using them for years with the old installation. The option is also enabled. I'll try to find out what happens next time somebody commits a "Fixed" message. Thanks bye Fabi |
From: Damien R. <dr...@ma...> - 2023-09-14 16:24:21
|
If you have a correctly setup and working Source Integration plugin, then you should be all set. For the record, the legacy source_* configs were already obsolete in 1.3.0 (see https://mantisbt.org/bugs/view.php?id=11732). As for automatic resolution of issues, this is controlled by an option in the Source Integration plugin's config (Resolve Fixed Issues). I think it should work also when importing changesets initially, but to be honest I am not really sure... I would have to look at the plugin's source code to confirm, but don't have time for that at the moment. Also keep in mind that the source integration plugin has 2 distinct regex, one for identifying issues and one for resolving them. On Thu, 14 Sept 2023 at 17:19, Fabian Cenedese <Cen...@in...> wrote: > Hello > > After an update from 1.3.11 to current version (including current > Source* plugins) I get some warnings in the admin/check page, > probably because I just copied over the config files: > > The configuration option source_control_notes_view_status is now obsolete > The configuration option source_control_account is now obsolete > The configuration option source_control_set_status_to is now obsolete > The configuration option source_control_regexp is now obsolete > The configuration option source_control_fixed_regexp is now obsolete > The configuration option status_percentage_legend is now obsolete > The configuration option inline_file_exts is now obsolete > > Can these options just be removed? Or would the information need > to be entered in some other place? I couldn't find information on > https://github.com/mantisbt-plugins/source-integration/ (or other > places). > > And a follow-up question: Should closing of issues with the #Fixed > regexp just work with importing changesets? The commit messages > are added to the mentioned issues but the issues are not closed > (neither status nor resolution is changed). Is this related to the > warnings above? Is it necessary to call ...?page=Source/checkin? > > Thanks > > bye Fabi > > > > _______________________________________________ > mantisbt-help mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-help > |
From: Fabian C. <Cen...@in...> - 2023-09-14 15:19:21
|
Hello After an update from 1.3.11 to current version (including current Source* plugins) I get some warnings in the admin/check page, probably because I just copied over the config files: The configuration option source_control_notes_view_status is now obsolete The configuration option source_control_account is now obsolete The configuration option source_control_set_status_to is now obsolete The configuration option source_control_regexp is now obsolete The configuration option source_control_fixed_regexp is now obsolete The configuration option status_percentage_legend is now obsolete The configuration option inline_file_exts is now obsolete Can these options just be removed? Or would the information need to be entered in some other place? I couldn't find information on https://github.com/mantisbt-plugins/source-integration/ (or other places). And a follow-up question: Should closing of issues with the #Fixed regexp just work with importing changesets? The commit messages are added to the mentioned issues but the issues are not closed (neither status nor resolution is changed). Is this related to the warnings above? Is it necessary to call ...?page=Source/checkin? Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2023-09-05 06:22:01
|
At 18:11 04.09.2023, you wrote: >Le lun. 4 sept. 2023 à 17:33, Fabian Cenedese <<mailto:Cen...@in...>Cen...@in...> a écrit½ : >Yes, renaming fonts/.htaccess seems to have worked as well. > > >Sorry, what do you mean "renaming" ? > >I was expecting you to *delete* the file.. I like to keep files in case I need them again as in "it didn't work". But renaming it to something the server doesn't know had the same effect, the icons showed up again. So depending on how old the systems you need to support you can also remove the file. bye Fabi |
From: Damien R. <dr...@ma...> - 2023-09-04 16:11:55
|
Le lun. 4 sept. 2023 à 17:33, Fabian Cenedese <Cen...@in...> a écrit : > Yes, renaming fonts/.htaccess seems to have worked as well. Sorry, what do you mean "renaming" ? I was expecting you to *delete* the file.. |
From: Fabian C. <Cen...@in...> - 2023-09-04 15:33:38
|
Hi Yes, renaming fonts/.htaccess seems to have worked as well. I'm on Ubuntu 22.04.3. bye Fabi At 16:43 04.09.2023, you wrote: >Hey > >I had a closer look at this, and the AddType directives in the .htaccess file were added back in 2015, for IE 9/10 compatibility with Fontawesome. > >Since that time, RFC8081 standardized font mime types, font/woff and font/woff2 deprecated previous usages such as application/font-woff and application/octet-stream. > >Maybe we could get rid of this .htaccess file, as the standard font types should normally be declared by default in the web server's config nowadays (e.g. For Apache on Ubuntu 22.04 TypesConfig /etc/mime.types). > >Could you please try if things work (i.e. You see the icons) without the .htaccess file? > >Thanks > >Le lun. 4 sept. 2023 à 15:24, Damien Regad <<mailto:dr...@ma...>dr...@ma...> a écrit : >You are getting HTTP 500 errors, so you need to check the web server error logs for more information.½ > >Most likely a problem with the web server's config. > >Damien > >PS you should remove the admin directory... > >Le lun. 4 sept. 2023 à 09:48, Fabian Cenedese <<mailto:Cen...@in...>Cen...@in...> a écrit : >Hello > >I just upgraded an old 1.3.11 installation to the current 2.25.7. >I untarred it to a new location and copied the plugins (Source, >SourceGitlab, SourceSVN) over. The admin/install page worked >without error. > >Everything seems to work so far except that there are errors >with regards to fonts. And this also leads to missing icons. >However the font files are all present and accessible. What >could be the reason for this? > >[] > > >/var/www/public/mantisbt-2.25.7/fonts$ ls -la >-rw-r--r-- 1 www-data www-data 165742 Apr 12 00:55 fontawesome-webfont.eot >-rw-r--r-- 1 www-data www-data 444379 Apr 12 00:55 fontawesome-webfont.svg >-rw-r--r-- 1 www-data www-data 165548 Apr 12 00:55 fontawesome-webfont.ttf >-rw-r--r-- 1 www-data www-data 98024 Apr 12 00:55 fontawesome-webfont.woff >-rw-r--r-- 1 www-data www-data 77160 Apr 12 00:55 fontawesome-webfont.woff2 >etc > >Thanks > >bye Fabi >_______________________________________________ >mantisbt-help mailing list ><mailto:man...@li...>man...@li... >https://lists.sourceforge.net/lists/listinfo/mantisbt-help > > >_______________________________________________ >mantisbt-help mailing list >man...@li... >https://lists.sourceforge.net/lists/listinfo/mantisbt-help |
From: Damien R. <dr...@ma...> - 2023-09-04 14:43:56
|
Hey I had a closer look at this, and the AddType directives in the .htaccess file were added back in 2015, for IE 9/10 compatibility with Fontawesome. Since that time, RFC8081 standardized font mime types, font/woff and font/woff2 deprecated previous usages such as application/font-woff and application/octet-stream. Maybe we could get rid of this .htaccess file, as the standard font types should normally be declared by default in the web server's config nowadays (e.g. For Apache on Ubuntu 22.04 TypesConfig /etc/mime.types). Could you please try if things work (i.e. You see the icons) without the .htaccess file? Thanks Le lun. 4 sept. 2023 à 15:24, Damien Regad <dr...@ma...> a écrit : > You are getting HTTP 500 errors, so you need to check the web server error > logs for more information. > > Most likely a problem with the web server's config. > > Damien > > PS you should remove the admin directory... > > Le lun. 4 sept. 2023 à 09:48, Fabian Cenedese <Cen...@in...> a > écrit : > >> Hello >> >> I just upgraded an old 1.3.11 installation to the current 2.25.7. >> I untarred it to a new location and copied the plugins (Source, >> SourceGitlab, SourceSVN) over. The admin/install page worked >> without error. >> >> Everything seems to work so far except that there are errors >> with regards to fonts. And this also leads to missing icons. >> However the font files are all present and accessible. What >> could be the reason for this? >> >> [] >> >> >> /var/www/public/mantisbt-2.25.7/fonts$ ls -la >> -rw-r--r-- 1 www-data www-data 165742 Apr 12 00:55 >> fontawesome-webfont.eot >> -rw-r--r-- 1 www-data www-data 444379 Apr 12 00:55 >> fontawesome-webfont.svg >> -rw-r--r-- 1 www-data www-data 165548 Apr 12 00:55 >> fontawesome-webfont.ttf >> -rw-r--r-- 1 www-data www-data 98024 Apr 12 00:55 >> fontawesome-webfont.woff >> -rw-r--r-- 1 www-data www-data 77160 Apr 12 00:55 >> fontawesome-webfont.woff2 >> etc >> >> Thanks >> >> bye Fabi >> _______________________________________________ >> mantisbt-help mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-help >> > |
From: Damien R. <dr...@ma...> - 2023-09-04 13:25:15
|
You are getting HTTP 500 errors, so you need to check the web server error logs for more information. Most likely a problem with the web server's config. Damien PS you should remove the admin directory... Le lun. 4 sept. 2023 à 09:48, Fabian Cenedese <Cen...@in...> a écrit : > Hello > > I just upgraded an old 1.3.11 installation to the current 2.25.7. > I untarred it to a new location and copied the plugins (Source, > SourceGitlab, SourceSVN) over. The admin/install page worked > without error. > > Everything seems to work so far except that there are errors > with regards to fonts. And this also leads to missing icons. > However the font files are all present and accessible. What > could be the reason for this? > > [] > > > /var/www/public/mantisbt-2.25.7/fonts$ ls -la > -rw-r--r-- 1 www-data www-data 165742 Apr 12 00:55 fontawesome-webfont.eot > -rw-r--r-- 1 www-data www-data 444379 Apr 12 00:55 fontawesome-webfont.svg > -rw-r--r-- 1 www-data www-data 165548 Apr 12 00:55 fontawesome-webfont.ttf > -rw-r--r-- 1 www-data www-data 98024 Apr 12 00:55 > fontawesome-webfont.woff > -rw-r--r-- 1 www-data www-data 77160 Apr 12 00:55 > fontawesome-webfont.woff2 > etc > > Thanks > > bye Fabi > _______________________________________________ > mantisbt-help mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-help > |
From: Fabian C. <Cen...@in...> - 2023-09-04 12:58:55
|
At 09:48 04.09.2023, Fabian Cenedese wrote: >Hello > >Everything seems to work so far except that there are errors >with regards to fonts. And this also leads to missing icons. >However the font files are all present and accessible. What >could be the reason for this? I guess I can also bring the solution after solving it myself. The fonts/.htaccess file wants to use AddType for some font files. This in itself needs permission from the webserver (Apache2). Therefore an AllowOverride was necessary for the mantis page. Maybe this helps other people. bye Fabi |
From: Fabian C. <Cen...@in...> - 2023-09-04 08:02:51
|
Hello I just upgraded an old 1.3.11 installation to the current 2.25.7. I untarred it to a new location and copied the plugins (Source, SourceGitlab, SourceSVN) over. The admin/install page worked without error. Everything seems to work so far except that there are errors with regards to fonts. And this also leads to missing icons. However the font files are all present and accessible. What could be the reason for this? [] /var/www/public/mantisbt-2.25.7/fonts$ ls -la -rw-r--r-- 1 www-data www-data 165742 Apr 12 00:55 fontawesome-webfont.eot -rw-r--r-- 1 www-data www-data 444379 Apr 12 00:55 fontawesome-webfont.svg -rw-r--r-- 1 www-data www-data 165548 Apr 12 00:55 fontawesome-webfont.ttf -rw-r--r-- 1 www-data www-data 98024 Apr 12 00:55 fontawesome-webfont.woff -rw-r--r-- 1 www-data www-data 77160 Apr 12 00:55 fontawesome-webfont.woff2 etc Thanks bye Fabi |
From: KM <in...@ya...> - 2020-06-22 18:18:22
|
I neglected to mention that i don't necessarily need everything that is blue, to be maroon. I think at least the headings bars maybe. Thanks again. KM On Monday, June 22, 2020, 01:38:18 PM EDT, KM via mantisbt-help <man...@li...> wrote: Hi All, I recently installed Mantis 2.24.1. I was easily able to change our logo etc., but wanted to change the default blue color theme to maroon. I did try searching but did not find any exact information to help me. I assume it has something to do with the css directory/files. I apologize in advance if there is info somewhere that I missed. Can anyone let me know how to change the bars on the pages from blue to maroon? Thanks in advance. KM _______________________________________________ mantisbt-help mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-help |
From: KM <in...@ya...> - 2020-06-22 17:38:14
|
Hi All, I recently installed Mantis 2.24.1. I was easily able to change our logo etc., but wanted to change the default blue color theme to maroon. I did try searching but did not find any exact information to help me. I assume it has something to do with the css directory/files. I apologize in advance if there is info somewhere that I missed. Can anyone let me know how to change the bars on the pages from blue to maroon? Thanks in advance. KM |
From: Roland B. <ro...@at...> - 2018-01-26 14:15:38
|
Looks good, should work. > Fabian Cenedese <Cen...@in...> hat am 26. Januar 2018 um 14:44 geschrieben: > > > At 13:17 26.01.2018, Fabian Cenedese wrote: > >Hi > > > >I wanted to change the access level of a user. But the > >Manage Users page always returned an error that the > >email already exists. Of course, it was used by this user > >that I wanted to change. After different tries to solve this > >I finally just deleted the user and recreated it with the > >desired settings. Unfortunately all bugs that were entered > >with the previous account now only show up with user11. > >Even with the same name the new user is not the same > >as the old. Is there a way to change the id or whatever is > >used for unique identification to the previous user account? > > I now changed the user id with these commands: > > # start mysql to access the database, take password from mantis setup description > >mysql -uroot -pPassword > # start working with the mantis database > USE mantis; > # show the content of the user table > SELECT * FROM mantis_user_table; > # change the id of the new user > UPDATE mantis_user_table SET id=OldId WHERE id=NewId; > # check that id was changed > SELECT * FROM mantis_user_table; > # and we're done > EXIT > > Anything bad to expect from here? Can't be worse than > not finding the new user anymore as happened with the > old user before. > > Thanks > > bye Fabi > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mantisbt-help mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-help |
From: Fabian C. <Cen...@in...> - 2018-01-26 13:44:15
|
At 13:17 26.01.2018, Fabian Cenedese wrote: >Hi > >I wanted to change the access level of a user. But the >Manage Users page always returned an error that the >email already exists. Of course, it was used by this user >that I wanted to change. After different tries to solve this >I finally just deleted the user and recreated it with the >desired settings. Unfortunately all bugs that were entered >with the previous account now only show up with user11. >Even with the same name the new user is not the same >as the old. Is there a way to change the id or whatever is >used for unique identification to the previous user account? I now changed the user id with these commands: # start mysql to access the database, take password from mantis setup description >mysql -uroot -pPassword # start working with the mantis database USE mantis; # show the content of the user table SELECT * FROM mantis_user_table; # change the id of the new user UPDATE mantis_user_table SET id=OldId WHERE id=NewId; # check that id was changed SELECT * FROM mantis_user_table; # and we're done EXIT Anything bad to expect from here? Can't be worse than not finding the new user anymore as happened with the old user before. Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2018-01-26 12:48:57
|
Hi I wanted to change the access level of a user. But the Manage Users page always returned an error that the email already exists. Of course, it was used by this user that I wanted to change. After different tries to solve this I finally just deleted the user and recreated it with the desired settings. Unfortunately all bugs that were entered with the previous account now only show up with user11. Even with the same name the new user is not the same as the old. Is there a way to change the id or whatever is used for unique identification to the previous user account? Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2017-11-14 08:18:08
|
>Hello Fabian > >Sorry I hardly follow this mailing list anymore since there is so little >traffic on it. I suggest you head to GitHub for source integration plug-in >support. > >https://github.com/mantisbt-plugins/source-integration > >Feel free to open a new issue if you feel the plug-ins behavior is >incorrect. Okay, I added a comment to this issue which talks about the same settings and probably is the same problem https://github.com/mantisbt-plugins/source-integration/issues/229 bye Fabi |
From: Damien R. <dr...@ma...> - 2017-11-13 14:40:49
|
Fabian Cenedese <Cen...@in...> wrote: > >> i added some debug code to see what's going on. I found out >> that Source.API.php checks for PVM and skips the closing >> if this is not available and enabled. PVM is the product-version- >> matrix plugin. Why is this needed? Can't I just close bugs in >> mantis without this plugin? Is it enough to just install and enable >> it or does it have more dependencies? Does it need configuration >> if I don't use it? > > Even though I'm only talking to myself here: I think I now found > the real problem, nothing to do with PVM. There's a setting stored > in the database under 'plugin_Source_bugfix_handler'. In the config > page this is the option 'Bug Fixed Assign To Committer'. I unchecked > this because I didn't want to change any data in the bug, I only want > it to be closed if the commit message contains 'Fixed #...' That's when > the automatic closing stopped. > > In Source.API.php this variable is checked if it is set. > > $t_handler = config_get( 'plugin_Source_bugfix_handler' ); > if ( Source_PVM() ) { > ... > } elseif( $t_handler && $t_handler_id !== null ) { > ...close bug > } > > So it seems that auto closing is not possible if this setting is not > enabled. As I don't want to change the handler in the bug I will either > skip the check for the setting or disable the code to change the bug > handler. I find it wrong to disable closing completely if this handler > is not set in the config. And it looks like the current code in git is > still the same. > > Are there reasons to do it like that? Am I missing something? Hello Fabian Sorry I hardly follow this mailing list anymore since there is so little traffic on it. I suggest you head to GitHub for source integration plug-in support. https://github.com/mantisbt-plugins/source-integration Feel free to open a new issue if you feel the plug-ins behavior is incorrect. |
From: Fabian C. <Cen...@in...> - 2017-11-13 11:57:35
|
>i added some debug code to see what's going on. I found out >that Source.API.php checks for PVM and skips the closing >if this is not available and enabled. PVM is the product-version- >matrix plugin. Why is this needed? Can't I just close bugs in >mantis without this plugin? Is it enough to just install and enable >it or does it have more dependencies? Does it need configuration >if I don't use it? Even though I'm only talking to myself here: I think I now found the real problem, nothing to do with PVM. There's a setting stored in the database under 'plugin_Source_bugfix_handler'. In the config page this is the option 'Bug Fixed Assign To Committer'. I unchecked this because I didn't want to change any data in the bug, I only want it to be closed if the commit message contains 'Fixed #...' That's when the automatic closing stopped. In Source.API.php this variable is checked if it is set. $t_handler = config_get( 'plugin_Source_bugfix_handler' ); if ( Source_PVM() ) { ... } elseif( $t_handler && $t_handler_id !== null ) { ...close bug } So it seems that auto closing is not possible if this setting is not enabled. As I don't want to change the handler in the bug I will either skip the check for the setting or disable the code to change the bug handler. I find it wrong to disable closing completely if this handler is not set in the config. And it looks like the current code in git is still the same. Are there reasons to do it like that? Am I missing something? Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2017-11-13 07:33:10
|
At 12:29 09.11.2017, you wrote: >At 10:54 07.11.2017, you wrote: >>Hi >> >>I'm still using the old 1.3 version with the SourceControl >>plugin. I'm having a problem that someone might know >>what's going on. >> >>I have repositories configured, they have a hook, upon >>a commit the SourceControl is called and the changesets >>are imported, so far so good. >>However the closing of bugs mentioned in the commit >>message does not work. The number is parsed and >>the changeset is added so the RegEx and the text are >>fine. I also get the commit message and mail with the >>"Bug Fixed Message" setting. I also have the "Resolve >>Fixed Issues" checked and "Bug Fixed Status"=closed >>and "Bug Fixed Resolution"=fixed. The RegExes are >>all on default, the message is "! Fixed #1234: ..." >>After committing and getting the mail I check the issue >>in Mantis and it is still open/confirmed. >> >>What else can go wrong or could I check to make it work? > >How can I debug this myself? What LogLevels are used in >the SourceControl plugin? i added some debug code to see what's going on. I found out that Source.API.php checks for PVM and skips the closing if this is not available and enabled. PVM is the product-version- matrix plugin. Why is this needed? Can't I just close bugs in mantis without this plugin? Is it enough to just install and enable it or does it have more dependencies? Does it need configuration if I don't use it? Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2017-11-09 11:29:30
|
At 10:54 07.11.2017, you wrote: >Hi > >I'm still using the old 1.3 version with the SourceControl >plugin. I'm having a problem that someone might know >what's going on. > >I have repositories configured, they have a hook, upon >a commit the SourceControl is called and the changesets >are imported, so far so good. >However the closing of bugs mentioned in the commit >message does not work. The number is parsed and >the changeset is added so the RegEx and the text are >fine. I also get the commit message and mail with the >"Bug Fixed Message" setting. I also have the "Resolve >Fixed Issues" checked and "Bug Fixed Status"=closed >and "Bug Fixed Resolution"=fixed. The RegExes are >all on default, the message is "! Fixed #1234: ..." >After committing and getting the mail I check the issue >in Mantis and it is still open/confirmed. > >What else can go wrong or could I check to make it work? How can I debug this myself? What LogLevels are used in the SourceControl plugin? Thanks bye Fabi |
From: Fabian C. <Cen...@in...> - 2017-11-07 10:07:06
|
Hi I'm still using the old 1.3 version with the SourceControl plugin. I'm having a problem that someone might know what's going on. I have repositories configured, they have a hook, upon a commit the SourceControl is called and the changesets are imported, so far so good. However the closing of bugs mentioned in the commit message does not work. The number is parsed and the changeset is added so the RegEx and the text are fine. I also get the commit message and mail with the "Bug Fixed Message" setting. I also have the "Resolve Fixed Issues" checked and "Bug Fixed Status"=closed and "Bug Fixed Resolution"=fixed. The RegExes are all on default, the message is "! Fixed #1234: ..." After committing and getting the mail I check the issue in Mantis and it is still open/confirmed. What else can go wrong or could I check to make it work? Thanks bye Fabi |