View Issue Details

IDProjectCategoryView StatusLast Update
0003698mantisbtfeaturepublic2017-01-18 09:58
Reporterdrdoctor Assigned To 
Status newResolutionopen 
Summary0003698: Approval Management

Need for Approval Management:

  • Testing and Approval options
  • Notifications to testers and managers when ready
TagsNo tags attached.




2004-03-29 06:24

reporter   ~0005280

To me this sounds as a good extension to the current functionalities of Mantis. But only adding testing and approval option to Mantis is not enough.

According to my opinion the above point are related to an 'observation tool' and not specific to a bugtracker and than you will get a complete different life-cycle, like:

a.) observe --> b.) analyse --> c.) asign tasks (to developers) --> d.) (developers) perform task --> e.) test the result (by the observer [see a.]) --> f.) close the observation

The analyses should then also be added to Mantis Bug or can the note field be enough? Than the task section; developers should see the actions that have been assigned to them and you even can add the approval (e.g. by the analyser) option to the specific task. After all tasks have been performed (to solve the observation), the observation will be ready for test. According to my opinion the observer should test the result and if it is OK the observation can be closed. If the fix did not solved the observation a testnote should be added and the observation should be analyses again by the analyser (see life cycle).



2004-03-29 06:46

reporter   ~0005281

What I'm missing from Mantis ATM that it is not capable the handle Verification, which is the last stage in the life cycle of the bug.

The process of verifying includes a review of the resolution information and confirmation of the resolution. The review of the resolution is to ensure
that the information is complete, accurate and complies with this process. Confirmation of the resolution can be done by performing an independent test or by reviewing existing information.

See the attached picture for the workflow.

It's important that the verification is independent from the developer or the reporter!

If these verification activities demonstrate that the SPR has been successfully resolved, the SPR is changed to state Verified and appropriate verification information is added.

It would be a configurable option, this feature could be enabled/disabled by a variable.

2004-03-29 06:47


untitled.gif (16,375 bytes)   
untitled.gif (16,375 bytes)   

2004-03-30 08:17


mantisflow.ppt (28,672 bytes)

2004-03-30 08:17


mantisflow.png (8,110 bytes)   
mantisflow.png (8,110 bytes)   


2004-03-30 08:18

reporter   ~0005290

Added a powerpoint presentation (and image to give an impression) in which I more or less describe the situation of the first note (by me) for this observation.



2004-03-30 12:47

reporter   ~0005291

On our tracker system (we are trying to migrate to mantis) we have policies in place to say that developers can only put bugs into "in test" and only our lab techs are allowed to move a bug from "in test" to "closed", but this is all just policy and there is nothing in our current system that would enforce this. It would be really great if mantis could do something like this.



2004-03-31 02:58

reporter   ~0005293

Redcom - you're right, now in the Mantis this can be done only if you insert a status between resolved and closed: tested or verified and only allow the developer to resolve a bug and give "manager" access (higher level) to lab techs (so they can put the bug into tested status) - but this solution is not really optimal...

Blaat - still I don't understand what is the benefit of the proposed 'observation tool'...
Do you want to create different tasks for the developers if a bug is inserted into the Mantis?



2004-03-31 04:34

reporter   ~0005301

Why an observation tool?

I think this has more to do with the fact that I look at Mantis from a testers point of view and than even more at the FAT (Functional Acceptance Test) of an application or product which has been build.

If you are performing e.g. the FAT Test scripts and something is not inline with the expectation, you can name it a bug or an incident. But these words sound negative, therefore we use the term 'observation' (which is also advised by the ISEB).

After we put the observation in the tool it can then (as you see in the flow) be analysed by an analyser (e.g. the writer of the functional specifications) and makes a conclusion. This can e.g. be:

  1. It is build inline with Functional Specs (but if you really need it we can build it);
  2. It is a duplicate of another observation;
  3. It is nothing so cancel.
  4. Is an incident/bug.

If it is the 1st you and your customer can talk about implementation, costs, etc.
If it is the 2nd you need to wait before the other observation (tasks) is solved to test the outcome of this observation
If it is the 4th the analyser needs to make tasks for the development team (or teams when you are working with different sub teams) and assign the tasks to the teams/members to solve the incident/bug.

Once the developers perform all their tasks and mark them as finished in the tool the observation is then ready for the laboratory testing. If this is then internally accepted the observer (during FAT, thus the customer) can then rerun the test script and accepts the observation, so it can be closed in the tool.

Why register tasks in the Tool?

As you are already finished with building your product according to you specs and you are now in a new phase. Therefore all tasks for the developers are now registered in the observation tool as the building phase is finished. Furthermore you can make more tasks as the observation is only an observation and no tasks are defined in that.



2004-04-01 03:27

reporter   ~0005311

Thanks for the detailed description, now it depends on the developers.



2004-05-13 17:33

reporter   ~0005498

Last edited: 2004-07-30 02:21

I was reading another bugreport 0002710 (or observation) and there are also some notes which can be combined with this specific bugreport. Maybe a sort of combination can be made by the developers?

edited on: 07-30-04 02:21



2005-09-21 05:55

reporter   ~0011414

Reminder sent to: mohammed

hi mohammed,

this is a check mail



2010-05-10 05:59

reporter   ~0025446

This could be achieved by standard Mantis by creating a project for each such request. This would lead to many projects (big problem or not?).
Within 1.2 with its plugin system there is another option.A plugin that allows adding additional tasks to other developers within an issue could be a nice feature. It could also be used to assign co-workers to the same issue.
Fields to be used would be:
Initiated by
Date of creation
Due date task (before due-date of issue)
Role (executer or co-worker)
Complete Y/N
Date completed



2010-05-11 09:08

reporter (10,038 bytes)


2010-05-11 09:10

reporter   ~0025465

Attached a plugin for version 1.2 and above which allows for adding additional tasks to an issue.
Every tasks has :
Creation date (automatic)
Change date (automatic)
Due date (to be set once)
Finished date (to be set by authorised person)
Title ( 50 characters )
Description ( 150 characters )
Response ( 150 characters )
Once a task has been reported complete, it can only be deleted by authorised staff. Maintenance is no longer possible.
Upon adding a task, the person you assign it to wil receive an email in case plugin is configured to do.
Equally from every change, History records can be created in case plugin is configured to do.

Issue History

Date Modified Username Field Change
2004-03-29 05:35 drdoctor New Issue
2004-03-29 06:24 blaat Note Added: 0005280
2004-03-29 06:46 drdoctor Note Added: 0005281
2004-03-29 06:47 drdoctor File Added: untitled.gif
2004-03-30 08:17 blaat File Added: mantisflow.ppt
2004-03-30 08:17 blaat File Added: mantisflow.png
2004-03-30 08:18 blaat Note Added: 0005290
2004-03-30 12:47 redcom Note Added: 0005291
2004-03-31 02:58 drdoctor Note Added: 0005293
2004-03-31 04:34 blaat Note Added: 0005301
2004-04-01 03:27 drdoctor Note Added: 0005311
2004-05-13 17:33 blaat Note Added: 0005498
2004-07-30 02:01 blaat Sponsorship Added blaat: US$ 5
2004-07-30 02:01 blaat Sponsorship Total 0 => 5
2004-07-30 02:21 vboctor Note Edited: 0005498
2005-09-21 05:55 mohammed Note Added: 0011414
2010-05-10 05:59 cas Note Added: 0025446
2010-05-11 09:08 cas File Added:
2010-05-11 09:10 cas Note Added: 0025465
2017-01-18 09:58 atrol Severity major => feature