[PD-10597] GraphQL Backend Restrictions

[eledumorales]

Description

Implements access of the following list:

1. Queries
2. Query Fields
3. Mutations
4. Mutation Arguments

based on role's restrictions. If restrictions doesn't exist, it will display full data.

Result Format

Queries:
if a certain attribute has a view restriction, it will return null. Required fields can't be restricted because this will cause a schema conflict.

Mutations:
following graphql's result structure, warnings will be added inside { errors: warning: ... } and it will contain a list of the attributes/arguments (key) with the restriction (value). In the following example, it displays Project restrictions on name attribute and also restrictions on User's teamId attribute, which is a Project Texter's nested resource:

"errors": {
        "warning": {
          "project": [
            {
              "name": "don't have permissions to update"
            },
            {
              "projectTexter": [
                {
                  "user": [
                    {
                      "teamId": "don't have permissions to create"
                    }
                  ]
                }
              ]
            }
          ]
        }
      }

obs:

• Required fields can't be restricted for queries and mutations because of schema conflicts.
• Specify restriction type warning for nested attributes will be added in another ticket

Checklist

• I have added appropriate tests if this PR fixes a bug or adds a feature.
• All status checks (tests, linting, etc...) are passing.

[kylejginavan]

Task linked: PD-10597 GraphQL Backend Security Restrictions

[uezper95]

why was the advisor created if the user had restrictions on those fields? Or was the advisor created but the fields that were restricted just were filled with nil ?

[eledumorales]

the second description is the correct one, advisor will be created but with restricted attributes filtered. User will receive a warning about the attributes that were not saved because of role's restrictions

[kylejginavan]

Why do we need to check RequiredField to view?

[eledumorales]

required fields can't be restricted because this will cause a schema conflict. For example if attribute name is required, the schema assures that this attribute will always be returned as string. If it has a restriction, it will try to return null, causing a query fail for schema error

[kylejginavan]

1. Lots of duplicate logic. I think there should be a helper method that passes base resource name and field name to a helper function to do the checks.
2. I don't think the specs cover all the use cases.

[kylejginavan]

Why are we using ruby here instead of sql? I would add specs then convert to SQL. Same comment applies to many of the functions in this file.

[feded]

memoize base_restrictions thus is always the same

@base_restrictions ||=  context[:current_user]&.restrictions&.select do |el|
     (el.resource.resource_type_id == "HasHelpers::ResourceType::::BaseResource")
end
restrictions = @base_restrictions.select { |r|  restriction_operations.include?(r.restriction_operation_id) }