# Запросы на изменение

Запрос на изменение позволяет поменять секреты окружения, в которое у вас нет права записи. Типичный случай: разработчику с доступом к `dev` к релизу нужна новая переменная в `prod`. Он предлагает изменение, а редактор `prod` проверяет его, одобряет и применяет.

> **К сведению.** Доступно только по [подписке](https://tuna.am/#pricing).

Запросы работают только в [личном кабинете](https://my.tuna.am/secrets/requests). Через API, CLI и сервисные ключи их не создать и не одобрить: одобрение должен давать человек, а не утёкший ключ или скрипт.

Редакторы окружения по-прежнему правят секреты напрямую. Запросы и политики не запрещают прямые правки, а добавляют путь для тех, у кого права записи нет.

## Кто что может

| Действие                     | Кто может                                                                                     |
| ---------------------------- | --------------------------------------------------------------------------------------------- |
| Создать запрос               | любой участник проекта, даже без доступа к нужному окружению                                  |
| Видеть значения в запросе    | участник с доступом к окружению или автор значения                                            |
| Одобрить и применить         | редактор окружения: участник с правом записи в него, а также администратор и владелец команды |
| Настроить политики одобрения | администратор и владелец команды                                                              |

Права участников на окружения задаются в [ролях команды](https://tuna.am/docs/team/roles.md).

## Как предложить изменение

Откройте конфигурацию. Если права записи в неё нет, вместо кнопки **Сохранить** будет **Предложить изменение**.

![Конфигурация dev без права записи: в правом верхнем углу кнопка «Предложить изменение»](/docs/img/secrets/change-requests/config-viewer.webp)

Запрос собирается в форме:

1. Укажите заголовок и, по желанию, описание: зачем нужно изменение.
2. Выберите проект и конфигурацию. У окружений без доступа стоит замок: менять в них секреты можно, но текущих значений и имён секретов вы не увидите.
3. Добавьте или измените секреты. Каждая конфигурация — отдельный блок, его одобряют и применяют отдельно. Чтобы поменять секреты в нескольких окружениях, нажмите **Добавить конфигурацию**.
4. Нажмите **Предпросмотр**: там видно, что изменится, и можно выбрать ревьюеров. Без ревьюеров запрос ждёт всех, кто может его одобрить.
5. Нажмите **Отправить на ревью**.

![Форма нового запроса: заголовок, описание, проект и блок конфигурации prod с новой переменной](/docs/img/secrets/change-requests/form-filled.webp)

Через запрос нельзя менять секреты с видимостью `restricted` и выставлять такую видимость.

Ревьюеры получат письмо. В письме есть заголовок запроса, проект, конфигурации и имена секретов, значений нет.

## Ревью и применение

Запросы, которые ждут вашего ревью, видны на главной странице кабинета в блоке **Требует внимания** и в разделе **Секреты → Запросы на изменение** с фильтром **Ждут моего ревью**.

![Список запросов на изменение с кнопкой «Ревью» у запроса, который ждёт одобрения](/docs/img/secrets/change-requests/list-review.webp)

На странице запроса для каждого блока показаны дифф и одобрения. Значения скрыты: чтобы их увидеть, нажмите на значок глаза. Редактор окружения видит и прежние значения, и новые.

![Блок prod на ревью: новые и изменённые секреты, кнопки «Одобрить» и неактивная «Применить»](/docs/img/secrets/change-requests/request-review.webp)

1. Нажмите **Одобрить**. Передумали — **Снять одобрение**.
2. Когда блок одобрен, нажмите **Применить** и подтвердите. Новые значения сразу записываются в конфигурацию, а в [истории изменений](https://tuna.am/docs/secrets.md#history) появляется запись со ссылкой на запрос.

![Применённый блок: кто и когда применил изменения, ссылка на историю конфигурации](/docs/img/secrets/change-requests/request-applied.webp)

Автор получит письмо, когда изменения применят или запрос закроют.

Если запрос не нужен, нажмите **Закрыть запрос**. Автор и ревьюеры могут править запрос, пока он открыт, но после правки блока его одобрения снимаются и ревью начинается заново.

### Статусы

| Статус            | Что значит                                      |
| ----------------- | ----------------------------------------------- |
| Черновик          | запрос сохранён, но не отправлен на ревью       |
| На ревью          | ждёт одобрения                                  |
| Одобрен           | одобрений достаточно, изменения можно применить |
| Применён          | изменения записаны в конфигурацию               |
| Частично применён | часть блоков применена, остальные отменены      |
| Отменён           | запрос закрыли без применения                   |

### Если секрет изменили напрямую

Изменения применяются строго. Если после создания запроса кто-то поменял тот же секрет напрямую, блок помечается как **Устарел**, и применить его нельзя: иначе запрос молча затёр бы чужую правку. Нажмите **обновить**, чтобы пересобрать блок от текущих значений. Одобрения при этом снимаются.

![Блок с пометкой «Устарел: секреты изменились после создания» и ссылкой «обновить»](/docs/img/secrets/change-requests/request-outdated.webp)

На конфигурации с открытым запросом есть плашка со ссылкой на него, чтобы редактор видел, что изменения уже ждут ревью.

## Политики одобрения

По умолчанию блок можно применить после одного одобрения редактора окружения. Политики одобрения задают более строгие правила, например два одобрения для `prod` и запрет одобрять собственный запрос. Политиками управляют администраторы и владельцы команды в разделе [Секреты → Политики одобрения](https://my.tuna.am/secrets/policies).

![Форма новой политики «Продакшен»: два одобрения от любого редактора окружения, автор не может одобрить свой запрос](/docs/img/secrets/change-requests/policy-form.webp)

В политике задаются:

* **Где действует** — все проекты команды, включая новые, или выбранные проекты. Внутри проекта можно ограничить политику окружениями (вместе с их дочерними конфигурациями) или отдельными конфигурациями.
* **Правила** — сколько нужно одобрений, от 1 до 20, и чьи одобрения засчитываются: любого редактора окружения или выбранных участников. Одобрение засчитывается, только если у участника есть право записи в окружение. Должны выполняться все правила политики.
* **Автор запроса не может одобрить его сам** — одобрение автора не засчитывается, кнопка **Одобрить** у него недоступна.
* **Назначать ревьюерами участников из правил** — при создании запроса они станут ревьюерами и получат письмо.

Если на конфигурацию действует несколько политик, нужно выполнить все. У блока под политикой появляется плашка с прогрессом, например `0/2`, а кнопка **Применить** становится доступна, когда все правила выполнены.

![Блок под политикой: плашка «0/2» и подсказка у кнопки «Применить»](/docs/img/secrets/change-requests/request-policy.webp)

## Сколько хранятся запросы

Закрытые и применённые запросы хранятся столько же, сколько [история изменений](https://tuna.am/docs/secrets.md#history) конфигураций на вашем тарифе. Открытые запросы не удаляются. Если удалить конфигурацию или окружение, их блоки пропадут из запросов. Если удалить проект, удалятся и его запросы.