Skip to content

Latest commit

 

History

History
134 lines (104 loc) · 14.2 KB

userlink.md

File metadata and controls

134 lines (104 loc) · 14.2 KB

Работа со списком контактов

Данный документ описывает логику и сценарий работы по управлению списком контактов.

  1. Описание статусов пользователя
  2. Поиск пользователя
  3. Изменение статуса авторизации
  4. Обработка изменений статуса имеющихся контактов
  5. Работа с неавторизованными контактами
  6. Запрет/разрешение управления списком контактов

Описание статусов пользователя

Каждый контакт, который получает клиентское приложение в виде объекта user имеет следующие поля, описывающие состояние авторизации в списке контактов текущего пользователя:

// ---
    , link_status: string ('requested'|'received'|'rejected'|'accepted'|'withdrawn')
    , link_status_read: boolean (true|false)
    , link_status_date: timestamp
// ---

link_status - состояние авторизации

Для всех состояний кроме accepted пользователи не могут писать друг другу. У пользователя с таким статусом пустые следующие поля: first_name, last_name, avatar. В любых упоминаниях о пользователе в интерфейсе вместо first_name last_name отображается username.

  1. accepted - состояние, когда оба пользователя подтвердили авторизацию. Оба пользователя могут писать друг другу.
  2. withdrawn - состояние, когда текущий пользователь, либо его собеседник разорвал авторизацию. В окне с перепиской отображается уведомление об отмене авторизации.
  3. received - состояние, когда текущий пользователь получил запрос на авторизацию от другого пользователя. В окне с перепиской отображается уведомление о запрошенной у текущего пользователя авторизации.
  4. requested - состояние, когда текущий пользователь запросил авторизацию у другого пользователя. В окне с перепиской отображается уведомление о запросе авторизации текущим пользователем.
  5. rejected - состояние, когда собеседник отклонил запрос на авторизацию. В окне с перепиской отображается уведомление

link_status_read - отметка о прочтении статуса, ставится в true при изменении статуса, инициированного собеседником. Если был получен пользователь с непрочитанным статусом или пришло уведомление об изменении статуса, и если не открыта переписка с этим пользователем, то необходимо увеличиь счетчик непрочитанных сообщений у от данного пользователя.

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

Поиск пользователя

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

Если в списке контактов нет искомого пользователя, то появляется кнопка для активации глобального поиска:

После нажатия на кнопку активации глобального поиска в результатах поиска выводятся пользователи, которых нет в списке контактов. Запрос результатов поиска с сервера выполняется отправкой фрейма [find contacts](/socket.io/client-emited/userlink/find contacts.md)

При тапе на контакт из списка, контакту необходимо отпрвить запрос на авторизацию(Изменение статуса авторизации), после обработки ответа сервера переход на экран диалогов с пользователем:

Изменение статуса авторизации

Все запросы на изменение статуса авторизации выполняются отправкой socket.io фрейма [handle userlink](/socket.io/client-emited/userlink/handle userlink.md)

Обработка изменений статуса имеющихся контактов

Оповещения об изменении статуса авторизации сервер осуществляет двумя способами.

  1. [userlink update](/socket.io/server-emited/userlink update.md). Этот фрейм используется сервером в случаях изменения link_status, когда пользователь присутствует у текущего пользователя в контактах, но не авторизован. Примечание: для подтверждения авторизации другим пользователем и для запроса на авторизацию от пользователя, которого нет в списке контактов используется [user container](/socket.io/server-emited/user container.md).

  2. [user container](/socket.io/server-emited/user container.md).

  • В случае, если пользователь, которого нет в списке контактов, запрашивает авторизацию, необходимо получить всю информацию об этом контакте, в том числе список диалогов и сообщений (если когда либо была переписка с данным пользователем). first_name, last_name, avatar в данных отсутствуют. Статус установлен в received.
  • В случае, если пользователь, который есть в списке контактов, но еще не авторизован, подтвердил авторизацию, то приходит контейнер с данными пользователя со статусом accepted, но без диалогов и сообщений, так как они уже есть на клиенте.
  • В случае, если пользователь, которого нет в списке контактов, подтвердил авторизацию, то приходит контейнер со всеми данными пользователя со статусом accepted, в том числе список диалогов и сообщений (если когда либо была переписка с данным пользователем).

Работа с неавторизованными контактами

Для реализации работы с неавторизованными контактами, необходимо обратить внимание на следующие моменты:

  1. Если получен контакт со статусом авторизации отличным от accepted, то везде вместо first_name last_name отображается username.
  2. Вывод списка участников группы. Возможна такая ситуация, что участника группы нет в списке контактов (не путать с неподтвержденным статусом авторизации), но его нужно показать в списке участников. Для этого в объекте группы group для каждого участника указан username.
// Recipients example
Recipients: [
{
  "12":{id:12,username:"10002",domain_id:1, key:{...}},
  "14":{id:14,username:"10004",domain_id:1, key:{...}}
}
  1. Редактирование списка участников группы, среди которых есть участники, которых нет в контактах. Аналогично пункту 2 необходимо выводить всех участников, даже если они не в списке контактов. Неавторизованных и польностью отсутствующих в контактах пользователей администратор группы может исключить из группы, но не может добавить новых неавторизованных и польностью отсутствующих в контактах пользователей.
  2. Расшифровка сообщений от неавторизованных и полностью отсутствующих в контактах пользователей. Первоначально при получении клчючей запросом [give me keys](/socket.io/client-emited/key/give me keys.md), пользователь получает все чужие открытые ключи, которые хоть раз использовались в шифровании для данного пользователя. Что гарантирует, что все полученные данные можно будет расшифровать при наличии соответствующих закрытых ключей. Исключения:

  • Собеседник полностью отсутствует в контактах, но есть в группе. Чтобы переписка с ним была возможна, необходимо добавить его открытый ключ в локальное хранилище открытых ключей, если этого ключа еще там нет. Ключ поставляется в объекте group в Recipients

    // Recipients example
Recipients: [
{
  "12":{id:12,username:"10002",domain_id:1, key:{...}},
  "14":{id:14,username:"10004",domain_id:1, key:{...}}
}

  • Собеседник получен во фрейме [user container](/socket.io/server-emited/user container.md) и, вероятно, его ключа нет в локальном хранилище. Чтобы переписка с ним была возможна, необходимо добавить его открытый ключ в локальное хранилище открытых ключей, если этого ключа еще там нет. Ключ поставляется в объекте user

    // user fragment example
key: {...}

Запрет/разрешение управления списком контактов

Запрет/разрешение управления списком контакта устанавливается на сервере в настройках домена. Domain.config.contactlist_management_by_user = {boolean}(true|false)

В зависимости от того, разрешено на клиенте управление списком контактов или нет, в интерфейсе будут следующие отличия:

  1. Меню переписки
  2. Поиск контактов
  3. Получение запроса авторизации
  4. Отправка запроса авторизации
  5. Авторизация отменена
  6. Авторизация отклонена