Create Forbidden group_EN

Purpose

This WS allows to create forbidden group from Admin panel. The group will be used as additional restriction on get/search specific medical events.

Key points

1. This is a graphQl method used in Administration panel only

2. Only authenticated and authorized NHS employee with appropriate scope can create a Forbidden group.

3. Forbidden group should be signed with DS.

4. Group creates w/o any items such as services, dictionary codes or service groups

Specification

"""
Input for `createForbiddenGroup` mutation.
User must have a scope **forbidden_group:write**
"""
input CreateForbiddenGroupInput {
  "The name of the `ForbiddenGroup`."
  name: String!
  "Reason for creating the `ForbiddenGroup`."
  creationReason: String!
}

"""
Return type for `createForbiddenGroup` mutation.
"""
type CreateForbiddenGroupPayload {
  "Created `ForbiddenGroup`."
  forbiddenGroup: ForbiddenGroup
}

Authorization

• Verify the validity of access token

  • in case of error - return 401 (“Invalid access token”) in case of validation fails

• Verify that token is not expired

  • in case of error - return 401 (“Invalid access token”)

• Check user scopes in order to perform this action (scope = 'forbidden_group:write')

  • return 403 (“Your scope does not allow to access this resource. Missing allowances: forbidden_group:write”) in case of invalid scope(s)

Validate legal entity

• Extract client_id from token.

• Check client scopes in order to perform this action (scope = 'forbidden_group:write')

  • in case of error - return 403 (“Your scope does not allow to access this resource. Missing allowances: forbidden_group:write”)

• Check legal entity status (status = ACTIVE)

  • In case of error - return 409 ('client_id refers to legal entity that is not active')

Validate Digital Sign

• Validate request is signed

  • in case of error - return 422 (“document must be signed by 1 signer but contains 0 signatures”)

• Check DS is valid and not expired

• Validate that DS belongs to the user

  • Check that DRFO from DS and party.tax_id matches

    • in case of error - return 409 (“Signer DRFO doesn't match with requester tax_id“)

Validate request

• Check name and creation_reason is submitted

  • in case of error - return 422 ('required property <name/creation_reason> was not present')

Service logic

1. Save signed content to media storage

2. Save data to forbidden_groups table (PRM DB) according to /wiki/spaces/FORBIDDEN/pages/2087190529