RC_Update Forbidden group (CR-357)

• Purpose

• Key points

• Specification

• Authorization

• Validate legal entity

• Validate Digital Sign

• Validate request

• Service logic

Purpose

This WS allows to update forbidden group params from Admin panel.

Key points

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

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

3. Forbidden group should be signed with DS.

4. Group updates w/o any changes in Forbidden group items (services, dictionary codes or service groups)

Specification

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 at least one of params (short_name or sms_url) are submitted

  • in case of error - return 422 ('At least one update param is required')

• Check forbidden group exists and is active record in forbidden_groups table in PRM DB

  • in case of error - return 422 ('Forbidden group is not found.')

Service logic

1. Save signed content to bucket forbidden-groups-dev with name update/<timestamp> (where <timestamp> -- time of update in unix_time format)

2. Save data to forbidden_groups table (PRM DB) according to Forbidden group data model