Что делать, если пользователь
Принципиально проблема неразрешима, и вопрос лишь в рациональных действиях по выходу из этой неприятной ситуации...
Следует предупреждать пользователя о необходимости делать копии его ID-файла перед внесением в него любых изменений и после этого. В некоторых случаях допустимо иметь архив ID-файлов пользователей. Один из вариантов организации такого архива рассматривается в 9.6. Если архив имеется, воспользуйтесь им. Однако это "не спасет" в случае, если пользователь создал ключ шифрования, использовал его для шифрования документов в базах, но более никому не передал. Подобное может случиться с зашифрованной почтой и зашифрованными локальными базами данных, если пользователь "успел" изменить публичный ключ.
Если же копии ID-файла нет, остается только вновь зарегистрировать пользователя под его прежним именем.
· Откройте документ Person этого пользователя в общей адресной книге, запомните местоположение почтового ящика, затем закройте и удалите документ Person.
· Зарегистрируйте пользователя заново под прежним именем, указав TEMP.nsf в качестве файла почтового ящика.
· Исправьте в новом документе Person местоположение почтового ящика с TEMP.nsf на прежнее.
· Проверьте, что под новым ID-файлом удается "войти" в почтовый ящик пользователя.
· Удалите TEMP.nsf и передайте пользователю новый ID-файл.
