Мета

Даний веб-сервіс (WS) для початку створення запиту на персону для оновлення даних персони, у відповідності до його id, який перед цим був знайдений з токену доступу по person_id.

Специфікація

Apiary

Основні положення

1. Даний веб-сервіс (WS) має використовуватись тільки для оновлення існуючої персони в системі.

2. Автентифікаційний метод персони та довіреної особи не мають передаватись в запиті для оновлення персони.

Авторизація

• Перевірити валідність токену доступу

  • Повернути (401, 'Invalid access token') в разі неуспішних перевірок

• Перевірити, що токен дійсний

  • в разі помилки - повернути (401, 'Invalid access token')

• Перевірити скоупи користувача на можливість виконання даної дії (scope = 'person_request:write_pis')

  • Повернути (403, 'Your scope does not allow to access this resource. Missing allowances: person_request:write_pis') в разі невалідних скоупів

• Перевірити, що токен містисть person_id

  • в разі помилки - повернути (401, 'Invalid access token')

Перевірити персону

• Отримати person_id з токену (x-person-id хедер)

• Перевірити статус персони, що він активний (status = ‘active' & is_active = 'true’)

  • в разі помилки - повернути 404 ('Person is not found')

• Перевірити, що об'єм змін даних по персоні в запиті допустимий (персона не оновлюється забагато), у відповідності до існуючої перевірки, описаної тут Create/Update person request | Update person request. Порівняти отриманий скор з конфігураційним параметром PERSON_ONLINE_DEDUPLICATION_UPDATE_SCORE_PIS.

Перевірити довірену особу та взаємозв'язок

Якщо персона юридично не дієздатна - система має переконатись, що її дані оновлюються довіреною особою та є зареєстрований та верифікований взаємозв'язок.

Отримати applicant_person_id з токену, порівняти цого до person_id з токену:

• якщо рівний - перевірити, що персона має бути не авторизована як довірена особа, що вона не відповідає наступним правилам:

  • вік персони < no_self_registration_age глобальному параметру;

  • що вік персони між значенням no_self_registration_age та person_full_legal_capacity_age глобальних параметрів та персона не має документу з типом з конфігураційного параметру PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES;

  • вік персони > person_full_legal_capacity_age глобального параметру та існує хоча б один взаємозв'язок активний та погоджений з довіреною особою з персоною (викорисовуючи наступний процес Check confidant person relationship з person_id = person з запиту - очікується відповідь :ok, :approved)

    • в разі помилки - повернути 409 (‘Request must be authorized by confidant person’)

• Якщо не рівний - перевірити взаємозв'язок по наступним крокам:

  • Перевірити, що зареєстрований взаємозв'язок між person_id та applicant_person_id(MPI.confidant_person_relationships)

  • Перевірити, що взаємозв'язок є VERIFIED

    • в разі помилки - повернути 409 (‘Can’t confirm relationship’)

  • Перевірити, що існує applicant_person_id (status = 'active' & is_active = 'true') та має будь-який verification_status але не NOT_VERIFIED

    • в разі помилки - повернути 409 (‘Confidant person not found or is not verified’)

Перевірити запит

Перевірити запит, використовуючи JSON схему (у відповідності до Вимоги до набору даних персони )

• в разі, якщо значення поля не відповідає схемі - повернути 422 з повідомленням у відповідності до поля

• в разі, якщо додаткові поля присутні в запиті - повернути 422 ('schema does not allow additional properties')

• в разі, якщо потрібні параметри не присутні в запиті - повернути 422 ('required property %{property} was not present')

• в разі, якщо необхідний набір параметрів не присутній в запиті - повернути 422 ('expected a minimum of %{min} items but got %{actual}')

Перевірити tax_id

