Перейти к содержимому

Каталог таблиц: пользовательские формы и интеграции

Обновлено:

Раздел «Каталог таблиц» в личном кабинете позволяет создать собственную таблицу данных, которую можно использовать из конструктора через JavaScript. Это отдельный механизм для интеграций и нестандартных форм: заявки на помощь, внутренние обращения, анкеты, дополнительные статусы и другие данные, которых нет в стандартной форме заявки.

В отличие от обычного каталога материалов или элементов, таблица не описывает мебель. Она хранит записи произвольной структуры: набор полей задаётся вами, а каждая отправленная форма становится отдельной записью.

Откройте личный кабинет и перейдите в:

«Каталог таблиц» → «Список таблиц»

На странице отображаются созданные таблицы. Для каждой таблицы используется:

  • название — видно администратору и пользователю в меню;
  • ключ — техническое имя, по которому таблица вызывается из JavaScript и API;
  • набор полей — структура формы и данных записи.

Ключ должен быть коротким, уникальным и написан латиницей без пробелов. Например: support_requests, dealer_sos, callback_forms.

Таблица состоит из полей. Для каждого поля задаются:

  • Название — текст, который увидит пользователь;
  • Код — техническое имя поля; его использует JS при чтении и записи;
  • Тип поля — например, текст, список, флажок или кнопка;
  • Обязательность — нужно ли заполнить поле перед отправкой;
  • Проверка обязательности — каким образом проверять заполнение;
  • Активность — показывать поле или временно скрыть его;
  • Порядок — позиция поля в форме и таблице;
  • Значения — варианты для поля-списка.

Код поля также следует писать латиницей, цифрами и символом _, например question, dealer_id, urgency. Не меняйте код после запуска интеграции без необходимости: внешний JS и уже сохранённые записи обращаются к полю именно по этому коду.

В таблицу можно добавить готовые поля PlanPlace:

  • project_number — номер записи;
  • project_img — изображение проекта;
  • spec_link — ссылка на PDF-спецификацию;
  • project_link — ссылка на файл проекта DBX;
  • user — авторизованный пользователь;
  • user_guid — идентификатор пользователя внешней системы;
  • project_select — кнопка выбора сохранённого проекта.

Если в форме присутствуют project_link или project_select, конструктор может автоматически подготовить файл проекта. Если добавлено поле project_img, при отправке прикладывается изображение сцены. Для spec_link генерируется PDF-спецификация.

Само создание таблицы ещё не показывает её пользователю. Чтобы дизайнер или клиент мог вызвать форму из конструктора:

  1. Создайте таблицу и настройте её поля.
  2. Откройте раздел «Настройка меню планировщика».
  3. Добавьте в нужное меню действие, связанное с таблицей.
  4. Выберите действие сохранения в таблицу (show_save_custom_table) или просмотра записей (show_list_custom_table).
  5. Передайте действию технический ключ таблицы.
  6. Сохраните меню и проверьте его на сцене.

Для одной таблицы можно добавить два действия: одно открывает форму новой записи, второе показывает список ранее отправленных записей.

Внутренние действия вызываются так:

pp.interface.root.$emit('show_save_custom_table', {
key: 'support_requests',
heading: 'Сообщить о проблеме',
button: 'Отправить'
});
pp.interface.root.$emit('show_list_custom_table', {
key: 'support_requests',
heading: 'Мои обращения'
});

На практике обычно используют не прямой вызов из консоли, а действие меню или кнопку, добавленную через пользовательский JS.

При отправке формы конструктор:

  1. Проверяет обязательные поля.
  2. Собирает данные проекта и формы в JSON.
  3. При необходимости формирует DBX, изображение сцены и PDF.
  4. Отправляет данные в config/index.php/api/custom_table/add.
  5. Получает ID новой записи.
  6. Запоминает выбранную запись и может перевести конструктор в режим работы с ней.

Если запись уже была выбрана, повторная отправка обновляет её, а не создаёт новую. Это позволяет открыть обращение или проект, изменить данные и сохранить результат обратно в ту же строку.

Ключ таблицы передаётся параметром table_key.

POST /config/index.php/api/custom_table/add
Content-Type: multipart/form-data

Основные поля запроса:

  • table_key — ключ таблицы;
  • data — JSON со структурой записи;
  • user — email авторизованного пользователя, если он вошёл в PlanPlace;
  • user_guid — идентификатор пользователя внешней системы;
  • id — ID существующей записи для обновления;
  • файлы project_link, project_img, spec_link — если таблица предусматривает вложения.

Успешный ответ:

{
"status": "success",
"item_id": 123
}
GET /config/index.php/api/custom_table/get?table_key=support_requests&id=123

Ответ содержит item с сохранённой структурой JSON.

GET /config/index.php/api/custom_table/list?table_key=support_requests&page=1&limit=20

