Для забезпечення приватності та покращення якості вказаних особистих даних (адреса проживання, контактний телефон, email) учасників аукціонів у публічному АРІ процедури, а також для запобіганню використання зазначеної інформації у маркетингових активностях (небажані дзвінки, сповіщення, розсилки), внесено зміни у логіку роботи API ЦБД і повертати відповідь з Контактною інформацІєю виключно користувачам-власникам Обʼєктів Процедури/Біда.
Загальна інформація
На сервісі Процедур необхідно поля
- bids[*].bidders[*].contactPoint.email
- bids[*].bidders[*].contactPoint.telephone
- bids[*].bidders[].address.*
awards[*].buyers[*].contactPoint.email
awards[*].buyers[*].contactPoint.telephone
awards[*].buyers[*].address.*
contracts[*].buyers[*].contactPoint.email
contracts[*].buyers[*].contactPoint.telephone
contracts[*].buyers[].address.*
- questions[*].author.email
- questions[*].author.telephone
- currentTenants.address.*
- previousAuctionBidder.address.*
відображати у вигляді "зірочок" для користувачів, які не є власниками цього обʼєкта.
Приклад відображення:
Логіка відображення КІ
Отримання контактних даних учасників у межах процедури має здійснюватись на основі авторизаційного токена (broker token)
Отримання контактних даних учасників НЕ має здійснюється на основі токенів доступу до обʼєктів (acc_token)
Рішення щодо доступу до Контактної інформації учасників приймається на основі:
- токена майданчика (broker token)
- належності обʼєкта до відповідного майданчика
Наприклад, при виконанні запиту GET /api/procedures/{id} з токеном майданчика в header:
- ЦБД визначає майданчик на основі broker token
- для кожного обʼєкта у процедурі:
- якщо обʼєкт був створений з цим broker token — контактні дані відкриваються
- якщо обʼєкт був створений Не з цим broker token — контактні дані залишаються прихованими.
Критерієм належності обʼєкта до майданчика є ідентифікатор власника обʼєкта - owner, що співпадає з майданчиком, з токеном якого виконується запит.
Важливо
Варто враховувати логіку роботи GET запитів, яка описана ТУТ
При виконанні GET запиту до обʼєкта з:
broker_token + acc_token + | відкриті | Якщо в запиті присутній коректний broker_token, то КІ має бути доступна |
broker_token + acc_token - | відкриті | Якщо в запиті присутній коректний broker_token, то КІ має бути доступна |
broker_token - acc_token + | закриті | Якщо в запиті відсутній коректний broker_token, то КІ має бути НЕдоступна |
Майданчикам
Майданчик не зобовʼязаний виконувати окремі запити з токенами кожного біда для отримання контактних даних власних учасників.
Достатньо одного запиту до процедури з використанням broker token для майданчика-власника декількох бідів, щоб отримати по всім одразу відкриту КІ.
АЛЕ це правило не порушує загальну існуючу логіку повернення інфор мації про Біди, яка описана тут
ВАЖЛИВО На прикладі:
Майданчик є власником Процедури і Біда в цій процедурі.
ДО моменту публічного відкриття інформації про Біди:
Для отримання інформації про Біда - необхідно робити запит з використанням acc_token цього біда, згідно Логіка роботи GET запитів
З моменту публічного відкриття інформації про Біди:
Як власник обʼєкта "верхнього" рівня - процедури, Майданчик при запиті отримає КІ по всіх бідам (і своїм і чужим)
На інтерфейсі, в кабінеті Біда необхідно буде власнику біда відображати КІ свою і НЕ показувати КІ інших учасників.
Тобто, API віддасть всю КІ Майданчику-власнику Процедури. А ось Майданчик вже робить на своїй стороні логіку "кому що показати" і логіка має відображати користувачам тільки "свою" КІ.
Важливо
Приклад:
broker_1 опублікував Процедуру
broker_2 опублікував Біда до Процедури
broker_3 опублікував Запитання до Процедур
| Статус процедури | broker_1 | broker_2 | broker_3 |
|---|---|---|---|
active_rectification active_tendering active_auction | Не бачить Бідів | Бачить кожного свого Біда окремо з обовʼязковим використанням acc_token КІ своїх Бідів деанонімізована Не бачить чужих Бідів | Не бачить Бідів |
active_qualification paused complete unsuccessful cancelled | Бачить всіх Бідів КІ всіх бідів деанонімізована | Бачить всіх Бідів КІ своїх Бідів деанонімізована КІ чужих Бідів анонімізована | Бачить всіх Бідів КІ всіх Бідів анонімізована |
Логіка Mirror
Клієнт, який підключений до Mirror має отримувати контактну інформацію обʼєктів, де він є власником цього обʼєкта (object.owner == broker token)
В розрізі Контактної Інформації існує чотири типи Брокерів:
- Власник Процедури_А
- Власник Біда до Процедури_А
- Власник Запитання до Процедури_А
- Broker, який НЕ є стороною Процедури_А
Сценарії
- broker_1 опублікував Процедуру_А
- broker_2 опублікував два біда (bid_21, bid_22) до Процедури_А.
- broker_3 опублікував одного біда (bid_31) до Процедури А.
- broker_4 опублікував запитання до Процедури_А
- broker_5 НЕ опублікував жодного Біда і жодного Питання до Процедури_А. Він не є стороною Процедури_А
Всі brokers підключені до Mirrror зі своїми авторизаційними даними.
Після завершення роботи Модуля Аукціону Біди стають публічно доступними і в Mirror всім прилітає обʼєкт
Expected result:
| Actor/object | bid_21 | bid_22 | bid_31 | question | Description |
|---|---|---|---|---|---|
| broker_1 | бачить КІ | бачить КІ | бачить КІ | бачить КІ | broker_1 отримує в Mirror обʼєкт процедури, в якому дані НЕ анонімізовані (бо він є власником Процедури, як батьківського обʼєкта) Всі Біди і Запитання є дочірніми обʼєктами до його Процедури. |
| broker_2 | бачить КІ | бачить КІ | - | - | broker_2 отримує в Mirror обʼєкт процедури, в якому дані НЕ анонімізовані для bid_21 та bid_22 (бо він є власником обох Бідів) та анонімізовані для bid_31 |
| broker_3 | - | - | бачить КІ | - | broker_3 отримує в Mirror обʼєкт процедури, в якому дані НЕ анонімізовані для bid_31 і анонімізовані по bid_21 та bid_22 |
| broker_4 | - | - | - | бачить КІ | Не є власником Процедури і не є власником жодного біда Є власником Запитання і бачить КІ в своєму запитанні |
| broker_5 | - | - | - | - | Не є власником Процедури, не є власником жодного біда, не є власником запитання. broker_5 отримує в Mirror обʼєкт процедури, в якому дані АНОНІМІЗОВАНІ по всім бідам (бо він не є їх власником) |
Тобто, якщо Майданчик є власником одного біда в процедурі, то в mirror він має отримувати обʼєкт в якому відкрита КІ тільки по його біду і не відкрита КІ по іншим бідам цієї ж процедури, бо він не є власником інших бідів. (бага)
Правила відображення інформації на майданчиках
Контактна інформація учасників процедури є конфіденційною інформацією та не повинна відображатися публічно.
У публічному API та у відповідях, які не призначені для власника відповідного обʼєкта, значення Контактної інформації мають повертатися у прихованому вигляді, наприклад як "*****" або в іншому форматі маскування, який не дозволяє відновити оригінальне значення.
Якщо сторінка доступна неавторизованому користувачу або є публічною вітриною Майданчика, усі поля Контактної інформації повинні бути приховані.
| Сценарій | Очікуване відображення |
|---|---|
| Користувач переглядає процедуру на публічній сторінці Майданчика | Контактна інформація прихована |
| Майданчик є власником процедури, але сторінка публічна | Контактна інформація все одно прихована |
| Майданчик є власником біда, але сторінка публічна | Контактна інформація все одно прихована |
| Майданчик не є стороною процедури | Контактна інформація прихована |
Відображення Контактної інформації у кабінеті Організатора
У кабінеті Організатора Контактна інформація учасників може відображатися лише у випадку, якщо Майданчик, через який Організатор працює з процедурою, є власником цієї процедури.
Технічно це означає:
procedure.owner == broker, визначений за broker token
Якщо Майданчик є власником процедури, він може відобразити Організатору Контактну інформацію по обʼєктах цієї процедури, зокрема по бідах, учасниках, awards/contracts, якщо така інформація доступна у відповіді ЦБД.
| Умова | Результат |
|---|---|
| Майданчик є власником процедури | У кабінеті Організатора можна відображати КІ учасників цієї процедури |
| Майданчик не є власником процедури | У кабінеті Організатора КІ учасників не відображається |
| Користувач не авторизований як Організатор цієї процедури | КІ не відображається |
Відображення Контактної інформації у кабінеті Учасника
У кабінеті Учасника Майданчик має право відображати тільки Контактну інформацію самого Учасника, тобто інформацію з обʼєктів, власником яких є цей Майданчик.
Правило
bid.owner == broker, визначений за broker token
Якщо умова виконується — КІ по цьому біду може бути відображена в кабінеті Учасника.
Якщо умова не виконується — КІ по цьому біду повинна бути прихована.
| Сценарій | Очікуване відображення |
|---|---|
| Учасник переглядає власний bid у своєму кабінеті | КІ цього учасника відображається |
| Учасник переглядає процедуру з іншими бідами | КІ інших учасників прихована |
| Майданчик має декілька власних бідів у процедурі | КІ відкривається лише по власних бідах цього Майданчика |
| Майданчик не має власних бідів у процедурі | КІ всіх учасників прихована |
Матриця
| Місце відображення | Хто переглядає | Умова доступу | Чи показувати КІ |
|---|---|---|---|
| Публічна сторінка процедури | Будь-який користувач | Не має значення | Ні |
| Публічна сторінка процедури | Майданчик-власник процедури | Навіть якщо procedure.owner == broker | Ні |
| Кабінет Організатора | Організатор процедури | procedure.owner == broker | Так |
| Кабінет Організатора | Організатор не через Майданчик-власник | procedure.owner != broker | Ні |
| Кабінет Учасника | Учасник власного біда | bid.owner == broker | Так, тільки власна КІ |
| Кабінет Учасника | Учасник переглядає інших учасників | other_bid.owner != broker | Ні |
| Кабінет Майданчика-власника question | Власник question | question.owner == broker | Так, тільки по власному question |
Доступ до Контактної Інформації у BI
BI є звичайним клієнтом ЦБД і, відповідно, має свій Токен.
При підключені до mirror з авторизацією, ВІ може забирати обʼєкт з полями Контактної Інформації.
- Бізнес мета: Авторизовані користувачі ВІ з спеціальною роллю мають можливість на окремому дашборді бачити Контактну Інформацію по всіх Процедурах. Маркетинг Prozorro.Sale використовує КІ для проведення комунікацій з Учасниками (Бідами).
- Логіка відображення КІ залишається на стороні ВІ. Нам необхідно розробити можливість для BI від mirror отримати обʼєкт ЦБД з КІ.
- Ми цю можливість надаємо ідентифікуючи BI по broker token-у
Анонімізація ТУТ