review

In the last section, we mainly added and modified the user’s role, and left the query and delete, which the author has implemented with code. I’m not going to explain the idea, just post code review. Specific items can be viewed inside the project!

Search the user

Because the data of a project has been shown to the front end, we can use the front end to filter, and do not need to call the back end interface.

  • In the same line as adding members, a search box is added to search for members

  • The search method

The idea of this search method is that when the user enters an empty string, the previous data is restored. When the user enters a name, all mail/name data containing name in the ROLES array is searched and the data array is updated. (After all, the Data array is where the data is actually displayed.)

  • Delete methods

The delete method is also very simple, is to delete the corresponding data by ID, if successful to reload the next data.

The backend update

Write methods to delete user roles, as we wrote in the previous section for a similar permission verification method. However, every time we decide whether he is a supermanager first, then whether he is the project owner, and finally whether he is the team leader, such steps are actually needed in addition/deletion/change, why not draw out a public method?

So we have removed the has_permission method here

The logic is also relatively simple, basically according to the above, judge the supermanager first, then the project owner. There is a group leader worthy of attention, because the group leader cannot modify the group leader’s permission, so once he is not the supermanager and not the owner, it is forbidden for him to modify the group leader’s permission (delete or change).

See the effect

Let’s get down to business now.

Change the test case table

In fact, if done more perfectly, use cases should be divided into modules, but here we are not so detailed, use cases directory is not taken out to maintain separately, on the figure of a word: save trouble

  • Level of use cases

    The value is a string of characters that can be p0-P3 or more based on service requirements.

  • Directory to which the use case belongs

    To make it easier to view the use cases, we grouped them into categories, so that the use cases formed a three-level structure:

    Project -> Directory -> Use cases

    Although the key information of the interface is not included here, the use case can then be combined with the yAPi-related documentation by adding a field: api_id to bridge the link between the test case and the API. Here first do not tangle so much!

Improve the use case list interface

  • Added interface to get use case tree
from collections import defaultdict

from app.models.test_case import TestCase
from app.utils.logger import Log


class TestCaseDao(object) :
    log = Log("TestCaseDao")

    @staticmethod
    def list_test_case(project_id) :
        try:
            case_list = TestCase.query.filter_by(project_id=project_id, deleted_at=None).order_by(
                TestCase.name.asc()).all(a)return TestCaseDao.get_tree(case_list), None
        except Exception as e:
            TestCaseDao.log.error(F "Failed to get test case:{str(e)}")
            return[].F "Failed to get test case:{str(e)}"

    @staticmethod
    def get_tree(case_list) :
        result = defaultdict(list)
        # Get directory -> use case mapping
        for cs in case_list:
            result[cs.catalogue].append(cs)
        keys = sorted(result.keys())
        tree = [dict(key=f"cat_{key}",
                     children=[{"key": f"case_{child.id}"."title": child.name} for child in result[key]],
                     title=key, total=len(result[key])) for key in keys]
        return tree

Copy the code

It’s actually a very simple query interface: get the use case according to project_id. Because trees in ANTD require data structures like this:

Json as shown below

const treeData = [
  {
    title: 'parent 1'.key: '0-0'.children: [{title: 'parent 1-0'.key: '0-0-0'.disabled: true.children: [{title: 'leaf'.key: '0-0-0-0'.disableCheckbox: true}, {title: 'leaf'.key: '0-0-0-1',},],}, {title: 'parent 1-1'.key: '0-0-1'.children: [{ title: <span style={{ color: '#1890ff' }}>sss</span>, key: '0-0-1-0'}],},]},Copy the code

The key is used to determine the uniqueness of nodes in the tree, the title is the name, and children are the subsequent nodes that hang in that directory.

Actual effect:

Note here that we prefix key with case_ and cat_ to distinguish between use cases and directories, because different data needs to present different ICONS, as we’ll show next.

  • Continue rewriting the /project/query interface

Later, if a project has a lot of data, Redis may be introduced to cache the information of the project, so that there is no need to go to the database for a special check every time.

Write a use case list page

First we split the page in two, showing the tree on the left and the use case selected by the user on the right.

Effect:

7 copies on the left, 17 copies on the right, 2 cards, if the height exceeds the scroll bar automatically.

Today I will not talk about the details of the front end in detail, after all, the tree itself is complex, feel better not to say, ha ha!

The project address

  • Front-end address:

Github.com/wuranxu/pit…

  • Back-end address:

Github.com/wuranxu/pit…

Imperceptibly wrote so long, but today is still to write code, code time shrinking, first try to speed up the pace!