• Перевірити, що $.person.tax_id відповідає оновленому полю персони tax_id

  • в разі помилки - повернути 422 ('tax_id can't be updated')

• Додатково, перевірити tax_id у відповідності до існуючих перевірок, описаних тут Create/Update person request | Validate "tax_id"

Перевірити признак no_tax_id

• Перевірити признак no_tax_id у відповідності до існуючих перевірок, описаних тут Create/Update person request | Check "no_tax_id" flag

Перевірити признак patient_signed

• Перевірити признак patient_signed у відповідності до існуючих перевірок, описаних тут Create/Update person request | Check "patient_signed" flag

Перевірити признак process_disclosure_data_consent

• Перевірити признак process_disclosure_data_consent у відповідності до існуючих перевірок, описаних тутCreate/Update person request | Validate person documents

Перевірити адреси персон

• Перевірити адреси персони у відповідності до існуючих перевірок, описаних тут Create/Update person request | Validate person documents

Перевірити документи персон

• Якщо оновлений unzr персони не рівний null - перевірити, що $.person.unzr рівний оновленому unzr персони

  • в разі помилки - повернути 422 ('unzr can't be updated')

• Додатково, перевірити документи персони у відповідності до існуючих перевірок, описаних тутCreate/Update person request | Validate person documents

Сервісна логіка

Згенерувати URL завантаження

В залежності від пейлоад (набору даних) система генерує перелік signed urls для завантаження скан-копій документів.

Підписані URLs дійсні тільки протягом виділеного періоду часу (у відповідності до конфігураційного параметру SECRETS_TTL). Якщо період вийшов - новий запит на персону має бути створено.

Для кожного типу документу, якщо спрацьовують пару правил - генерується тільки один лінк.

1. Перевірити блок документів персони. Якщо одни з документів має document.type = BIRTH_CERTIFICATE_FOREIGN та вік персони < no_self_auth_age глобального параметру, то

   1. Згенерувати URL з типом person.BIRTH_CERTIFICATE_FOREIGN

2. Перевірити блок документів персони. Якщо одни з документів має document.type = PERMANENT_RESIDENCE_PERMIT та вік персони >= no_self_auth_age глобального параметру то

   1. Згенерувати URL з типом person.PERMANENT_RESIDENCE_PERMIT

3. Перевірити блок документів персони. Якщо одни з документів має document.type з PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES то

   1. Згенерувати URL з типом person.<<document_type>> де document_type - тип документа з конфігураційного параметру, для кожного знайти тип документу

4. Перевірити unzr персони. Якщо $.person.unzr не пусто та перші 8 цифр для $.person.unzr != $.person.birth_date

   1. Згенерувати URL з типом person.unzr

Викликати Media Content Storage для генерації URL завантаження для кожного документу отримані шляхом виконання логіки вище та зберіганням документів до DB.

Згенерувати друковану форму

Підготувати дані для друкованої форми по запиту на персону

1. Визначити шаблон друкованої форми на основі поля applicant_person_id з токену та перевірки взаємозв'язку з довіреною особою:

   1. Якщо applicant_person_id не рівна person_id з токену - вибрати друковану форму для довіреної особи (зберігається в конфігураційному параметрі PIS_PERSON_REQUEST_PRINTOUT_FORM_INCAPACITY_TEMPLATE_ID)

   2. Якщо applicant_person_id рівна person_id з токену - обрати друковану форму без довіреної особи (зберігається в конфігураційному параметрі PIS_PERSON_REQUEST_PRINTOUT_FORM_TEMPLATE_ID)

2. Викликати сервіс MAN для відображення друкованої форми

3. Підготувати контент друкованої форми на основі даних запиту на персону

   1. для друкованої форми з довіреною особою - додатково завантажити дані довіреної особи на основі applicant_person_id з токену

      1. отримати дані довіреної особи з таблиці persons (з persons.id = applicant_person_id)

      2. отримати документи довіреної особи з таблиці person_documents (з person_documents.person_id = applicant_person_id)

      3. отримати документи по взаємозв'язку з таблиці confidant_person_relationship_documents (з confidant_person_relationship_id = id для взаємозв'язку між персоною та довіреною особою)

4. Відобразити друковану форму та зберегти до запиту на персону

Знайти запити на персону в статусі pending

Знайти запити на персону в статусі pending в IL.person_requests для уникнення дублів запитів:

• person_data_id = person_id з токену

• status = NEW або APPROVED

Відмінити запити на персону

Змінити статуси всіх знайдених запитів на персону:

• встановити статус = CANCELLED

• встановити updated_at = now()

• встановити updated_by = user_id з токену

Знайти запит на персону

Додати запис до IL.person_requests, встановити значення:

• id = автогенерований uuid

• person_data = $.person з запиту в форматі json

  • person_data.person.id = person_id з токену

• status = NEW

• authentication_method_current = null

• channel = PIS

• legal_entity_id = null

• tax_id = $.person.tax_id з запиту (якщо не null)

• last_name = $.person.last_name з запиту

• first_name = $.person.first_name з запиту

• birth_date = $.person.birth_date з запиту

• printout_form = відобразити друковану форму

• documents = згенеровані лінки для завантаження документів (якщо потрібно)

• person_documents = $.person.documents з запиту в форматі json

• inserted_by = user_id з токену

• updated_by = user_id з токену

• inserted_at = now()

• updated_at = now()

• patient_signed = $.patient_signed з запиту

• process_disclosure_data_consent = $.process_disclosure_data_consent з запиту

• person_data_id = $.person.id з запиту

• authorize_with = null

Відобразити відповідь

Відобразити відповідь у відповідності до специфікації.