Защита цены в Airtable: почему запрет редактирования не скрывает данные
Как разделить изменение значений, настройку полей и видимость данных Airtable при работе с ценами и согласованием карточек.
Содержание статьи
Ограничение редактирования поля Airtable защищает значение от определённых правок, но не делает цену или себестоимость невидимой для участников базы. Ещё одно различие: право менять ячейку не совпадает с правом менять тип поля и его настройки. При настройке согласования цен эти уровни нужно проверять отдельно, иначе удобный интерфейс создаст ложное ощущение защищённого процесса.
Разделите три разных полномочия
Первое полномочие — видеть данные. Второе — менять значение у конкретного товара. Третье — менять саму структуру поля: название, тип или допустимые варианты. Для обычного менеджера может быть достаточно второго права в нескольких рабочих полях, тогда как настройка структуры остаётся у ответственного за базу.
Поле с расчётной ценой также может быть недоступно для прямой правки по другой причине: Formula, Lookup и Rollup вычисляются на основе исходных данных. Не выдавайте дополнительные права только потому, что сотрудник не может ввести число в результат формулы. Сначала проверьте условия вычисления связанных показателей.
Настройте конкретный рабочий переход
Составьте таблицу полей: предлагаемая цена, утверждённая цена, причина изменения и отметка согласования. Решите, кто заполняет каждое поле. Владельцы и создатели базы на поддерживаемых планах могут ограничить изменение содержимого через Edit field permissions, а создание и удаление записей — через настройки таблицы.
Если право изменения закреплено за интеграцией, проверьте пользователя, от имени которого она работает. В документации предусмотрено ограничение на пользователя персонального токена или автора OAuth-подключения. Общая учётная запись, которой пользуются и люди, и несколько систем, усложняет понимание границ: разрешение фактически относится ко всем её действиям.
Проверьте интерфейс и внешнее обновление
Права полей распространяются на интерфейсы, мобильные приложения, расширения и API. Поле может выглядеть доступным в интерфейсе, но изменение будет запрещено правилами базы. Поэтому проверяйте не только вид кнопки, а фактическое сохранение под нужной ролью. Для импорта выполните отдельный тест на небольшой группе товаров.
Испытайте разрешённую правку и правку, которая должна быть отклонена. Затем убедитесь, что менеджер продолжает выполнять обычные задачи: добавлять описание, проверять фото и вести комментарии. При обмене через CSV полезен контроль ключа обновления, поскольку корректные права не исправляют ошибочное сопоставление строк.
Проверьте видимость отдельно от редактирования
Если подрядчик вообще не должен видеть себестоимость, запрет редактирования этого поля недостаточен. Потребуется подходящая схема ограниченного представления данных или интерфейсного доступа. Не добавляйте человека ко всей базе, рассчитывая скрыть коммерческие сведения одним замком возле названия столбца.
После настройки сохраните описание ролей и ответственного за изменение правил. Владельцы и создатели способны пересматривать ограничения, поэтому регламент должен учитывать и эти полномочия. Приёмка завершена, когда каждый участник выполняет нужную операцию, запрещённая правка действительно не сохраняется, а видимость данных проверена независимо. Такой подход помогает локализовать ошибку доступа до массового изменения цен.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы