View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015788 | mantisbt | administration | public | 2013-04-26 05:56 | 2021-07-27 21:12 |
Reporter | eelcodegraaff | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | feedback | Resolution | open | ||
Product Version | 1.2.7 | ||||
Summary | 0015788: request for change Assign collection of bugs to Reporter | ||||
Description | When we are using mantis we found one step could help us a lot.
Te result will be : | ||||
Additional Information | could this feature to be able to use "globals" like reporter, also in a collection of selected bugs... | ||||
Tags | No tags attached. | ||||
related to | 0010958 | acknowledged | patch: added "assign to reporter" to the bug_change_status_page |
The out-of-the-box workflow/permissions settings in Mantis do not allow Reporters to be assigned issues, so I assumed you customized that. What I would try to do in this case:
I'll let you work out the specifics. |
|
Sorry maybe i dont understand you : view issues: make a filter for fixed in version now i want to assign all bugs to be retested to the original reporter (since sometimes the bugs are assigned to different people) use checkbox select all i hope this makes it a bit more detailled for you regards eelco |
|
I understood that perfectly. What I'm saying is that instead of assigning the issues to the reporters, I recommend instead to define a new status for the workflow, and instead use the Update Status mass-update option to inform the reporters. You can do this now, out of the box (but you need to change your process, the way you currently use the system). Doing what you request is not only unlikely to happen in any foreseeable future unless you provide a patch, and even then not sure we'd include that as issues are normally not assigned to reporters. |
|
Ok, thanks for your suggestions on this issue: Maybe our test processes and the delivery of the builds to the test-environment are uncommon? Even when we add the step re-test in the process flow, there will still be the mass action to give the reporters the signal to retest and close the bug. what happens in our situation : here you will find a issue, the developer can assign the bug to the reporter to test but : in our process all fixed bugs will be assigned to the stage-manager (and even when you don't use this you want to have a person to agree on closing the bug owner) it is also not uncommon in the itil incident management process. Maybe i make some rumour now to make the statement a developer is not the person to decide a bug is fixed. The only person that has this mandate is the person that reported the bug :-) This will create a clear responsibility between tester and developer. when the version of the software with the bugs solved is builded, and delivered it will be deployed to the test systems. at that moment we will have the reporters a to retest the bug. The mass update will give the option to add a comment and this way trigger a email but the process make the reporter responsible to take action on his bug-report is still not solved i think. We use this method now for 6 years, and we do it now bug by bug but using the batch functions would make live easier. But i have respect for your opinion on this, and since i am not a programmer but a testmanager/testcoordinator i have to live with it :-) |
|
Just so you know, in my day job I happen to be responsible for software service delivery in a big pharma company, so trust me I know everything about strict processes (including GxP), testing and validated systems. What I'm trying to tell you is that using Mantis you do not need to assign an issue to a reporter to give them the "formal" opportunity to approve and ultimately close an issue. Here's how I did my own setup at work reporter opens issue (new)
All this while, reporters are never assigned an issue. We only set "allow reporter close". This is just to give you a concrete example, trying to propose a solution you can apply now, as opposed to waiting for months or years for a feature that may even never come (since it's not a common Mantis workflow to assign issues to reporters) Recommended reading: http://www.mantisbt.org/docs/master-1.2.x/en/administration_guide/admin.customize.status.html Just let me know if you want to keep this open as a new feature request or if I can close it. |
|
I agree, this is one of my use cases. But there is also another typical use case in my projects: Assigning to [Reporter] would not make sense when dealing with such mixed types of issues. I would need at least: But still not enough: A test manager should take the time to have a deeper look to every single issue. |
|
Seems we have a nice discussion on this one: I have the expectation the developer as wel as the reporter as well as the retester want to have a work list. For the developer this work list is the bugs assigned to him (since the manager assings bugs to different developers) it creates their worklist. If you look at bugs assigned to me, you know your work The another example where the bugs are assigned to a retester the bug is assigned and here you have as a person a worklist with issues to check and close. It is a manual job in this case there is not simple algorithm to solve this one other than using generic user accounts In the request i made, i want to have also the work list for the reporter/retester to be able to have the bugfixes assigned to him, it is hist worlist, not different as the list for the developer. It is the worklist for the person that need to validate the development solution and close the bug or reassign as bad-fix. In fact the whole functionality is there at this moment and the global [reporter] could be used in the assigning process. It is add to the assign collection of bugs not to assign 10 selected bugs to 1 single person to assing 10 selected bugs to the reporting persons. The 10 bugs are based on a selection filter, this can be a filter with tags i have added to bugs during the examination of the notes added to the bug or just a simple fixed in version. Answer on the question would i accept the suggested work around should be a no, simple because the principle of having your worklist as tasks is not solved. Or i does not understand the suggestions, in that case there is a bug in my brain. :-) |
|
BTW i will take some extra time to analyse the other suggested work-flow and or do some tests with my team on this work flow. I realise the request will take a long time we have a working process and we do it now bug by bug in the operational processes. It was a logical question based on the fact, when you know the [reporter] why don't use it where you can use bulk actions. So no hard feelings, it was in imho a small change in creating the global assign list. |
|
You can add your own custom group action "assign to reporter" by using the custom_group_actions config variable and building a custom edit and action page. See config_defaults_inc.php for details. |
|
This is (to some extent) visible out of the box in the My View page (in the 'Reported by me' box), and users can click on the header to see more than the default number of records You may want to try and set your config_inc.php with $g_my_view_boxes, setting 'verify' to some value, maybe this would give you what you want. You should also be able to easily implement this view through a saved filter also.
|
|
@dregad Bless you! I happen to work in the pharmaceutical sector, and I would dream of having an expert like you in my team. Concerning MantisBT, we are using informally MantisBT as tracker for tasks in the company, but we would also like to make the big jump towards complete Computer Software Validation and use MantisBT for GMP purposes to handle change controls, deviations, etc. Yet, convincing dinosaurs in IT and management is quite difficult. Have you got any advice? |
|