Как принять перенос календарей и контактов с Яндекса

Календари и контакты с Яндекса я принимаю после тестового импорта: сверяю события, поля карточек, права и обмен изменениями между устройствами. Файлы ICS и vCard сами по себе ничего не гарантируют. Ниже — проверка выгрузки и журнал приёмки, который помогает найти потери до отключения исходной учётной записи.

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

Я начинаю с реестра данных: сотрудник, исходная учётная запись, название календаря, его владелец, назначение, получатели доступа и будущий адрес ресурса. В проекте по переносу корпоративной почты этому нужен отдельный этап приёмки. Строка «почта перенесена» не объясняет, что стало с расписанием. Я прошу открыть каждый используемый календарь и адресную книгу. Важно увидеть, где хранятся данные: в веб-сервисе, локально на компьютере или в другой учётной записи телефона. Название приложения этого не доказывает. Для локального источника в реестре появляется собственный способ выгрузки; проверка одного Яндекса его не охватывает.

Затем я определяю границы проверки. Если переносим всю историю, фиксируем этот объём; если только согласованный период, записываем его начало и конец, а полную исходную выгрузку сохраняем отдельно. Счётчики сравниваем в одинаковых границах и в одном часовом поясе. Для повторяющихся встреч заранее договариваемся, что считаем: записи серий или показанные в периоде отдельные встречи. Числа из разных представлений нельзя ставить рядом и объявлять результат успешным. В реестре я оставляю место для исключений: что намеренно исключено из переноса, кто это согласовал и где осталось доступно исходное содержимое.

Общий календарь получает отдельную строку, даже если виден у каждого сотрудника. Я записываю, кому он принадлежит и кто сможет сделать выгрузку. Личные контакты, общий справочник сотрудников и локальные карточки тоже разделяю: это разные источники. После проверки у каждой строки должны быть ответственный и доказательство результата — файл, снимок настроек или запись теста. Формулу «все вроде пользуются» в акт не принимаю: у неё удивительно плохая поисковая выдача. Такой реестр позволяет заранее заметить недоступного владельца, лишний источник и ресурс, для которого на новой площадке ещё не определено место.

• Зафиксировать владельца каждого календаря и источник каждой адресной книги.
• Согласовать объём истории и способ подсчёта событий.
• Записать разрешённые действия пользователей с общими ресурсами.
• Назначить ответственного за проверку каждой строки реестра.

Где выгрузить календарь и контакты в Яндексе

Для календаря я открываю его настройки через меню рядом с названием на левой панели, затем вкладку «Экспорт» и вариант iCal. Полученную ссылку открываю в новой вкладке и сохраняю файл .ics. Это процедура из справки Яндекс Календаря; общий раздел аккаунта «Экспорт данных» её не заменяет. Если календарей несколько, проверяю выгрузку каждого ресурса по реестру. Рядом с файлом фиксирую владельца, время выгрузки и название исходного календаря. Ссылку и сам файл не публикую: в событиях могут быть адреса участников, описание встречи и другие рабочие сведения. Доступ к архиву получает тот, кто выполняет перенос и проверяет результат.

Есть ограничение, которое ломает красивый план централизованного экспорта: ссылки iCal и HTML в Яндексе доступны только владельцу календаря. Пользователю с предоставленным доступом справка предлагает ссылку CalDAV. Поэтому доступ на просмотр общего расписания не означает возможность получить его ICS этим способом. Я заранее привлекаю владельца либо отдельно проверяю подходящий способ извлечения данных. Нельзя просто попросить каждого сотрудника выгрузить всё видимое: появятся повторные копии одних ресурсов, а часть других останется без выгрузки. У каждого файла должен быть один понятный источник. Команды для работы с протоколами разобраны в статье про перенос через CalDAV и CardDAV.

Почтовые контакты выгружаю из Яндекс Контактов: меню «⋯» в левом верхнем углу, «Экспортировать», затем «Сохранить». По актуальной справке получается файл vCard. Там же прямо указано, что контакты организации выгрузить нельзя. Поэтому я не обещаю получить общую адресную книгу сотрудников нажатием этой кнопки. Для неё заранее определяю отдельный способ формирования на принимающей стороне и проверяю его с администратором. Если у сотрудника часть карточек хранится только в телефоне или локальной программе, эти записи также требуют отдельной работы. Экспорт должен покрывать согласованные источники, а не просто завершаться скачиванием хоть какого-нибудь файла.

