View Issue Details

IDProjectCategoryView StatusLast Update
0015788mantisbtadministrationpublic2021-07-27 21:12
Reportereelcodegraaff Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status feedbackResolutionopen 
Product Version1.2.7 
Summary0015788: request for change Assign collection of bugs to Reporter
Description

When we are using mantis we found one step could help us a lot.
You have a collection of bugs, and a collection of reporters. The bugs have the status fixed in version.
We now come to the moment we want to retest te bugs.
A logical procedure would be:
-filter bugs fixed in version X
-select all bugs

  • choose assing bugs to >
    and there i dont want to individuals but to "Reporter" and i miss this one badly.
    Assign should also not change status in this case.

Te result will be :
All bugs that have been reported and have the status fixed in version x can be retested since i have installed version x to the test system.
After the reporter has retested and the bug is fixed, he or she closed the bug.

Additional Information

could this feature to be able to use "globals" like reporter, also in a collection of selected bugs...

TagsNo tags attached.

Relationships

related to 0010958 acknowledged patch: added "assign to reporter" to the bug_change_status_page 

Activities

dregad

dregad

2013-04-26 06:54

developer   ~0036676

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:

  • create a custom status 'retesting' (or whatever) that is reachable from 'resolved' state
  • after release, manager sets bugs fixed in version X to 'retesting' state
  • from there, reporters can either close or reopen them if the issue is not fixed

I'll let you work out the specifics.

eelcodegraaff

eelcodegraaff

2013-04-26 11:17

reporter   ~0036682

Sorry maybe i dont understand you :
[Reporter] is not the group but the meta like the [myself]

view issues: make a filter for fixed in version
in my case i have lets say 10 bugs reported by several testers and solved by several developers.

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
use pulldown > assign
klick OK
then you have assign issues to > all people in the group but what i miss here is the meta for [Reporter]
This would give the testmanager a simple trick to direct assing all bugs to the right person for retesting

i hope this makes it a bit more detailled for you

regards eelco

dregad

dregad

2013-04-26 12:48

developer   ~0036684

[Reporter] is not the group but the meta like the [myself]

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.

eelcodegraaff

eelcodegraaff

2013-04-26 14:48

reporter   ~0036688

Ok, thanks for your suggestions on this issue:
It is in the testing processes quite normal to let the person that has reported a bug also test the bugfix and agree it has been fixed or agree on a won't fix. We test medical software and use strict processes.

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 :
a reports a bug
m the project manager assigns the bug to a developer d
d puts the bug on resolved in next version.

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 :-)

dregad

dregad

2013-04-26 17:07

developer   ~0036689

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)
issue is triaged (acknowledged) and optionally (confirmed)
manager gives it to a developer (assigned)
developer fixes issue in dev env (testing - custom status)
release is migrated to test env, beta testing:

  • problem still exist (back to assigned)
  • problem is solved (resolved)
    release is migrated to prod
    issues are confirmed resolved (closed - done by users or by managers if users don't do within given time)

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.

atrol

atrol

2013-04-26 17:11

developer   ~0036690

Last edited: 2013-04-26 17:15

It is in the testing processes quite normal to let the person that has reported a bug also test the bugfix and agree it has been fixed or agree on a won't fix.

I agree, this is one of my use cases.

But there is also another typical use case in my projects:
Developers are reporting bugs and fix them.
Another user tests the fix.

Assigning to [Reporter] would not make sense when dealing with such mixed types of issues.

I would need at least:
Assign to the reporter if the reporter is not the one that set solution to fixed.

But still not enough:
I am the one who knows which is the best one to test the fix because I am the one who knows which skills are needed to test the fix.
I am the one who knows which one of the test team is good in working together with this special developer
....

A test manager should take the time to have a deeper look to every single issue.
Managers that use just bulk operations to delegate the work can be replaced by a MantisBT plugin which is triggered by a cron job ;-)

eelcodegraaff

eelcodegraaff

2013-04-27 05:01

reporter   ~0036691

Seems we have a nice discussion on this one:
I understand it is a matter of expectation and how you want to do your work.

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. :-)

eelcodegraaff

eelcodegraaff

2013-04-27 05:02

reporter   ~0036692

Last edited: 2013-04-27 05:07

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.

nimmich

nimmich

2013-04-28 06:22

reporter   ~0036723

Last edited: 2013-04-28 06:23

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.

dregad

dregad

2013-04-29 06:35

developer   ~0036729

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

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.

  • reported by [myself]
  • status = resolved (or whatever it is before you finally close the issues)
Matteo.Z

Matteo.Z

2021-07-27 21:12

reporter   ~0065718

@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?