From: smig1o Gazeta.p. <sm...@ga...> - 2010-04-20 09:29:19
|
Hi ther I've got a question. Is assigning bug to a developer a part of bug updating? Is there any signal emited befora/after bug assign? -- Piotr Szmigielski Poznań 'Press any key to continue or any other key to quit' Reply To: sm...@ga... ICQ# 236063520 GG# 1950736 Jabber# sm...@ja... |
From: Pablo P. <pab...@ju...> - 2010-04-20 09:36:46
|
El 20/04/2010 11:02, smig1o Gazeta.pl escribió: > Hi ther > > I've got a question. Is assigning bug to a developer a part of bug > updating? Is there any signal emited befora/after bug assign? > > Hi, I could´t find any signal in that moment, only before/after UPDATE, when you assign a bug, if you find a solution let me know it. |
From: smig1o Gazeta.p. <sm...@ga...> - 2010-04-20 09:54:04
|
W dniu 20 kwietnia 2010 11:36 użytkownik Pablo Pedrosa <pab...@ju...> napisał: > El 20/04/2010 11:02, smig1o Gazeta.pl escribió: >> Hi ther >> >> I've got a question. Is assigning bug to a developer a part of bug >> updating? Is there any signal emited befora/after bug assign? >> >> > Hi, I could´t find any signal in that moment, only before/after UPDATE, > when you assign a bug, if you find a solution let me know it. Seems I'll be forced to modify bug_update function to handle that. I see no other solution atm. -- Piotr Szmigielski Poznań 'Press any key to continue or any other key to quit' Reply To: sm...@ga... ICQ# 236063520 GG# 1950736 Jabber# sm...@ja... |
From: David H. <hic...@op...> - 2010-04-22 07:06:38
|
On Tue, 2010-04-20 at 11:53 +0200, smig1o Gazeta.pl wrote: > Seems I'll be forced to modify bug_update function to handle that. I > see no other solution atm. Please consider filing a bug report on the MantisBT bug tracker if one doesn't already exist. We may need to consider adding another hook that plugins can use before/after a bug is reassigned. However I'm of the opinion that we really should be passing all modifications to a bug through the same process. In other words, we create an interface which accepts a list of proposed changes to a bug. This interface would then be responsible for determining whether the changes can succeed. The reason for bundling changes to different fields together when performing validation is to allow for complex rules about the state of issue metadata. For instance you could make a rule that states the priority of an issue cannot be set above HIGH if the severity is below MAJOR. Thus we'd only need two hooks... one prior to updating a bug and one after a bug has been updated. The alternative (when not bundling updates together through the same interface) is a mess of dozens of hooks before/after a whole number of events like: bug_assign, bug_resolve, bug_close, etc. Regards, David |
From: smig1o Gazeta.p. <sm...@ga...> - 2010-04-22 13:05:59
|
2010/4/22 David Hicks <hic...@op...>: > On Tue, 2010-04-20 at 11:53 +0200, smig1o Gazeta.pl wrote: >> Seems I'll be forced to modify bug_update function to handle that. I >> see no other solution atm. > > Please consider filing a bug report on the MantisBT bug tracker if one > doesn't already exist. We may need to consider adding another hook that > plugins can use before/after a bug is reassigned. > > However I'm of the opinion that we really should be passing all > modifications to a bug through the same process. In other words, we > create an interface which accepts a list of proposed changes to a bug. > This interface would then be responsible for determining whether the > changes can succeed. The reason for bundling changes to different fields > together when performing validation is to allow for complex rules about > the state of issue metadata. For instance you could make a rule that > states the priority of an issue cannot be set above HIGH if the severity > is below MAJOR. > > Thus we'd only need two hooks... one prior to updating a bug and one > after a bug has been updated. The alternative (when not bundling updates > together through the same interface) is a mess of dozens of hooks > before/after a whole number of events like: bug_assign, bug_resolve, > bug_close, etc. > > Regards, > > David On the bug view page there are several buttons like: Edit, Assign To, change status to, etc. The problem is that by pressing >Assign To< bug_assign function is called, not bug_change. And yes, it would be nice to have one single path on each bug data change. I also wasnt able to find EVENT_MENU_MANAGE_CONFIG event call. So I'll submit two bugs then. Regards -- Piotr Szmigielski Poznań 'Press any key to continue or any other key to quit' Reply To: sm...@ga... ICQ# 236063520 GG# 1950736 Jabber# sm...@ja... |
From: John R. <jr...@le...> - 2010-04-22 17:59:49
|
I've written a basic "fix" for the issue, which involves replacing the call to bug_assign with the logic from bug_assign followed by the event signal and a call to bug->update(). I'm not sure that I feel this is the best solution though, so I would like some feedback on it. The commit is on my proposal repo: http://git.mantisforge.org/w/mantisbt/jreese.git?a=commit;h=d8b656e8ba432c7294a9b4143050f761f5e60474 Cheers -- John Reese LeetCode.net |
From: smig1o Gazeta.p. <sm...@ga...> - 2010-04-22 18:31:28
|
2010/4/22 John Reese <jr...@le...>: > I've written a basic "fix" for the issue, which involves replacing the call to > bug_assign with the logic from bug_assign followed by the event signal and a > call to bug->update(). I'm not sure that I feel this is the best solution > though, so I would like some feedback on it. The commit is on my proposal repo: > > http://git.mantisforge.org/w/mantisbt/jreese.git?a=commit;h=d8b656e8ba432c7294a9b4143050f761f5e60474 > > Cheers I put task list functionality into Mantis 1.1.1. The difference between bug and task is that tasks have strict order. Since Mantis 1.1.1 was one big program I had to heavily modify its core and some GUI functions. Now I have plugins system and my boss wants me tu upgrade to ver 1.2. So I have to rewrite this task functions as a plugin. Should I wait for 1.2.1 or fetch a patch you made for this? Regards -- Piotr Szmigielski Poznań 'Press any key to continue or any other key to quit' Reply To: sm...@ga... ICQ# 236063520 GG# 1950736 Jabber# sm...@ja... |
From: Pablo P. <pab...@ju...> - 2010-04-23 09:48:23
|
Is there any posibility to install mantis 1.2 with Oracle 10XE?, I´m trying to do that with no success at all, if anyone have any guide or something i can read, it would be perfect. Thanks Pablo |