SHA256
Удалить проверенные pending-фичи
This commit is contained in:
+2
-2
@@ -1,2 +1,2 @@
|
|||||||
client.version=1.2.323
|
client.version=1.2.324
|
||||||
server.version=1.2.295
|
server.version=1.2.296
|
||||||
|
|||||||
@@ -1,15 +0,0 @@
|
|||||||
# Регистрация: глаз у пароля, автопроверка логина и сохранение связки с 12 словами
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
На экране регистрации добавлены кнопка-глаз у поля пароля, автопроверка логина с задержкой около 1.5 секунды и сохранение связки между обычным полем пароля и режимом `12 слов`, пока пользователь вручную не изменит пароль.
|
|
||||||
- что проверять:
|
|
||||||
Открыть экран регистрации и убедиться, что справа от поля пароля есть квадратная кнопка-глаз, которая переключает скрытый и открытый показ пароля.
|
|
||||||
Включить режим `Представить пароль в виде 12 слов`, заполнить несколько или все слова, затем выключить режим и проверить, что в поле пароля появился склеенный пароль.
|
|
||||||
Снова включить режим `12 слов` без ручного редактирования пароля и проверить, что ранее введённые слова восстановились.
|
|
||||||
После этого вручную изменить пароль в обычном поле и снова включить режим `12 слов` — набор слов должен быть очищен.
|
|
||||||
Ввести логин и перестать печатать примерно на 1.5 секунды — под полем логина должен автоматически появиться актуальный статус доступности.
|
|
||||||
Проверить, что кнопка `Проверить логин` находится ниже статуса, а текст про частые вопросы снизу страницы отсутствует.
|
|
||||||
- ожидаемый результат:
|
|
||||||
Регистрация ведёт себя предсказуемо: пароль можно показать или скрыть, слова не теряются при простом скрытии режима `12 слов`, а статус логина обновляется автоматически и вручную.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@@ -1,13 +0,0 @@
|
|||||||
# Исправление экрана регистрации и отдельный UI-деплой на `t2.shineup.me`
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
Исправлен экран регистрации после регрессии: обычное поле пароля, кнопка-глаз и кнопка проверки логина снова должны быть видимы одновременно с режимом `12 слов`. Отдельно UI выложен на `t2.shineup.me` безопасным способом без использования исторического `deployUITest2`.
|
|
||||||
- что проверять:
|
|
||||||
Открыть экран регистрации и убедиться, что видны поле логина, статус под ним, кнопка `Проверить логин`, обычное поле пароля и квадратная кнопка-глаз.
|
|
||||||
Включить режим `12 слов` и убедиться, что блок слов появляется, но обычное поле пароля не исчезает.
|
|
||||||
Ввести слова и проверить, что длинный составной пароль сразу виден в обычном поле пароля.
|
|
||||||
Проверить, что `https://t2.shineup.me` отдаёт обновлённый UI с этой правкой.
|
|
||||||
- ожидаемый результат:
|
|
||||||
Экран регистрации снова полностью рабочий и на `t2.shineup.me` доступна именно исправленная версия UI.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@@ -1,12 +0,0 @@
|
|||||||
# Проверки серверных настроек через текущий выбранный Solana RPC
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
Убрано использование `SOLANA_ENDPOINT_DEFAULT` в проверках логина сервера. Теперь проверки должны идти через текущий выбранный пользователем Solana endpoint из настроек.
|
|
||||||
- что проверять:
|
|
||||||
Открыть экран настроек входа или серверных настроек.
|
|
||||||
Поменять `Адрес Solana сервера` на другой endpoint и проверить логин сервера кнопкой `Проверить`.
|
|
||||||
Убедиться, что результат проверки соответствует именно выбранному RPC, а не значению по умолчанию.
|
|
||||||
- ожидаемый результат:
|
|
||||||
Все проверки логина сервера используют текущий выбранный Solana endpoint и не подмешивают дефолтный RPC.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
-12
@@ -1,12 +0,0 @@
|
|||||||
# Исправление нормализации Solana endpoint и удаление старой кнопки справки
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
Убрана скрытая подмена выбранного Solana endpoint на дефолтный при сохранении настроек входа. Со страницы настроек входа удалена старая маленькая кнопка `?` внизу.
|
|
||||||
- что проверять:
|
|
||||||
Открыть настройки входа, ввести свой Solana RPC и сохранить.
|
|
||||||
Убедиться, что после сохранения endpoint остаётся ровно тем, который был введён, без незаметной подмены.
|
|
||||||
Проверить, что внизу страницы больше нет маленькой кнопки `?`.
|
|
||||||
- ожидаемый результат:
|
|
||||||
Клиент использует именно выбранный пользователем Solana endpoint, а экран настроек входа не содержит старой кнопки справки.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@@ -1,12 +0,0 @@
|
|||||||
# UI deploy: подстановка Solana cluster и endpoint
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
В UI deploy-скрипт добавлена подстановка `defaultSolanaCluster` и `defaultSolanaEndpoint` в `deploy-config.js`. Для production на уровне скриптов используется значение `mainnet`, которое внутри общего deploy-скрипта нормализуется в `mainnet-beta` для совместимости с кодом. Для `t2` выставляется devnet/api.devnet.solana.com.
|
|
||||||
- что проверять:
|
|
||||||
Выполнить production UI deploy и проверить, что в опубликованном `js/deploy-config.js` стоят `mainnet-beta` и `https://solana-rpc.publicnode.com`.
|
|
||||||
Выполнить `t2` UI deploy и проверить, что в опубликованном `js/deploy-config.js` стоят `devnet` и `https://api.devnet.solana.com`.
|
|
||||||
Убедиться, что логин и адрес сервера при этом тоже подставляются корректно.
|
|
||||||
- ожидаемый результат:
|
|
||||||
После деплоя каждый UI-инстанс получает свои правильные Solana defaults без ручной правки файла на сервере.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@@ -1,12 +0,0 @@
|
|||||||
# Перенос второго production на `server2.shineup.me` и добавление UI-обёрток `t1/t3/t4`
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
Второй production-контур переименован в документации и UI deploy-скриптах на `server2.shineup.me` с логином `server2shineupme`. Добавлены отдельные UI-обёртки для `t1`, `t3` и `t4`.
|
|
||||||
- что проверять:
|
|
||||||
Выполнить `./gradlew deployUI` и убедиться, что deploy идёт на `server2.shineup.me`.
|
|
||||||
Проверить новые скрипты `deploy_shine-ui_t1.sh`, `deploy_shine-ui_t3.sh`, `deploy_shine-ui_t4.sh`.
|
|
||||||
Убедиться, что в проектной документации больше нет упоминаний старого домена второго production-контура.
|
|
||||||
- ожидаемый результат:
|
|
||||||
Второй production везде обозначен как `server2.shineup.me`, а все четыре devnet UI-инстанса имеют отдельные короткие deploy-обёртки.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@@ -1,11 +0,0 @@
|
|||||||
# Переименование UI-обёртки второго production в единый формат
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
UI-обёртка второго production переименована в `deploy_shine-ui_production_server2shineupme.sh`, чтобы имя было единообразным с production-обёрткой основного домена.
|
|
||||||
- что проверять:
|
|
||||||
Убедиться, что `./gradlew deployUI` использует новый файл-обёртку.
|
|
||||||
Проверить, что старое имя `deploy_shine-ui_server2shineupme.sh` больше нигде не используется.
|
|
||||||
- ожидаемый результат:
|
|
||||||
Для второго production используется обёртка с именем `deploy_shine-ui_production_server2shineupme.sh`.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@@ -1,20 +0,0 @@
|
|||||||
# Исправление payer для Solana login guard предпроверки
|
|
||||||
|
|
||||||
- статус: `pending`
|
|
||||||
|
|
||||||
## Кратко
|
|
||||||
|
|
||||||
В браузерной предпроверке логина через `shine_login_guard` убран несуществующий test payer-аккаунт.
|
|
||||||
Для `simulateTransaction` теперь используется существующий `program id` самой `shine_login_guard`.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- на странице регистрации в devnet логин длиной от `5` символов больше не показывает предупреждение:
|
|
||||||
`предпроверка Solana недоступна: ... AccountNotFound`;
|
|
||||||
- свободный логин показывает обычный статус `Логин свободен ✅`;
|
|
||||||
- короткий логин всё ещё корректно классифицируется как недоступный для обычной регистрации.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- `simulateTransaction` для `shine_login_guard` не падает из-за `AccountNotFound`;
|
|
||||||
- UI показывает результат on-chain предпроверки без ложного warning.
|
|
||||||
@@ -1,24 +0,0 @@
|
|||||||
# Торжественный финал регистрации и фоновый автовход
|
|
||||||
|
|
||||||
- статус: `pending`
|
|
||||||
|
|
||||||
## Кратко
|
|
||||||
|
|
||||||
После успешной регистрации экран завершения сделан более торжественным.
|
|
||||||
Убран countdown и кнопка ручного запуска автовхода.
|
|
||||||
Теперь UI ждёт 5 секунд, затем раз в секунду пробует автоматически войти в аккаунт, пока запись не станет доступна на сервере.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- после регистрации появляется экран с текстом `Поздравляем, регистрация завершена`;
|
|
||||||
- ниже есть пояснение про ожидание обновления записи в блокчейне;
|
|
||||||
- отображается строка `Или вы можете` и кнопка `Вернуться в главное меню`;
|
|
||||||
- если ничего не нажимать, через несколько секунд начинается фоновый автовход без мигающего countdown;
|
|
||||||
- после появления записи пользователь автоматически попадает в свой аккаунт;
|
|
||||||
- если нажать `Вернуться в главное меню`, автоматические попытки прекращаются и открывается стартовый экран.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- финальный экран регистрации выглядит спокойнее и понятнее;
|
|
||||||
- пользователь не видит лишний таймер и ручную кнопку входа;
|
|
||||||
- автовход происходит сам, когда сервер уже готов принять логин.
|
|
||||||
Reference in New Issue
Block a user