Представьте экран, который я хочу отдать покупателю: он вошёл и сразу видит свои заказы за выбранный период, может сузить список датами и статусами, открыть нужную строку, скачать по ней счёт и акт, а всю получившуюся выборку сохранить себе файлом — таблицей XLSX для бухгалтерии и PDF для подписи. Ни одного звонка, ни одной просьбы «пришлите, пожалуйста». Сегодня этого экрана нет, и каждый такой запрос превращается в разговор с менеджером, который лезет в учётную систему и пересылает файлы по одному.
Вторая половина задачи — про права, и она для меня важнее красоты. Учётная запись заводится не самостоятельной регистрацией, а приглашением от нас. У компании-покупателя есть владелец: он приглашает своих людей, отключает уволившихся, правит реквизиты и включает себе двухфакторный вход. Есть сотрудник: он работает с историей и документами и больше ни с чем. Разделение должно держаться не на спрятанных кнопках, а на самой выборке данных — чужой заказ не должен доставаться даже тому, кто вручную подставит его номер в адрес.
Данные приходят из нашей учётной системы по её API, документация у нас на руках и передаётся вместе с тестовым доступом; отгрузка порождает письмо покупателю. Открывать портал будут преимущественно с телефонов, поэтому телефонная вёрстка — обязательное условие приёмки, а не пожелание.
Перечень того, что жду на выходе:
— регистрация по приглашению и восстановление пароля, двухфакторный вход у владельца;
— две роли с разными правами и экран управления сотрудниками у владельца;
— список заказов с фильтрами по диапазону дат и по статусам, карточка заказа с документами;
— скачивание счетов и актов и экспорт текущей выборки в XLSX и PDF;
— уведомления об отгрузке на почту;
— обмен с учётной системой по документированному API;
— рабочий вид на телефоне;
— персональные данные клиентов не выгружаются наружу и не попадают в письма целиком: наружу уходит номер заказа и статус, остальное читается только после входа;
— доступ к чужим заказам закрывается на уровне запроса, а не только в интерфейсе;
— тестовый контур работает на обезличенных данных, без копий боевой базы покупателей.
Вторая половина задачи — про права, и она для меня важнее красоты. Учётная запись заводится не самостоятельной регистрацией, а приглашением от нас. У компании-покупателя есть владелец: он приглашает своих людей, отключает уволившихся, правит реквизиты и включает себе двухфакторный вход. Есть сотрудник: он работает с историей и документами и больше ни с чем. Разделение должно держаться не на спрятанных кнопках, а на самой выборке данных — чужой заказ не должен доставаться даже тому, кто вручную подставит его номер в адрес.
Данные приходят из нашей учётной системы по её API, документация у нас на руках и передаётся вместе с тестовым доступом; отгрузка порождает письмо покупателю. Открывать портал будут преимущественно с телефонов, поэтому телефонная вёрстка — обязательное условие приёмки, а не пожелание.
Перечень того, что жду на выходе:
— регистрация по приглашению и восстановление пароля, двухфакторный вход у владельца;
— две роли с разными правами и экран управления сотрудниками у владельца;
— список заказов с фильтрами по диапазону дат и по статусам, карточка заказа с документами;
— скачивание счетов и актов и экспорт текущей выборки в XLSX и PDF;
— уведомления об отгрузке на почту;
— обмен с учётной системой по документированному API;
— рабочий вид на телефоне;
— персональные данные клиентов не выгружаются наружу и не попадают в письма целиком: наружу уходит номер заказа и статус, остальное читается только после входа;
— доступ к чужим заказам закрывается на уровне запроса, а не только в интерфейсе;
— тестовый контур работает на обезличенных данных, без копий боевой базы покупателей.
