LawMatic B2 — локальная работа и синхронизация (общие принципы)

Здесь описана общая модель данных и обмена для LawMatic B2 на всех платформах. Конкретные экраны, меню и ограничения ОС приведены в разделах Платформы (macOS, Windows, Android, iOS).

Главная идея: данные сначала у вас

Приложение опирается на локальную базу данных (файл на устройстве или выделенное хранилище в мобильных клиентах — формулировка зависит от платформы). Вы работаете с контактами, делами, задачами, финансами и связанными сущностями без обязательного постоянного интернета.

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

Два режима работы

Локальный режим (без синхронизации с сервером)

Данные остаются на устройстве, автоматическая отправка на общий сервер отключена.
Удобно для одной машины, теста или работы в изолированной среде.
В коде и интерфейсе заложена возможность переносить базу файлами между компьютерами там, где клиент это поддерживает (см. ниже) — это не то же самое, что серверная синхронизация.

Синхронизация через сервер

Указывается адрес сервера совместимого API (в экосистеме LawMatic / Legalic часто используется общий хост, либо свой сервер с тем же протоколом).
Доступ к API оформляется парой API Key и API Secret (их выдаёт администратор или личный кабинет — в зависимости от вашей схемы подключения).
После настройки клиент может забирать изменения с сервера и отправлять локальные правки (контакты, дела, задачи, база знаний и др. — в составе конкретной версии приложения).

Между платформами именно этот режим даёт «общую картину»: Mac, Windows, телефон и планшет с одной и той же учётной записью API и одним сервером обмениваются данными через центральный узел, а не напрямую друг с другом.

Сервер LEGALIC и домены

В экосистеме LawMatic этим центральным узлом выступает платформа LEGALIC — серверная часть и онлайн-доступ (веб), размещаемые на отдельном домене от сайта документации docs.lawmatic.ru. Именно к узлу LEGALIC (или к совместимому экземпляру с тем же API) клиенты подключаются в настройках синхронизации.

Кратко о продукте и его месте в архитектуре: раздел LEGALIC — обзор.

Как устроена «авторизация» для синхронизации

Во всех клиентах смысл один: это не классический логин и пароль в форме входа (как на сайте), а привязка приложения к API:

Ввод API Key и API Secret.
Запрос токена у сервера (по схеме вроде client credentials).
Дальнейшие запросы к API с этим токеном и, при необходимости, заголовками с ключами — в зависимости от реализации клиента.

После успешной привязки приложение получает профиль пользователя с сервера (идентификатор, имя и т.д.) и использует его при создании записей и при синхронизации.

Что происходит при синхронизации с сервером

В типичном цикле (детали и порядок шагов могут слегка отличаться по платформе):

Обновление токена и проверка доступа.
Загрузка с сервера изменённых сущностей (контакты, дела, задачи, знания, при необходимости мониторинг и др.).
Выгрузка на сервер локальных изменений, помеченных как требующие отправки.

Синхронизацию можно запускать вручную и/или по расписанию (интервалы вроде 15–180 минут — смотрите настройки клиента). Нужен доступ в интернет.

Запись «только локально»

Даже при включённом сервере отдельные объекты можно помечать так, чтобы они не уходили на сервер (переключатели запрета синхронизации в карточках, фильтры «только локальные» / «ожидают синхронизации» и т.п. — названия зависят от платформы). Это не противоречит общей модели: серверу отдаётся только то, что разрешено правилами записи и режимом.

Идентификаторы пользователя и авторов

Записи привязаны к GUID пользователя. Если локальные данные создавались с некорректным GUID автора, сервер может отклонять синхронизацию таких строк. После успешного получения профиля с сервера в настройках (на поддерживаемых клиентах) доступны инструменты диагностики и исправления таких GUID.

Обмен данными через файлы (в дополнение к серверу)

Имеет смысл разделять два уровня.

1. Файл основной базы (полный снимок CRM)

На десктопах приложение обычно работает с отдельным файлом базы. Перенос «как есть» на другой компьютер — это копирование этого файла и открытие его в приложении (с предварительным закрытием программы на обеих сторонах, чтобы не повредить файл).

Важно:

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

В локальном режиме перенос файла — естественный способ сменить компьютер или сделать архивную копию.

2. Вспомогательные файлы (например, настройки ИИ)

На отдельных платформах (в первую очередь macOS) может быть обмен не CRM-данными, а конфигурацией ИИ через выбранную папку и файл вроде ai_settings.json. Это отдельный канал, не смешивайте его с синхронизацией контактов и дел.

Подробности — в разделе про вашу ОС.

Сводка

Вопрос	Ответ
Где живут основные данные?	Локально, в базе на устройстве (или в хранилище клиента)
Как связать телефон и компьютер?	Один сервер + одна пара API Key / Secret (режим синхронизации через сервер)
Можно без сервера?	Да, локальный режим
Как перенести всё на другой ПК без сервера?	Где поддерживается — копирование файла базы и открытие в приложении
Сервер видит всё подряд?	Нет — только то, что не помечено как «только локально» / без запрета выгрузки

Дальше: LEGALIC (сервер) · macOS · Windows · Android · iOS · ← обзор B2