The workflow used by the company enforces the following states afer assigned:
fixed => used after develpoer has fixed the issue in the code
to be tested => assigned to another developer/user to check if the fix has been succesful
resolved => assigned to the project manager after test
closed => used after the software release has been published
I need to enforce that the person changing the ticket from assigned to fixed is not the same than the person which is setting the status from to be tested to resolved
Maybe not allowing to be tested to be assigned to a person who has fixed the issue would work as well.
I did neither find any entries in the forum nor any solutions to this. Any suggestions?
How can I enforce a two-man rule for closing issues
Moderators: Developer, Contributor
Re: How can I enforce a two-man rule for closing issues
Depending on your internal structure using "Workflow Transitions" page might offer what you want.
Have a look at section "Minimum Access Level to Change to this Status" at the bottom of the page.
Have a look at section "Minimum Access Level to Change to this Status" at the bottom of the page.
Re: How can I enforce a two-man rule for closing issues
This would sadly not work, as the idea is that:
- A reporter opens a ticket.
- A developer fixes it.
- The manager assignes it to another developer or back to the reporter to test it
- The reporter or (second) developer) resolves it.
The important parts are that the person removing the bug is not the same testing that ist is removed and further allow the customer (reporter) to test a case.
The later prohibits the workflow, as the reporter has in any other case less rights than the developer. And Manits supports only more rights to higher numbers.
- A reporter opens a ticket.
- A developer fixes it.
- The manager assignes it to another developer or back to the reporter to test it
- The reporter or (second) developer) resolves it.
The important parts are that the person removing the bug is not the same testing that ist is removed and further allow the customer (reporter) to test a case.
The later prohibits the workflow, as the reporter has in any other case less rights than the developer. And Manits supports only more rights to higher numbers.
Re: How can I enforce a two-man rule for closing issues
Not true.TDS wrote:And Manits supports only more rights to higher numbers.
Have a look at this configuration example.
In this case developers and managers are able to handle an issue, administrators are not able to handle an issue.
- Attachments
-
- handleIssue.PNG (20.95 KiB) Viewed 9233 times
Re: How can I enforce a two-man rule for closing issues
You are right but this does not allow me to enforce a second person needed to resolve the ticket.
I need automatic feature (not by human check) to ensure that
The user (usually with developer rights) which has set the status from "assigned" to "fixed"
is a different one than the user which is setting the status from "to be tested" to "resolved".
The second one could also be another developer.
I need automatic feature (not by human check) to ensure that
The user (usually with developer rights) which has set the status from "assigned" to "fixed"
is a different one than the user which is setting the status from "to be tested" to "resolved".
The second one could also be another developer.
Re: How can I enforce a two-man rule for closing issues
The only clean way to get what you want is to write a Mantis plugin.
https://www.mantisbt.org/docs/master-1. ... DEV.EVENTS
https://www.mantisbt.org/docs/master-1. ... DEV.EVENTS
Re: How can I enforce a two-man rule for closing issues
Hello,
I am a colleague of TDS and started to write a plugin yesterday.
I have one big problem:
My hook on the event "EVENT_BUG_UPDATED" seems to be called only AFTER the bug-update has been written to the DB. This way, I cannot prevent a status-change from "to be tested" to "resolved".
The documentation in the provided link says the event can be used for pre- and post-processing. How can I achieve this? And if there is a way to do some pre-processing and give a Veto, is there an easy way to determine if the current bug-update is a status change? I only found a workaround by searching for the newest status change in the history table throug the history-api.
In the meanwhile I digged into some of the mantis-sources and want to add some Information, most of which is probably clear to you:
1. We are using Mantis 1.2.19.
2. bug_update.php does some special handling in case of a status-change, which (at least) includes sending out the special mails. Shouldn't this also be omitted in case of a Veto (null-return) from a plugin?
3. bug_update.php which is called from the bug-page after an update but also from bug_change_status_page.php. It contains the event_signal-call and a check for null afterwards.
I do return back null in my hooked method directly after I raise the error-message. The problem just is that the status-Change is already in the history-table and bug-table when the event is fired.
I can write and read some php code, but I don't have any IDE or any tool to debug it, so I don't see what happens here.
I am a colleague of TDS and started to write a plugin yesterday.
I have one big problem:
My hook on the event "EVENT_BUG_UPDATED" seems to be called only AFTER the bug-update has been written to the DB. This way, I cannot prevent a status-change from "to be tested" to "resolved".
The documentation in the provided link says the event can be used for pre- and post-processing. How can I achieve this? And if there is a way to do some pre-processing and give a Veto, is there an easy way to determine if the current bug-update is a status change? I only found a workaround by searching for the newest status change in the history table throug the history-api.
In the meanwhile I digged into some of the mantis-sources and want to add some Information, most of which is probably clear to you:
1. We are using Mantis 1.2.19.
2. bug_update.php does some special handling in case of a status-change, which (at least) includes sending out the special mails. Shouldn't this also be omitted in case of a Veto (null-return) from a plugin?
3. bug_update.php which is called from the bug-page after an update but also from bug_change_status_page.php. It contains the event_signal-call and a check for null afterwards.
I do return back null in my hooked method directly after I raise the error-message. The problem just is that the status-Change is already in the history-table and bug-table when the event is fired.
I can write and read some php code, but I don't have any IDE or any tool to debug it, so I don't see what happens here.
Re: How can I enforce a two-man rule for closing issues
Since my last changed on my first reply are not approved yet, I have to write a new reply:
Some deeper digging and logging gave the following result:
history_log_event_direct is called for the field "status" after submitting the bug_change_status_page.php but before the event_signal in bug_update.php is called.
The call to history_log_event_direct does not come from bug_api.php->update. I also see no way how it should come from bug_api.php->bug_assign, but this is the only function I could find which also logs a status update to the history table. And wherever this status-change is logged, the status in the bug-table is also changed already, cause there is no second logging of a status-Change.
I can't figure out what is going on here...
Some deeper digging and logging gave the following result:
history_log_event_direct is called for the field "status" after submitting the bug_change_status_page.php but before the event_signal in bug_update.php is called.
The call to history_log_event_direct does not come from bug_api.php->update. I also see no way how it should come from bug_api.php->bug_assign, but this is the only function I could find which also logs a status update to the history table. And wherever this status-change is logged, the status in the bug-table is also changed already, cause there is no second logging of a status-Change.
I can't figure out what is going on here...
Re: How can I enforce a two-man rule for closing issues
ok, next one, can't stop researching this 
bug_update.php calls bug->bug_resolve which calls bug->bug_set_field for the status which update bug-table and calls history_log_event*.
So the poblem seems to be, that the code block to "hadle status transitions that come from pages other than bug_*update_page.php" is executed before the event is triggered and can give a Veto.
So two final questions:
A. Is the EVENT_UPDATE_BUG designed to also handle updates from generic update-pages such as status-change?
B. Would calling event_signal before the status-transition-code-block is reached solve the problem or would it introduce new (maybe worse) problems?
bug_update.php calls bug->bug_resolve which calls bug->bug_set_field for the status which update bug-table and calls history_log_event*.
So the poblem seems to be, that the code block to "hadle status transitions that come from pages other than bug_*update_page.php" is executed before the event is triggered and can give a Veto.
So two final questions:
A. Is the EVENT_UPDATE_BUG designed to also handle updates from generic update-pages such as status-change?
B. Would calling event_signal before the status-transition-code-block is reached solve the problem or would it introduce new (maybe worse) problems?
Re: How can I enforce a two-man rule for closing issues
I can hardly invest any time in supporting this issue, but at least would like to provide some hints.
- the documentations of 1.2.x is questionable, so better trust the code
- the documentations of 1.3 is better, but there is still a lot of space for optimizations
https://www.mantisbt.org/docs/master/en ... ml-single/
There are some known limitations and bugs around some events.
Some of them are fixed in 1.3, some of them need major redesign and will also not be befixed in 1.3.
E.g. 1.3. provides a new event EVENT_UPDATE_BUG_DATA
Have a look at those issues and the related ones to get an impression of the current state
https://www.mantisbt.org/bugs/view.php?id=11967
https://www.mantisbt.org/bugs/view.php?id=20577
https://www.mantisbt.org/bugs/view.php?id=20578
Feel free to open more reports for it at https://www.mantisbt.org/bugs if your problem is not covered by the existing bug reports.
Hope this helps at least a litte bit.
- the documentations of 1.2.x is questionable, so better trust the code
- the documentations of 1.3 is better, but there is still a lot of space for optimizations
https://www.mantisbt.org/docs/master/en ... ml-single/
There are some known limitations and bugs around some events.
Some of them are fixed in 1.3, some of them need major redesign and will also not be befixed in 1.3.
E.g. 1.3. provides a new event EVENT_UPDATE_BUG_DATA
Have a look at those issues and the related ones to get an impression of the current state
https://www.mantisbt.org/bugs/view.php?id=11967
https://www.mantisbt.org/bugs/view.php?id=20577
https://www.mantisbt.org/bugs/view.php?id=20578
Feel free to open more reports for it at https://www.mantisbt.org/bugs if your problem is not covered by the existing bug reports.
Hope this helps at least a litte bit.
Re: How can I enforce a two-man rule for closing issues
Ok, I see. There are already several tickets describing this Problem. And for 1.3.0 there's a new chain Event for preprocessing which gets called before any status-transisitions are handled. This solution looks good.
So I will create a local patch (firing the event before the status-handling) in our Installation . And I will be careful to not use another plugin which hooks EVENT_BUG_UPDATE cause it might be designed for the original behaviour of 1.2.x.
So I will create a local patch (firing the event before the status-handling) in our Installation . And I will be careful to not use another plugin which hooks EVENT_BUG_UPDATE cause it might be designed for the original behaviour of 1.2.x.