Re: Closing issues with commit message
Damien Regad <[email protected]> Sun, 24 Sep 2023 15:54:19 +0200
| Newsgroups | gmane.comp.bug-tracking.mantis.general |
|---|---|
| Message-ID | <CA+zp4VP_2Pwbcx9QXfyGjBKXPLspJyjz8ngVsecNv+5FzLygOA@mail.gmail.com> |
--===============7508482805069639328== Content-Type: multipart/alternative; boundary="0000000000005f8a8506061b2e1b" --0000000000005f8a8506061b2e1b Content-Type: text/plain; charset="UTF-8" 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 <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/mantisbt-help > --0000000000005f8a8506061b2e1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">It would be great if you could follow up = on the discussion in the=C2=A0Source Integeration=C2=A0support thread where= it belongs, instead of replying to my comment [1] in this mailing list, wh= ich makes it difficult to follow the thread for me, and nearly impossible f= or other readers.<div><br></div><div>[1]:=C2=A0<a href=3D"https://github.co= m/mantisbt-plugins/source-integration/issues/229#issuecomment-1729798955" t= arget=3D"_blank">https://github.com/mantisbt-plugins/source-integration/iss= ues/229#issuecomment-1729798955</a></div></div><div class=3D"gmail-yj6qo gm= ail-ajU" style=3D"outline:currentcolor;padding:10px 0px;width:22px;margin:2= px 0px 0px"></div><br class=3D"gmail-Apple-interchange-newline"></div><br><= div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 22 = Sept 2023 at 09:07, Fabian Cenedese <<a href=3D"mailto:[email protected]= ">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl= e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br> >>>Hi<br> >>><br> >>>I'm still trying to close mantis issues by committing chang= es<br> >>>with a matching "Fixed" message. The changeset is imp= orted<br> >>>but the issue is not closed.<br> >><br> >>My memory was letting me down. Seems like we already had<br> >>this problem years ago and I also asked on the mailing list:<br> >><br> >><a href=3D"https://sourceforge.net/p/mantisbt/mailman/mantisbt-help= /thread/20171107095422.061FD31FBDC1%40macserver.private" rel=3D"noreferrer"= target=3D"_blank">https://sourceforge.net/p/mantisbt/mailman/mantisbt-help= /thread/20171107095422.061FD31FBDC1%40macserver.private</a><br> >><br> >>Then I left a code change on github:<br> >><br> >><a href=3D"https://github.com/mantisbt-plugins/source-integration/i= ssues/229" rel=3D"noreferrer" target=3D"_blank">https://github.com/mantisbt= -plugins/source-integration/issues/229</a><br> >><br> >>I now applied the same patch to the current version in hopes<br> >>of getting the behavior back that we were used to.<br> >><br> >>Is there a=C2=A0 reason why that shouldn't be applied to the of= ficial<br> >>code as well? I find it misleading that the option "Bug Fixed<= br> >>Assign To Committer" unchecked will completely disable<br> >>closing of issues. Right now it rather behaves like the "Enabl= ed<br> >>Features" box to close issues.<br> ><br> >The current behavior is by design actually (see <<a href=3D"https://= github.com/mantisbt-plugins/source-integration/issues/80" rel=3D"noreferrer= " target=3D"_blank">https://github.com/mantisbt-plugins/source-integration/= issues/80</a>>#80), as documented in the code:<br> ><br> ><<a href=3D"https://github.com/mantisbt-plugins/source-integration/b= lob/e374feca48ddfce87b7d34a628dc370b01e197ba/Source/Source.API.php#L380-L38= 2" rel=3D"noreferrer" target=3D"_blank">https://github.com/mantisbt-plugins= /source-integration/blob/e374feca48ddfce87b7d34a628dc370b01e197ba/Source/So= urce.API.php#L380-L382</a>><a href=3D"https://github.com/mantisbt-plugin= s/source-integration/blob/e374feca48ddfce87b7d34a628dc370b01e197ba/Source/S= ource.API.php#L380-L382" rel=3D"noreferrer" target=3D"_blank">https://githu= b.com/mantisbt-plugins/source-integration/blob/e374feca48ddfce87b7d34a628dc= 370b01e197ba/Source/Source.API.php#L380-L382</a><br> ><br> >I did not look in detail to confirm for sure, but if I'm not mistak= en what <<a href=3D"https://github.com/fcenedese" rel=3D"noreferrer" tar= get=3D"_blank">https://github.com/fcenedese</a>>@fcenedese suggests woul= d allow resolved issues not to be assigned at all, which feels strange to m= e. What do you think ?<br> ><br> >Anyway, I'll have a closer look as time allows.<br> <br> I just think that the naming of this option doesn't match its function.= <br> Right now it just says "assign name", but unchecking it disables<= br> issue closing completely. So it does (almost?) the same as the<br> feature box. I find this counter intuitive.<br> <br> If you use my code change and enable the "assign name" box by<br> default then you get the same behavior as it is now I think. However<br> disabling it allows to close an issue without changing the assignee<br> which is not possible right now. If that means that an issue might be<br> closed without a user assigned to it then so be it, that's why we<br> unchecked this feature. Usually we already assigned the issues<br> beforehand so they already have an assignee. And if the issue is<br> closed by a commit then it's also visible who did the commit. The<br> assignee does not need to be the same as the one fixing/closing<br> the issue.<br> <br> Of course you can keep the current behavior but then at least you<br> need to change the wording of the check box as it definitely doesn't<br= > describe its function right now. And we'd still keep our local mantis<b= r> patched to get the desired functionality. But looking at the comments<br> in the issues and mailing lists we're not the only ones struggling<br> with this.<br> <br> Thanks<br> <br> bye=C2=A0 Fabi<br> <br> <br> <br> _______________________________________________<br> mantisbt-help mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">ma= [email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/mantisbt-help" rel= =3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listi= nfo/mantisbt-help</a><br> </blockquote></div> --0000000000005f8a8506061b2e1b-- --===============7508482805069639328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7508482805069639328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mantisbt-help mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mantisbt-help --===============7508482805069639328==--