Оригиналы выгрузок я сохраняю без изменений, а преобразования делаю на копиях. Отдельно записываю, какие исходные файлы использованы в тесте и какие — в окончательной загрузке. Импорт ICS является разовым копированием; последующие изменения источника сами в него не попадут. Подписка на календарь по ссылке — другой режим работы, который сохраняет зависимость от источника. Поэтому перед окончательной выгрузкой согласую паузу в изменении данных, а для срочных правок завожу журнал. Туда записываю автора, ресурс и содержание изменения. Этот список помогает закончить перенос, не запуская вслепую ещё один полный импорт поверх уже проверенных данных.

Как проверить ICS: серия, исключение и время встречи

Сначала я загружаю копию ICS в отдельный тестовый календарь и открываю заранее выбранные события. В набор беру обычную встречу, событие на весь день, повторяющуюся серию с концом, отменённый экземпляр и экземпляр, перенесённый на другое время. Добавляю встречу с участниками и напоминанием. Это мой набор приёмки, а не обещание одинакового поведения всех календарных программ. Для каждого примера записываю исходную дату, ожидаемое время, участников и результат в принимающей системе. Если событие не прошло проверку, сохраняю описание расхождения до попытки исправления. Скриншот пустой недели без указания периода такой записи не заменит.

Когда результат расходится, смотрю структуру iCalendar по RFC 5545. UID идентифицирует событие, RRULE описывает правило повторения, EXDATE исключает даты из набора повторений, а RECURRENCE-ID указывает конкретный экземпляр серии по его исходному времени начала. Последнее важно для перенесённой встречи: её новое время и идентификатор экземпляра решают разные задачи. Я сравниваю исходную выгрузку с результатом импорта, а не объявляю любую строку с пятничной датой правильной. Если программа создала новые идентификаторы, это требует отдельной проверки связей; совпадение названий не доказывает сохранность серии. Сам файл при диагностике не правлю, чтобы не потерять исходные данные.

Дата начала описывается DTSTART; TZID задаёт связь локального времени с часовым поясом, а время с окончанием Z представлено в UTC. Напоминания могут описываться компонентом VALARM. Наличие этих элементов не доказывает, что принимающее приложение использовало их так, как ожидает пользователь. Поэтому я проверяю фактическое отображение встречи и срабатывание уведомления. Для события на весь день важна дата без неожиданного смещения, для встречи с временем — согласованный момент начала. Отдельно смотрю, сохранились ли описание, место и список участников. Такие проверки я провожу в веб-интерфейсе назначения, прежде чем разбирать поведение телефона или настольной программы.

Количество строк или блоков событий в ICS не равно количеству видимых встреч: серия может задаваться правилом и исключениями. Для проверки полноты я сравниваю расписание в согласованном периоде, затем выборочно открываю сложные события. Край периода тоже проверяю: там проще пропустить встречу, если фильтры заданы по-разному. Отдельный тест — повторно загрузить тот же файл в изолированный календарь и записать поведение конкретного импортёра. Один может сопоставить записи, другой создаст копии; полагаться на это без проверки нельзя. Если отменённая встреча вернулась, повторно импортировать весь архив на рабочие календари я не стану: сначала выясню причину на тесте.

Как сверить контакты и выбрать формат для получателя

Я не выбираю формат контактов по принципу «этот универсальнее». Яндекс отдаёт почтовые контакты в vCard, а нужный способ загрузки определяет принимающий продукт и его конкретный импортёр. В экспертной базе есть полезный контрпример: процедура миграции в документации Carbonio CE предусматривает календари в ICS и контакты в CSV. Это требование описанного способа миграции, а не утверждение обо всех интерфейсах Carbonio. Если выбран именно он, понадобятся подготовка CSV и проверка соответствия полей. Менять расширение .vcf на .csv бессмысленно: внутреннее содержимое от этого таблицей не станет. Исходный vCard я сохраняю и после преобразования.

Для нового Outlook и Outlook в браузере Microsoft описывает импорт контактов из CSV и рекомендует UTF-8, в том числе для кириллицы. Поэтому утверждение «CSV ломает русские имена, берите только vCard» я отвергаю. Я проверяю кодировку, заголовки столбцов и соответствие полей требованиям импортёра. Затем загружаю небольшой набор карточек и смотрю результат. Переименование столбца наугад проблему не диагностирует. Важно различать загрузку в адресную книгу на сервере и появление записей в конкретном приложении: это могут быть разные этапы. Если в программе настроена только почтовая учётная запись, я отдельно выясняю, откуда она получает контакты.

В проверочный набор я включаю карточку с русским именем, несколькими адресами, двумя телефонами, организацией и заметкой. Для каждой важной карточки сравниваю значения полей, а не только отображаемое имя. Ошибка преобразования может оставить число контактов прежним, но убрать дополнительный телефон или перенести должность в заметку. Отдельно смотрю группы и общие справочники: сохранность самих карточек ещё не подтверждает их прежнюю организацию. Числа «было» и «стало» записываю до чистки дублей. Если объединение записей согласовано, сохраняю таблицу соответствий и объяснение разницы. Иначе хороший отчёт получится ценой молча удалённых данных. Бухгалтерия такую творческую арифметику не заказывала.

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

