[schema] Add GraphQL layer for teams

[Rashmi-K-A]

This PR includes the changes for extending the GraphQL layer to manipulate Team objects. It adds a query for searching through Team objects and two mutations - AddTeam and DeleteTeam for creating and deleting Team objects respectively.

This PR closes #558.

[sduenas]

The PR looks good to me. Good job. Before we merging it, can you rebase it with muggle branch (I merged your other PR before).

I also have another question and I don't know if we can fix it in this PR. Probably we can do it in a different one. The thing is, when we run a query to ask for Teams, the fields related to the django tree package are visible. I think those fields shouldn't be exposed with the api cause they are details of the implementation but maybe I'm wrong. Also, if I understand correctly, it's not possible to ask for the children of a team. That's something that we should do because it's part of the idea of GraphQL.

[Rashmi-K-A]

The PR looks good to me. Good job. Before we merging it, can you rebase it with muggle branch (I merged your other PR before).

I also have another question and I don't know if we can fix it in this PR. Probably we can do it in a different one. The thing is, when we run a query to ask for Teams, the fields related to the django tree package are visible. I think those fields shouldn't be exposed with the api cause they are details of the implementation but maybe I'm wrong. Also, if I understand correctly, it's not possible to ask for the children of a team. That's something that we should do because it's part of the idea of GraphQL.

@sduenas:

About the implementation details - I think am a bit confused here, it doesnt return any of the fields like path and depth and num children in the graphQL response. Did you mean something else?

About getting the children - I was thinking of this, it is just a different function call getChildren instead of getDescendants, maybe we can add a bool filter that can toggle based on whether users want just the children or all descendants. Or if you think we dont have a need for users to see all descendants, we can just use getChildren instead.

[sduenas]

The PR looks good to me. Good job. Before we merging it, can you rebase it with muggle branch (I merged your other PR before).
I also have another question and I don't know if we can fix it in this PR. Probably we can do it in a different one. The thing is, when we run a query to ask for Teams, the fields related to the django tree package are visible. I think those fields shouldn't be exposed with the api cause they are details of the implementation but maybe I'm wrong. Also, if I understand correctly, it's not possible to ask for the children of a team. That's something that we should do because it's part of the idea of GraphQL.

@sduenas:

About the implementation details - I think am a bit confused here, it doesnt return any of the fields like path and depth and num children in the graphQL response. Did you mean something else?

It does. For example, if you run this query:

query teams {
  teams {
    entities {
      name
      path
      numchild
    }
  }
}

I get the next results for the two teams that I created:

{
  "data": {
    "teams": {
      "entities": [
        {
          "name": "test",
          "path": "0001",
          "numchild": 0
        },
        {
          "name": "test2",
          "path": "0002",
          "numchild": 0
        }
      ]
    }
  }
}

This is because we're exposing these fields from the internal model. I'm not sure if it's possible to avoid it.

About getting the children - I was thinking of this, it is just a different function call getChildren instead of getDescendants, maybe we can add a bool filter that can toggle based on whether users want just the children or all descendants. Or if you think we dont have a need for users to see all descendants, we can just use getChildren instead.

The descendants should be resolved within the query. I don't think we should add any filter to that. It should be something like:

query teams {
  teams {
    entities {
      name
      subteams {
         name
         subteams {
           name
           ...
      }
    }
  }

It's not mandatory to have it now but I think it's something we need because it's kind of the purpose of having graphql and a REST API, for example.

[Rashmi-K-A]

@sduenas:
About the implementation details - I think am a bit confused here, it doesnt return any of the fields like path and depth and num children in the graphQL response. Did you mean something else?

It does. For example, if you run this query:

query teams {
  teams {
    entities {
      name
      path
      numchild
    }
  }
}

I get the next results for the two teams that I created:

{
  "data": {
    "teams": {
      ...
  }
}

This is because we're exposing these fields from the internal model. I'm not sure if it's possible to avoid it.

@sduenas Oh! I did not notice that. Can we not use exclude=("path", "depth",.....) on the TeamType in schema.py to exclude certain fields?

[Rashmi-K-A]

About getting the children - I was thinking of this, it is just a different function call getChildren instead of getDescendants, maybe we can add a bool filter that can toggle based on whether users want just the children or all descendants. Or if you think we dont have a need for users to see all descendants, we can just use getChildren instead.

The descendants should be resolved within the query. I don't think we should add any filter to that. It should be something like:

query teams {
  teams {
    entities {
      name
      subteams {
         name
         subteams {
           name
           ...
      }
    }
  }

It's not mandatory to have it now but I think it's something we need because it's kind of the purpose of having graphql and a REST API, for example.

Sure, I think we can work out a way to do that. I ll make note of it for now and we can circle back to it when the UI is done.

[sduenas]

LGTM

[sduenas]

I merged the PR but I'm going to open two issues to try to resolve the open questions of this PR.