На цій сторінці - БД Клієнтів з трьома клієнтами, а також загальна БД Проєктів з шістьма проєктами - по два проєкти у кожного клієнта.
Наша мета - надати кожному з клієнтів доступ до його проєктів з нашої загальної БД Проєктів таким чином, щоб виключити можливість перегляду клієнтами проєктів один одного.
В Notion наразі це неможливо: для того щоб клієнт побачив свої проєкти йому потрібно відкрити доступ до бази проєктів, де містяться проєкти й інших клієнтів.
До баз даних, пропустити відео >>>
Як роблять користувачі Notion, але так робити не треба, можна переглянути в відео нижче. Логіка прикладу в відео повторюється в усіх способах створення клієнтських просторів, які можна знайти в інтернеті, і навіть додавання проміжкових баз даних, кнопок автоматизації та хитрих фільтрів - все це зводиться до відкриття загальної бази проєктів, без цього ніяк, але це не те що нам потрібно.
Існує просте рішення для того щоб відкрити доступ до відфільтрованої БД таким чином, щоб фільтри не можна було змінити, а отже, не можна було побачити записів в цій БД, які не відповідають умовам фільтру. Цей спосіб полягає в тому, що створюється батьківська БД, де є записи по всіх проєктах, потім в ній застосовується фільтр, умови якого вочевидь не виконуються (наприклад, виставляється фільтр з умовою, що назва проєкту є пустою), і додається Advanced filter, можна і з тією самою умовою (вона автоматично повторюється при застосуванні advanced filter), і після встановлення цих фільтрів БД є пустою. В такому вигляді БД публікується без можливості дублювання, і коли перейти на опубліковану БД - побачимо що всі записи приховані, можливості змінити фільтри і щось побачити немає.
⇒
Далі, використовуючи цю логіку, можна створювати відфільтровані представлення БД для клієнтів з додатковими фільтрами, застосовуючи саме advanced filter - клієнт за посиланням на опубліковану (теж без прав на дублювання) сторінку з його частиною БД побачить відфільтровані для нього записи, а при переході на батьківську БД не побачить там жодного запису, навіть своїх.
Якщо ви надасте права на дублювання - клієнт може зняти фільтри і більше не побачити своїх записів (поки ви не знімете і не поставите знову тег, за яким ви фільтрували йому представлення БД), тож повний доступ супроводжуйте чіткими інструкціями (та на мій погляд, клієнт взагалі не в тій ролі щоб отримувати інструкції що йому робити і чого - ні)
В цьому варіанті залишається ще один організаційний момент - клієнт може побачити назви тих параметрів, за якими ви відфільтрували БД для нього. Якщо він спробує додати такі параметри - нічого не зміниться, а якщо він спробує обрати всі окрім свого - він не побачить своїх записів, але в будь-якому випадку доступу до записів, які для нього не призначені вами, він не отримає. Якщо назви цих параметрів показувати не бажано (зазвичай фільтрують за іменами клієнтів або за назвами компаній-замовників) - дуже просто використати умовне кодування, коли кожному клієнту привласнюється певний ID, і фільтри виставляються саме по стовпчику з ID. Так клієнти отримають доступ до переліку незрозумілих ID в фільтрі і будуть впевнені, що інші ваші клієнти замість його імені також побачать такий чемний ID.
Це рішення може підходити для випадків, коли вам не потрібно давати клієнтам можливості щось змінювати в БД або додавати нові записи, і вам достатньо комфортно давати посилання на сторінку Notion клієнтам, які, можливо, не мали раніше справи з Notion, або, ймовірно, очікують не простору для занурень в таблиці рівня аналітика даних, а ключових даних верхнього рівня, які їм насправді важливо знати.
Та коли вам потрібно зробити так щоб клієнт відчував, що його сторінка - це його персональна сторінка, яка зроблена саме для нього і не є частиною чогось, де ще хтось (інші замовники) щось бачить чи робить, або якщо вам не потрібно показувати всі стовпці вашої БД клієнту, або ви хотіли би надати клієнту можливість щось записувати або змінювати - таке рішення не підходить.
Процес використання цих функцій ви можете оглянути на цьому відео:
З найкращими побажаннями,
Володимир Дьяченко з TEMPLOTION
