Узнаете?
Инструмент переезда сдается на середине. Половина задач уже в новом трекере, половина нет, и никто не может сказать, какие именно. Вложения остались в старой системе. Номера задач, на которые все ссылаются в чатах и документах, теперь ведут в никуда.
В Quevell переезд устроен так, чтобы быть скучным:
- Источником подойдет любой трекер, который умеет выгрузить таблицу. Вложения переезжают вместе с задачами.
- До записи вы видите результат: какие задачи готовы, что не так с остальными и к какой задаче ляжет каждый файл.
- Незнакомые статусы и поля сопоставляются прямо в диалоге, файл править не нужно.
- Импорт ложится целиком или не ложится вовсе. Наполовину перенесенного проекта не бывает.
- Старые номера задач продолжают находиться поиском. Загрузите тот же файл дважды, и ничего не создастся второй раз.
Уехать так же просто, как приехать. Выгрузка отдает каждое поле, комментарий, запись истории и вложение в том же формате, который Quevell принимает при импорте.
quevell.com
Инструмент переезда сдается на середине. Половина задач уже в новом трекере, половина нет, и никто не может сказать, какие именно. Вложения остались в старой системе. Номера задач, на которые все ссылаются в чатах и документах, теперь ведут в никуда.
В Quevell переезд устроен так, чтобы быть скучным:
- Источником подойдет любой трекер, который умеет выгрузить таблицу. Вложения переезжают вместе с задачами.
- До записи вы видите результат: какие задачи готовы, что не так с остальными и к какой задаче ляжет каждый файл.
- Незнакомые статусы и поля сопоставляются прямо в диалоге, файл править не нужно.
- Импорт ложится целиком или не ложится вовсе. Наполовину перенесенного проекта не бывает.
- Старые номера задач продолжают находиться поиском. Загрузите тот же файл дважды, и ничего не создастся второй раз.
Уехать так же просто, как приехать. Выгрузка отдает каждое поле, комментарий, запись истории и вложение в том же формате, который Quevell принимает при импорте.
quevell.com
🔥3
Задачи в Quevell теперь показывают, что происходит с кодом в GitHub: ветки, коммиты и пул-реквесты.
- Связь идет по ключу задачи. Достаточно написать ключ в имени ветки, заголовке пул-реквеста или тексте коммита: ветка, коммит или пул-реквест появится на задаче в блоке "Разработка".
- Пул-реквест виден со своим состоянием: открыт, запрошены изменения, одобрен, слит. Рядом итог проверок.
- Интеграция только читает. Приложение Quevell просит у GitHub четыре права, все на чтение, и ничего не пишет в репозиторий: ни комментарии, ни метки, ни статусы. Тело каждого события стирается сразу после чтения.
- Подключение делается один раз на компанию, репозитории выбирает каждый проект сам.
- На события пул-реквестов можно настроить правила автоматизации.
quevell.com
- Связь идет по ключу задачи. Достаточно написать ключ в имени ветки, заголовке пул-реквеста или тексте коммита: ветка, коммит или пул-реквест появится на задаче в блоке "Разработка".
- Пул-реквест виден со своим состоянием: открыт, запрошены изменения, одобрен, слит. Рядом итог проверок.
- Интеграция только читает. Приложение Quevell просит у GitHub четыре права, все на чтение, и ничего не пишет в репозиторий: ни комментарии, ни метки, ни статусы. Тело каждого события стирается сразу после чтения.
- Подключение делается один раз на компанию, репозитории выбирает каждый проект сам.
- На события пул-реквестов можно настроить правила автоматизации.
quevell.com
Самый неприятный момент в автоматизации наступает до первого запуска: правило уже настроено, а уверенности, что оно затронет именно те задачи, еще нет.
В Quevell для этого есть проверка - Dry-run. Правило прогоняется по настоящим задачам, не записывая ничего.
При этом проверка не живет отдельной логикой рядом с автоматизацией:
- Условие разбирается так же, как при срабатывании правила.
- Используются права аккаунта.
- Действия идут в том же порядке.
- Вместо выполнения собирается план.
В плане видно, какие задачи подошли под правило и какие не подошли. Для подходящих задач Quevell показывает, какие действия были бы выполнены.
Если правило содержит внешний вызов, проверка показывает, каким был бы запрос, вплоть до его тела. Если вызов, при этом, содержит секреты, то они остаются замаскированными.
Проверить можно и выключенное правило. То есть сначала посмотреть, что именно оно будет делать на настоящих данных, и только потом дать ему возможность действовать самостоятельно.
Проверка ограничена по той же причине, по которой она полезна: такой прогон обходится почти как настоящая работа правила. До 50 задач за прогон, до 6 прогонов в минуту на пользователя и до 10 секунд на один прогон.
quevell.com
В Quevell для этого есть проверка - Dry-run. Правило прогоняется по настоящим задачам, не записывая ничего.
При этом проверка не живет отдельной логикой рядом с автоматизацией:
- Условие разбирается так же, как при срабатывании правила.
- Используются права аккаунта.
- Действия идут в том же порядке.
- Вместо выполнения собирается план.
В плане видно, какие задачи подошли под правило и какие не подошли. Для подходящих задач Quevell показывает, какие действия были бы выполнены.
Если правило содержит внешний вызов, проверка показывает, каким был бы запрос, вплоть до его тела. Если вызов, при этом, содержит секреты, то они остаются замаскированными.
Проверить можно и выключенное правило. То есть сначала посмотреть, что именно оно будет делать на настоящих данных, и только потом дать ему возможность действовать самостоятельно.
Проверка ограничена по той же причине, по которой она полезна: такой прогон обходится почти как настоящая работа правила. До 50 задач за прогон, до 6 прогонов в минуту на пользователя и до 10 секунд на один прогон.
quevell.com
👍3❤1
Часто ли вы встречали механизм временной автоматической выдачи админки?
Постоянные права администратора нужны далеко не каждому. Часто пользователю достаточно получить их на время: настроить свой проект, добавить или изменить глобальные переменные, сделать нужное изменение и вернуться к обычным правам.
В Quevell для этого есть доверенные пользователи.
Доверенный пользователь сам запрашивает права администратора и указывает:
- Когда они должны начать действовать;
- Когда должны закончиться;
- Зачем они нужны.
Запрос попадает постоянному администратору компании. Он видит причину и срок и решает, соответствует ли запрос политикам компании.
Если все в порядке, запрос можно одобрить. Если оснований для такого доступа нет или срок выглядит избыточным, запрос отклоняется с причиной.
После одобрения права действуют только внутри указанного пользователем временного окна.
Отдельного процесса, который потом должен вспомнить и снять их, нет. При каждом административном действии Quevell заново проверяет, действует ли одобренный срок в этот момент.
Пока текущее время находится внутри окна, права есть.
Как только конечная дата прошла, временные права просто перестают существовать для проверки доступа.
Никакого крона, который падает. Никакой задержки между окончанием срока и фактическим прекращением доступа. И никакого забытого администратора через полгода после "временной" настройки.
quevell.com
Постоянные права администратора нужны далеко не каждому. Часто пользователю достаточно получить их на время: настроить свой проект, добавить или изменить глобальные переменные, сделать нужное изменение и вернуться к обычным правам.
В Quevell для этого есть доверенные пользователи.
Доверенный пользователь сам запрашивает права администратора и указывает:
- Когда они должны начать действовать;
- Когда должны закончиться;
- Зачем они нужны.
Запрос попадает постоянному администратору компании. Он видит причину и срок и решает, соответствует ли запрос политикам компании.
Если все в порядке, запрос можно одобрить. Если оснований для такого доступа нет или срок выглядит избыточным, запрос отклоняется с причиной.
После одобрения права действуют только внутри указанного пользователем временного окна.
Отдельного процесса, который потом должен вспомнить и снять их, нет. При каждом административном действии Quevell заново проверяет, действует ли одобренный срок в этот момент.
Пока текущее время находится внутри окна, права есть.
Как только конечная дата прошла, временные права просто перестают существовать для проверки доступа.
Никакого крона, который падает. Никакой задержки между окончанием срока и фактическим прекращением доступа. И никакого забытого администратора через полгода после "временной" настройки.
quevell.com
🔥1🏆1
В одном проекте могут находиться обычные рабочие задачи и, например, разбор серьезного инцидента, доступ к которому нужен лишь нескольким сотрудникам.
В Quevell для таких случаев предусмотрены уровни безопасности задач. Они позволяют ограничить круг пользователей, которые могут видеть конкретную задачу, сохранив ее в общем проекте.
Главный принцип: уровень безопасности может только сузить доступ к проекту, но никогда не расширить его.
Сначала Quevell проверяет, имеет ли пользователь доступ к проекту. Затем, если у задачи установлен уровень безопасности, проверяет, разрешен ли ему доступ через личное назначение, группу или роль в проекте.
Но здесь есть важная техническая деталь: для поиска, списков задач и досок ограничение применяется непосредственно в SQL-запросе. При обращении к отдельной задаче через API используется
Если задача защищена от пользователя, она не появляется в результатах поиска. А попытка открыть ее напрямую возвращает
Это сделано намеренно. Ответ
Почему это важно?
Скрыть задачу в интерфейсе недостаточно. Если ее можно найти через другой метод API, поисковый запрос или обращение по известному идентификатору, ограничение доступа теряет смысл.
Поэтому правила видимости применяются на сервере независимо от того, каким способом пользователь обращается к задаче.
quevell.com
В Quevell для таких случаев предусмотрены уровни безопасности задач. Они позволяют ограничить круг пользователей, которые могут видеть конкретную задачу, сохранив ее в общем проекте.
Главный принцип: уровень безопасности может только сузить доступ к проекту, но никогда не расширить его.
Сначала Quevell проверяет, имеет ли пользователь доступ к проекту. Затем, если у задачи установлен уровень безопасности, проверяет, разрешен ли ему доступ через личное назначение, группу или роль в проекте.
Но здесь есть важная техническая деталь: для поиска, списков задач и досок ограничение применяется непосредственно в SQL-запросе. При обращении к отдельной задаче через API используется
IssueAccessService, который проверяет те же условия.Если задача защищена от пользователя, она не появляется в результатах поиска. А попытка открыть ее напрямую возвращает
404 Not Found вместо 403 Forbidden.Это сделано намеренно. Ответ
403 подтвердил бы существование задачи, даже если ее содержимое недоступно.Почему это важно?
Скрыть задачу в интерфейсе недостаточно. Если ее можно найти через другой метод API, поисковый запрос или обращение по известному идентификатору, ограничение доступа теряет смысл.
Поэтому правила видимости применяются на сервере независимо от того, каким способом пользователь обращается к задаче.
quevell.com
👍2🔥1
Что происходит, когда администратор меняет рабочую схему действующего проекта?
Рабочая схема определяет, через какие статусы проходит задача и какие переходы между ними разрешены.
Изменить такую схему в работающем проекте сложнее, чем кажется. В ней уже находятся задачи, а некоторые статусы и переходы могут использоваться сразу в нескольких процессах.
В Quevell редактирование начинается с черновика. Пока администратор вносит изменения, действующая рабочая схема остается прежней.
Перед публикацией продукт проверяет новую конфигурацию: все статусы должны быть достижимы из начального, переходы должны быть корректными, а статус, в котором уже находятся задачи, нельзя удалить из схемы.
Кроме того, публикация требует указания текущей версии. Если другой администратор успел опубликовать изменения раньше, Quevell отклонит устаревшую версию, чтобы не перезаписать чужую работу.
Каждая успешная публикация создает новую ревизию рабочей схемы.
Ревизия хранит полный снимок конфигурации, включая статусы и переходы, а также автора и время публикации. Старые ревизии доступны для чтения и не изменяются.
Допустим, сейчас действует ревизия 6, но нужно вернуться к состоянию ревизии 3.
Quevell загрузит ее содержимое в конструктор как черновик. После проверки и публикации появится ревизия 7. Все шесть предыдущих сохранятся.
Почему это важно?
Изменение рабочей схемы может повлиять на движение задач сразу в нескольких проектах. Поэтому администратор должен заранее понимать последствия публикации и иметь возможность восстановить прежнюю конфигурацию.
Не менее важно сохранять историю. Если рабочая схема изменилась, по ревизиям можно установить, как она была устроена раньше, кто опубликовал изменения и когда они вступили в силу.
Возврат к прежней конфигурации не должен переписывать прошлое.
quevell.com
Рабочая схема определяет, через какие статусы проходит задача и какие переходы между ними разрешены.
Изменить такую схему в работающем проекте сложнее, чем кажется. В ней уже находятся задачи, а некоторые статусы и переходы могут использоваться сразу в нескольких процессах.
В Quevell редактирование начинается с черновика. Пока администратор вносит изменения, действующая рабочая схема остается прежней.
Перед публикацией продукт проверяет новую конфигурацию: все статусы должны быть достижимы из начального, переходы должны быть корректными, а статус, в котором уже находятся задачи, нельзя удалить из схемы.
Кроме того, публикация требует указания текущей версии. Если другой администратор успел опубликовать изменения раньше, Quevell отклонит устаревшую версию, чтобы не перезаписать чужую работу.
Каждая успешная публикация создает новую ревизию рабочей схемы.
Ревизия хранит полный снимок конфигурации, включая статусы и переходы, а также автора и время публикации. Старые ревизии доступны для чтения и не изменяются.
Допустим, сейчас действует ревизия 6, но нужно вернуться к состоянию ревизии 3.
Quevell загрузит ее содержимое в конструктор как черновик. После проверки и публикации появится ревизия 7. Все шесть предыдущих сохранятся.
Почему это важно?
Изменение рабочей схемы может повлиять на движение задач сразу в нескольких проектах. Поэтому администратор должен заранее понимать последствия публикации и иметь возможность восстановить прежнюю конфигурацию.
Не менее важно сохранять историю. Если рабочая схема изменилась, по ревизиям можно установить, как она была устроена раньше, кто опубликовал изменения и когда они вступили в силу.
Возврат к прежней конфигурации не должен переписывать прошлое.
quevell.com
👍3
Quevell теперь доступен через MCP: ChatGPT, Codex и Claude
Мы реализовали MCP 2.0 с 171 инструментом для работы с Quevell. Через AI-приложение можно искать и читать задачи, создавать и изменять их, работать с проектами, досками, спринтами, комментариями, учетом времени и базой знаний.
Все это работает через единый MCP-сервер и существующие сервисы Quevell.
Здесь важно, как устроен доступ.
1. Персональное подключение через OAuth.
Пользователь входит в Quevell, проходит двухфакторную аутентификацию, если она включена, и подтверждает доступ приложения. AI получает только те права, которыми пользователь уже располагает.
Чтение и запись разделены:
2. Подключение через сервисный аккаунт.
Для постоянных интеграций предусмотрены API-токены и OAuth с
Администрирование компании, платежи и выдача прав через MCP недоступны.
3. Контроль изменений.
Для операций записи используются
Некоторые действия требуют отдельного подтверждения человеком в Quevell. После подтверждения приложение повторяет операцию, а сервер заново проверяет права и версию.
4. Прозрачная история.
В истории сохраняется, кто действовал, через какое приложение и по какому каналу. Действие через MCP не должно выглядеть как обычное ручное изменение пользователя.
Адрес MCP у каждой компании свой:
Поддержка передачи файлов и отдельных чувствительных действий также требует проверки в конкретном клиенте.
Главный принцип: AI работает с теми же данными и правами, что и человек или сервисный аккаунт. Отдельного привилегированного доступа для него нет.
quevell.com
Мы реализовали MCP 2.0 с 171 инструментом для работы с Quevell. Через AI-приложение можно искать и читать задачи, создавать и изменять их, работать с проектами, досками, спринтами, комментариями, учетом времени и базой знаний.
Все это работает через единый MCP-сервер и существующие сервисы Quevell.
Здесь важно, как устроен доступ.
1. Персональное подключение через OAuth.
Пользователь входит в Quevell, проходит двухфакторную аутентификацию, если она включена, и подтверждает доступ приложения. AI получает только те права, которыми пользователь уже располагает.
Чтение и запись разделены:
mcp.read и mcp.write. Подключение можно отозвать в профиле.2. Подключение через сервисный аккаунт.
Для постоянных интеграций предусмотрены API-токены и OAuth с
client_credentials. У сервисного аккаунта собственные роли в проектах, а права токена можно дополнительно ограничить.Администрирование компании, платежи и выдача прав через MCP недоступны.
3. Контроль изменений.
Для операций записи используются
requestId и версия объекта. Повтор сетевого запроса с тем же идентификатором не должен создавать второе изменение, а устаревшая версия приводит к отказу вместо перезаписи чужой работы.Некоторые действия требуют отдельного подтверждения человеком в Quevell. После подтверждения приложение повторяет операцию, а сервер заново проверяет права и версию.
4. Прозрачная история.
В истории сохраняется, кто действовал, через какое приложение и по какому каналу. Действие через MCP не должно выглядеть как обычное ручное изменение пользователя.
Адрес MCP у каждой компании свой:
https://<ключ>.quevell.com/api/mcpПоддержка передачи файлов и отдельных чувствительных действий также требует проверки в конкретном клиенте.
Главный принцип: AI работает с теми же данными и правами, что и человек или сервисный аккаунт. Отдельного привилегированного доступа для него нет.
quevell.com
🔥4👍1
Что происходит с задачами, когда сотрудник покидает компанию?
Представим обычную ситуацию: сотрудник увольняется, но на нем остаются открытые задачи, роли в проектах, правила автоматизации и страницы базы знаний.
Если просто деактивировать его учетную запись, часть работы может остаться без ответственного, а правила автоматизации перестанут выполняться от его имени.
В Quevell для этого предусмотрена передача дел преемнику.
Администратор видит, что числится за сотрудником, выбирает преемника и передает ему работу одним действием.
Но важнее то, как эта передача устроена.
Все изменения выполняются в одной транзакции. Если что-то не удалось передать, операция откатывается целиком. Не возникает ситуации, когда задачи уже перешли новому сотруднику, а роли в проектах и правила автоматизации остались у прежнего.
При передаче:
- Открытые назначения и ответственность за незавершенные задачи переходят преемнику.
- Роли в проектах переносятся, а не копируются. У прежнего пользователя переданной личной роли больше нет.
- Правила автоматизации, личные страницы и сохраненные фильтры переходят новому ответственному.
- Если у преемника уже есть роль в проекте, она сохраняется.
- Доступ через группы обрабатывается отдельно: передача дел не меняет состав групп и полученные через них роли.
Авторство при этом остается неизменным.
Задачи, комментарии и вложения продолжают хранить сведения о том, кто действительно их создал. Назначение на завершенной задаче тоже остается частью истории.
Есть еще одно ограничение: Quevell не разрешает окончательно удалить пользователя, пока за ним остаются открытые назначения, ответственность за незавершенные задачи, роли в проектах или правила автоматизации. Сначала нужно передать работу.
Это важно по двум причинам.
Во-первых, работа компании не должна зависеть от того, остается ли конкретный сотрудник в команде.
Во-вторых, передача ответственности не должна переписывать историю. Новый сотрудник продолжает работу, но решения и действия предыдущего остаются на своих местах.
Работа переходит к другому человеку. История остается достоверной.
quevell.com
Представим обычную ситуацию: сотрудник увольняется, но на нем остаются открытые задачи, роли в проектах, правила автоматизации и страницы базы знаний.
Если просто деактивировать его учетную запись, часть работы может остаться без ответственного, а правила автоматизации перестанут выполняться от его имени.
В Quevell для этого предусмотрена передача дел преемнику.
Администратор видит, что числится за сотрудником, выбирает преемника и передает ему работу одним действием.
Но важнее то, как эта передача устроена.
Все изменения выполняются в одной транзакции. Если что-то не удалось передать, операция откатывается целиком. Не возникает ситуации, когда задачи уже перешли новому сотруднику, а роли в проектах и правила автоматизации остались у прежнего.
При передаче:
- Открытые назначения и ответственность за незавершенные задачи переходят преемнику.
- Роли в проектах переносятся, а не копируются. У прежнего пользователя переданной личной роли больше нет.
- Правила автоматизации, личные страницы и сохраненные фильтры переходят новому ответственному.
- Если у преемника уже есть роль в проекте, она сохраняется.
- Доступ через группы обрабатывается отдельно: передача дел не меняет состав групп и полученные через них роли.
Авторство при этом остается неизменным.
Задачи, комментарии и вложения продолжают хранить сведения о том, кто действительно их создал. Назначение на завершенной задаче тоже остается частью истории.
Есть еще одно ограничение: Quevell не разрешает окончательно удалить пользователя, пока за ним остаются открытые назначения, ответственность за незавершенные задачи, роли в проектах или правила автоматизации. Сначала нужно передать работу.
Это важно по двум причинам.
Во-первых, работа компании не должна зависеть от того, остается ли конкретный сотрудник в команде.
Во-вторых, передача ответственности не должна переписывать историю. Новый сотрудник продолжает работу, но решения и действия предыдущего остаются на своих местах.
Работа переходит к другому человеку. История остается достоверной.
quevell.com
👍2🔥1