Analysis of roles and permissions in Mantis

Analysis of roles and permissions in Mantis

1. The roles are as follows
     : Viewers, Reporters, Modifiers, Developers, Managers, Administrators

 

2. There are the following types of problem status
     : 10: New, 20: Call back, 30: Recognized, 40: Confirmed, 50: Dispatched, 80: Resolved, 90: Closed (abandoned, blocked)

 

3. The degree of completion of the problem is as follows:
     10: Unprocessed, 20: Corrected, 30: Reopened, 40: Unreproducible, 50: Unrepairable, 60: Repeated problem, 70: Not a problem, 80: Paused, 90: No modification

 

4. Workflow

   Role Handling Issue Issue Completion Issue Status

1. The reporting staff submits the bug and assigns it to the developer Unprocessed Assigned 

2. Developers 1) Modify the problem Corrected Solved
                2) If the situation of the problem is not clear, you can select the corresponding problem completion degree and call back
                3) Give up on modifying the problem Unhandled Give up

3. Testers 1) The   bug has been revised after the review, and it has been fixed. Close
  the problem that has been solved. 2) The bug still exists after the review                  . Blocking                       3) There is a dispute, but it is resolved after discussion Not a problem, etc. Close   


4. The manager proposes amendments to the controversial issues and decides whether to close it.     

5. Administrators create projects, assign test and developer permissions and tasks    


Note: According to the actual situation, the roles of the reporter and the tester are unified into the reporter.
                    Modifier and developer roles are unified into developer.    

 

Note: After the test is completed, the problem status is only 1, closed 2, abandoned 3, blocked.
           After being confirmed by the manager, the problem status is only 1, close 2, give up.

 

Viewers have the minimum authority
1. Can view bug information and print
2. View problem notes
3. View and download BUG attachments
4. View and download project documents.
5. Search for issues and filter issues
Applicable to: People
who want to be able to view the project content, understand the project progress, and download related project documents, but do not refer to any modification activities .

When browsing the bug information, you can remind the problem, and the most important thing is to be able to report the problem in time.
Reporter permissions:
1. View/report problems and print
2. Problem reminders
3. Modify problem status
4. Add/delete/modify problem comments5
. Upload/delete bug attachments
6. Start/cancel monitoring issues
7. Search for issues and filter issues
Applicable objects:
Persons who can describe the problem and error information at the first time, and can submit exact evidence of the problem in a timely manner,
such as a full-time test in the company Personnel (QA Specialist).

In addition to the basic permissions of the person who has and the report, the modifier also has the following permissions: permission to
modify bug issues and create sub-item issues, permission
to add sub-item issues of the issue,
or can establish dependencies with other BUG_IDs to facilitate finding and
modifying issues Person's authority
· View/report/modify problems, add sub-items and build dependencies and print
· Problem reminder
· Modify problem status
· Add/delete/modify problem comments
· Upload/delete bug attachments
· Start/cancel monitoring problems
· Search for problems and filter question

Applicable objects:
1. Be able to describe the error information of the problem at the first time, and submit the exact evidence of the problem in time.
2. Managers who are able to manage the relevant issue types and are familiar with the linkages between all issues.
Such as full-time testers (QA specialists) or QA administrators in the


company. In addition to having and modifying all the permissions of the personnel, developers also have the following permissions:
assign issues to specified users; move issues; delete issues; move issues; delete issues
Developer Permissions
View/Report/Modify Issues, Add Sub-Item Issues and Build Dependencies and Prints
Move/Delete/Copy Issues
Issue Alerts
Modify Issue Status
Add/Delete/Modify Issue Notes
Upload/Delete BUG Attachments
· Start/cancel monitoring problems
· Search and filter problems
Applicable objects:
1. Be able to describe the error information of the problem at the first time, and submit the exact evidence when the problem occurs in time.
2. Managers who are able to manage the relevant issue types and are familiar with the linkages between all issues.
3. Programmers directly involved in the development process,
such as QA administrators, R&D personnel

and managers in the company, in addition to the basic permissions of developers, they also have the following permissions:
can browse more problem information, including
unspecified personnel Issues
Resolved Issues
Recently Modified Issues
Project document management
Edit/delete/add new project document


Management Center
In project management, you can click on the existing project to manage it.
For example, change the project name and add sub-projects.
Edit/delete category item name, add version control serial number
Edit and delete custom field operations
Add personnel role permissions to this item, and can also modify and delete corresponding users from the item.

 

There are 7 process states for bugs in Mantis: New, Called, Accepted, Confirmed, Dispatched, Resolved, and Closed.

• New: The tester reports a new bug.

? Hit back: Testers change the bug status to "hit back" for "resolved" bugs that fail the verification test.

? Accepted: not currently used.

? Confirmed: If the bug submitted by the tester is deemed not to be a bug by the development manager, the bug status will be changed to "Confirmed", and corresponding comments will be added at the same time. After the development manager and the test manager discuss and decide, the tester will change the bug status to "closed" or "returned".

• Assigned: The development manager assigns a "new" or "returned" bug to a developer.

• Resolved: After the developer fixes the bug assigned to them, changes the bug to "Resolved". The tester is ready to perform the verification test.

? Closed: The tester will verify the "resolved" bug. If it passes, the bug will be changed to "closed". If it fails the verification test, the bug will be changed to "returned".

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326317465&siteId=291194637
Recommended