• Сверить количество карточек до объединения дублей.
• Проверить имя, адреса, телефоны, организацию и заметки.
• Проверить кодировку CSV и соответствие столбцов.
• Отдельно принять общий справочник и группы контактов.

Как принять права доступа и синхронизацию

Права на календарь я принимаю отдельно от событий. Обычная выгрузка ICS не служит переносом серверного списка разрешений; на новой площадке я создаю ресурс, назначаю владельца и настраиваю доступ по реестру. Затем вхожу под обычными пользователями и проверяю разрешённые действия. Для читателя проверяю чтение и отказ при попытке редактирования, для редактора — создание и изменение встречи. Для пользователя без доступа проверяю отсутствие доступа. Просмотр занятости, подробностей и закрытых событий оцениваю по возможностям выбранного сервера. Названия ролей у продуктов различаются, поэтому я сопоставляю действия, а не похожие слова в выпадающем списке настроек.

После проверки в браузере подключаю клиент. Для mailcow в экспертной базе указаны отдельные адреса CalDAV и CardDAV; официальная документация уточняет типовые пути личных ресурсов: https://mail.example.com/SOGo/dav/user@example.com/Calendar/personal/ и https://mail.example.com/SOGo/dav/user@example.com/Contacts/personal/. Здесь example.com — учебный домен. Фактический адрес, особенно для общего календаря, я беру из интерфейса SOGo или документации своей установки. Это адреса ресурсов, а не команда переноса. Один успешно подключённый почтовый ящик ещё не подтверждает работу ни одного из них: IMAP обслуживает почту, для календарей и контактов требуется отдельный поддерживаемый способ обмена.

С Outlook я сначала уточняю приложение: классический Outlook для Windows, новый Outlook или другая платформа. В документации mailcow для классического варианта описан Outlook CalDav Synchronizer, а для нового Outlook прямо указано отсутствие поддержки CalDAV/CardDAV этим способом. Поэтому универсальной инструкции «поставьте плагин на старую версию» у меня нет. Сначала выбираю совместимую связку сервера и приложения и проверяю её на тестовой учётной записи. На Android и iOS также проверяю конкретное приложение и способ подключения. Само название мобильной системы не гарантирует, что нужная адресная книга и общий календарь будут работать с выбранным сервером.

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

• Проверить чтение, редактирование и отказ в доступе.
• Провести обмен изменениями между сервером и клиентом.
• Проверить общий календарь под учётной записью сотрудника.
• Убедиться, что клиент показывает данные нового источника.

Учебный пример: журнал приёмки для девяти рабочих мест

Покажу процедуру на учебном примере московской студии печати «Буква и лист» с 9 рабочими местами. Это условный разбор, а не отчёт о выполненном проекте. Для него задаю 9 личных календарей, один общий календарь «Заказы» у директора и личные адресные книги сотрудников. Получаются 10 календарей в реестре, если аудит не обнаружит дополнительных источников. Версию принимающей системы и приложения записываю при подготовке теста; заранее придумывать их ради убедительного кейса не стану. Общий календарь выгружает владелец, поэтому девяти копий «Заказов» от разных сотрудников в плане нет.

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

Строка журнала содержит ресурс, исходный файл, время выгрузки, объём проверки, результат, найденное расхождение, способ исправления и имя проверившего. Для календаря «Заказы» добавляю владельца и результаты проверки прав менеджеров. Для адресной книги отмечаю полноту полей и согласованные объединения карточек. Отдельно записываю изменения, появившиеся после выгрузки: их нужно перенести контролируемым способом и повторно проверить. Фраза «всё сошлось» допустима лишь после заполнения этих строк. Чек-лист общей сверки после переноса почты дополняет эту процедуру проверкой писем; успешная приёмка одного типа данных не закрывает другой.

Успешным итогом такого примера я считаю закрытые строки реестра, доступный общий календарь с проверенными разрешениями и подтверждённый обмен изменениями на рабочих устройствах. Это критерий результата, а не выдуманная статистика успеха. Переключение MX управляет доставкой почты и не переносит расписание или адресные книги. Исходный сервис я отключаю после согласованной приёмки, сохранения выгрузок и проверки возможности восстановления, а срок хранения копий определяю в плане работ. Перед завершением передаю ответственному инструкции и список известных ограничений. Тогда у компании остаётся проверяемый результат, к которому можно вернуться при вопросе о конкретной встрече или карточке.

Частые вопросы