Поддерживаются параметры:

  • page — номер страницы;
  • limit — количество записей;
  • filter_field и filter_value — простой фильтр по одному полю;
  • filters — JSON-массив фильтров;
  • filters_mode=and или filters_mode=or — объединение фильтров.

Пример нескольких фильтров:

GET /config/index.php/api/custom_table/list?table_key=support_requests&filters_mode=and&filters=[{"field":"status","value":"new"},{"field":"dealer_id","value":"dealer-17"}]

Ответ содержит items и данные пагинации:

{
"status": "success",
"items": [],
"pagination": {
"total_count": 0,
"total_pages": 0
}
}
GET /config/index.php/api/custom_table/count?table_key=support_requests

Ответ:

{
"status": "success",
"count": 12
}
POST /config/index.php/api/custom_table/update
Content-Type: multipart/form-data

Передайте table_key, id и новое значение data.

POST /config/index.php/api/custom_table/delete
Content-Type: multipart/form-data

Передайте table_key и id удаляемой записи. Удаление необратимо штатными средствами.

Простая авторизация для внешнего сайта или iframe

Заголовок раздела «Простая авторизация для внешнего сайта или iframe»

Для сценария, когда PlanPlace открыт внутри сайта или iframe, можно использовать простой внешний идентификатор пользователя вместо полноценного входа в личный кабинет.

Интеграция передаёт в конструктор уникальный user_guid, после чего пользовательский код вызывает:

pp.interface.root.$up.login_simple_auth('external-user-42');

Этот режим не создаёт аккаунт PlanPlace и не заменяет полноценную авторизацию. Он только сообщает конструктору, к какому внешнему пользователю относятся записи.

При сохранении значение записывается в поле user_guid. При открытии списка таблица автоматически добавляет фильтр по этому полю. Поэтому каждый пользователь получает только свои записи, если интеграция всегда передаёт стабильный и уникальный идентификатор.

  • значение должно быть уникальным в вашей системе;
  • один и тот же пользователь должен получать один и тот же идентификатор;
  • нельзя использовать общий идентификатор для всех посетителей;
  • не передавайте в нём пароль или другой секрет;
  • если идентификатор можно подменить на стороне клиента, не используйте этот механизм как единственную защиту конфиденциальных данных.

Для строгой серверной безопасности нужна отдельная авторизация и серверный посредник, который проверяет пользователя до обращения к данным.

Таблицу можно использовать для кнопки «Нужна помощь» или «SOS» внутри конструктора.

Пример структуры:

ПолеКодНазначение
Темаsubjectкороткое описание проблемы
Сообщениеquestionподробности для поддержки
Срочностьpriorityобычная, срочная, критичная
Дилерdealer_idидентификатор дилера
Проектproject_linkссылка на DBX-проект
Изображениеproject_imgснимок текущей сцены

Кнопка открывает форму таблицы. После отправки специалист получает запись с вопросом, проектом и изображением, а не пытается восстановить ситуацию по тексту переписки.

Если у каждого дилера есть отдельный пользовательский идентификатор, его можно записывать в user_guid и показывать дилеру только его обращения. Владелец или отдельный интерфейс поддержки может получать полный список через API с серверной проверкой доступа.

Таблица может быть хранилищем заявок для отдельной страницы компании, встроенной рядом с PlanPlace или открывающейся внутри iframe. Внешняя страница:

  1. получает от своей системы идентификатор пользователя;
  2. передаёт его в конструктор через простой auth-режим;
  3. открывает форму сохранения записи;
  4. получает список заявок по user_guid;
  5. открывает выбранный проект по project_link;
  6. показывает статус и дополнительные поля из записи.

Так можно сделать собственный кабинет заявок, не меняя стандартную форму PlanPlace. При этом HTML и JS внешней страницы остаются вашей зоной ответственности: таблица предоставляет структуру хранения, фильтрацию и связь записи с проектом.

  • Не вставляйте ключ таблицы и пользовательские данные в публичный код, если это даёт доступ к чужим записям.
  • Простая авторизация по user_guid — это идентификация, а не полноценная защита от подмены.
  • Проверяйте данные на внешнем сервере до отображения оператору или отправки в CRM.
  • Не храните в свободных текстовых полях пароли, токены и платёжные данные.
  • Перед изменением схемы таблицы сохраните список полей и проверьте совместимость пользовательского JS.
  • Не удаляйте поле, которое используется фильтрами, кнопками меню или интеграцией.

table_keys — это конструктор пользовательских таблиц. Ключ таблицы задаёт отдельное хранилище, поля задают структуру формы, а действия меню открывают сохранение или список записей. Через api/custom_table внешняя страница или JS могут создавать, читать, фильтровать, обновлять и удалять записи. Для работы внутри iframe предусмотрен простой режим привязки записей к внешнему пользователю через user_guid; его следует считать удобным механизмом фильтрации, а не полноценной системой безопасности.