Redmine для нескольких клиентов: роли, трекеры и изоляция обращений

Представим администратора Сергея, который ведёт технический саппорт сразу для двух заказчиков. Первый — небольшая бухгалтерская фирма «Альфа», второй — розничная сеть «Бета». Сергей один, и ему нужно видеть обращения обоих. Но сотрудники «Альфы» не должны знать, что у «Беты» вообще есть проблемы с кассами, а бухгалтер «Беты» не должен случайно увидеть, сколько часов ушло на сервер соседа. Вот на этом пересечении и проверяется, понимаете ли вы Redmine: один человек, две территории, и между ними нет общей витрины.

Ниже разберём, как это устроить. Все примеры условные: «Альфа», «Бета» и Сергей придуманы для объяснения. Названия проектов, ролей и трекеров в вашей системе будут своими.

Три разные сущности, которые легко спутать

Самая частая ошибка при первой настройке — смешать в одну кучу проект, трекер и роль. Они отвечают на разные вопросы.

• Проект отвечает на вопрос «где это лежит». Это контейнер, внутри которого живут задачи, участники и учёт времени.
• Трекер отвечает на вопрос «что это за тип записи»: например, обращение, запрос на изменение, инцидент. Трекер описывает природу задачи, а не то, кому её можно показывать.
• Роль отвечает на вопрос «что может делать человек в конкретном проекте». Согласно документации Redmine по ролям и правам, роли задаются на уровне проекта: один и тот же человек в разных проектах может иметь разные роли.

Отсюда первое практическое следствие. Если вы заведёте трекер «Обращение Альфы» и трекер «Обращение Беты» и положите всё в один проект, вы получите красивые названия, но не границу доступа. Название трекера — всего лишь ярлык. Граница проводится там, где определено членство и роль, то есть на уровне проекта. Поэтому для двух клиентов с разной видимостью разумная отправная точка — два проекта: «Поддержка — Альфа» и «Поддержка — Бета».

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

Разберём на примере Сергея, зачем нужна эта разница. Допустим, в обоих проектах включены трекеры «Обращение» и «Инцидент». Когда в конце месяца вы смотрите, сколько инцидентов было у «Альфы» и у «Беты», трекер даёт общую шкалу сравнения, а проект — разрез по клиентам. Если же сделать трекер «Обращение Альфы» и перенести всё в один проект, исчезнет и общая шкала (типы разные), и граница доступа (проект один). Получается худший вариант из двух.

Отсюда простое правило для первичной настройки: трекеры отвечают за единообразие описания работы, роли — за права, проекты — за состав участников. Если вы ловите себя на мысли «создам ещё один трекер, чтобы скрыть это от клиента», остановитесь: трекер ничего не скрывает. Скрывают членство в проекте и настройки роли, о которых в документации по ролям и правам сказано, что роли задаются на уровне проекта.

Сергей в двух проектах

Теперь соберём конкретную схему. Заводим два проекта. В каждом создаём участников:

Роль «Клиент» — это роль, у которой минимум прав: создавать обращения, комментировать свои и смотреть их состояние. Роль «Исполнитель» шире: менять статусы, назначать, вносить время. Сергей один раз зарегистрирован в системе и состоит в обоих проектах. Ирина о существовании проекта «Беты» не узнает через список проектов, если она в нём не участник и проект не публичный.

Тут есть важная оговорка про публичность проекта: если проект отмечен как публичный, он может быть доступен более широкому кругу, чем его участники. Для клиентских пространств разумно держать проекты непубличными и отдельно проверить, что именно видит человек, не состоящий в проекте. Эту проверку мы вернём в конце.

Что именно клиент видит внутри своего проекта

Один проект ещё не решает всех вопросов. Внутри «Поддержки — Альфа» могут работать несколько сотрудников клиента. Должна ли Ирина видеть обращение, которое создал её коллега из соседнего отдела? А должен ли Сергей, исполнитель, видеть всё или только своё?

Для этого у роли есть настройка видимости задач. По документации, возможны три режима: все задачи; все непубличные задачи, но с исключениями для автора и исполнителя; только задачи, созданные пользователем или назначенные ему. Сами формулировки в интерфейсе могут отличаться по версии, поэтому сверяйтесь со своим экраном настройки роли.

Посмотрим, как это работает на двух ролях.

Роль «Клиент»: только своё

Если для клиентской роли выбрать режим «только созданные или назначенные пользователю», Ирина увидит лишь те обращения, которые открыла сама или которые назначены ей. Коллега по «Альфе», открывший обращение про принтер, для неё невидим. Это строгий режим, подходящий, когда сотрудники клиента не должны видеть переписку друг друга: например, кадровые вопросы рядом с техническими.

Цена такого выбора — дублирование. Если два сотрудника «Альфы» заводят обращение об одной и той же проблеме с почтой, они не увидят друг друга и создадут две задачи. Сергею придётся склеивать их вручную. Для маленького клиента с одним ответственным контактом это неважно, для компании на пятьдесят человек — ощутимо.

Роль «Клиент»: вся компания видит общее

Другой вариант — режим, при котором видны все задачи проекта. Тогда в «Альфе» любой участник видит любые обращения клиента: это удобно, когда команда небольшая и общая лента снижает дубли. Но тут скрыт подвох: если Сергей захочет завести внутреннюю заметку, не предназначенную клиенту, в таком режиме её увидят все. Для этого и нужен средний вариант.

Средний режим: непубличные задачи с исключениями

Режим «все непубличные задачи» подразумевает, что задача может быть помечена как приватная. Приватную задачу видит ограниченный круг, а автор и исполнитель имеют исключения: свою задачу они видят даже если она приватная. Это полезно для внутренней кухни: Сергей создаёт приватную задачу «Разобраться, почему у Альфы падает резервный скрипт», и клиентская роль её не видит.

Как именно работает пометка приватности и кто из ролей что видит при каждом сочетании, лучше проверить на тестовом проекте, а не угадывать по названиям. Я бы начал с простого правила: клиентской роли дать строгий или средний режим, исполнителю — все задачи проекта. Исполнитель в проекте клиента должен видеть полную картину, иначе он будет теряться в обращениях.

Когда у человека несколько ролей

В схеме с Сергеем возникает вопрос: что будет, если у одного пользователя в проекте окажется сразу несколько ролей? Допустим, Ирина — и обычный клиент, и «ответственный за согласование» в «Альфе». Для этого есть правило из документации: права нескольких ролей объединяются. Иначе говоря, итоговый набор прав — это сумма прав каждой роли пользователя в проекте.

На практике это значит две вещи.

• Лишняя роль почти никогда не ограничивает, она только расширяет. Если вы добавили Ирине роль «Согласующий» ради одного права, а роль «Клиент» урезана, итог будет шире клиентской. Нельзя добавить строгую роль и ожидать, что она «перебьёт» мягкую.
• Режим видимости задач тоже нужно проверять в сочетании. Я бы исходил из осторожного допущения, что при нескольких ролях побеждает более широкая видимость, но проверьте это на тестовой учётной записи у себя, а не считайте установленным фактом.

Отсюда практическое правило: не лепите ролей «на всякий случай». Лучше завести одну роль «Клиент-согласующий» с точным набором прав, чем выдавать две и гадать, что получится в сумме. Чем меньше пересечений, тем проще объяснить, почему человек видит то, что видит.

Роли в проектах Сергея тоже работают по этому принципу, но тут пересечения нет по построению: в «Альфе» у него роль «Исполнитель», в «Бете» — тоже «Исполнитель», и это две независимые записи членства. Права в одном проекте не просачиваются в другой, потому что роли привязаны к проекту.

Покажем объединение прав на цифрах из нашего примера. Пусть роль «Клиент» разрешает создавать обращения и комментировать, но не вносить время, а роль «Согласующий» разрешает менять статус задачи. Ирина с обеими ролями в «Альфе» сможет и создавать обращения, и менять статус: итог равен сумме. Отнять у неё право создавать, добавив третью, более строгую роль, не получится: объединение права только прибавляет. Чтобы сузить доступ, нужно убрать лишнюю роль у Ирины, а не добавлять ограничивающую.

То же верно и для Сергея, но в обратную сторону от опасений: в «Альфе» и «Бете» у него отдельные членства, и сложение происходит только внутри одного проекта. Если в «Бете» Сергея однажды сделают ещё и «Менеджером», расширится его работа только в «Бете», а в «Альфе» ничего не изменится. Поэтому при аудите прав смотрите на каждый проект отдельно, строка за строкой: человек, проект, список его ролей.

Время и пользователи: отдельные ручки

Вернёмся к опасению про время. Сергей вносит затраты: два часа на обращение «Беты», час на обращение «Альфы». Хорошо, если клиент не видит чужие часы, но нужно и то, чтобы Ирина не видела часы коллег внутри своего проекта, если это не предусмотрено договором.

По документации, видимость учёта времени и видимость пользователей — это отдельные свойства роли. То есть они не следуют автоматически за видимостью задач. Можно разрешить клиенту видеть все задачи проекта и при этом не показывать ему затраченное время, а можно наоборот. Это стоит решить явно, а не оставить по умолчанию.

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

Рассмотрим две договорённости на примере наших клиентов. Пусть «Альфа» платит за почасовую поддержку, а «Бета» — фиксированную абонентскую плату. Для «Альфы» имеет смысл дать клиентской роли просмотр затраченного времени: Ирина сверяет часы со счётом и не спорит. Для «Беты» время лучше скрыть: Олег увидит три часа на задачу, которую считал пятиминутной, и вместо обсуждения результата начнётся обсуждение трудоёмкости.

Поскольку видимость времени и видимость пользователей задаются отдельно от видимости задач, обе роли «Клиент» можно сделать разными по этим свойствам, не трогая остальное. Практичнее завести две клиентские роли — «Клиент (почасовой)» и «Клиент (абонент)» — чем менять одну роль под всех. Тогда состав прав каждого клиента виден по названию роли, и при проверке не нужно вспоминать, кому что обещали.

С видимостью пользователей история похожая. Когда клиент видит список пользователей, он может увидеть имена людей, которые не его сотрудники: например, Сергея и ещё двух инженеров вашей команды. Для большинства это безобидно. Но если в проекте участвуют субподрядчики, которых вы не хотите раскрывать, ограничьте видимость пользователей у клиентской роли. И заодно проверьте, что имя и почта Сергея не попадают туда, куда не нужно: например, в карточки задач, где автор отображается по имени. Настройка роли не отменит того, что в задаче, которую создал Сергей, виден её автор.

Передача обращения другому специалисту

Через полгода Сергей уходит в отпуск, и обращения «Беты» берёт Марина. Здесь два подвода, о которых легко забыть.

Первый — членство. Если Марина не состоит в проекте «Поддержка — Бета», назначить ей задачу нельзя, а если в «Альфе» она тоже состоит, ей откроются обращения обоих клиентов. Нужно ли это? Если Марина подменяет Сергея только по «Бете», добавляйте её только в проект «Беты». Принцип минимума здесь стоит приятным бонусом: человек видит ровно то, что ему передали.

Второй подвод связан с режимом видимости «только назначенные мне». Если у исполнителя стоит такой режим, а обращение осталось назначено на Сергея, Марина его не увидит, пока не станет исполнителем. Поэтому при передаче порядок такой:

1. добавить Марину в нужный проект с ролью исполнителя;
2. назначить ей обращения, которые нужно подхватить;
3. проверить под её учётной записью, что она видит всё нужное и не видит лишнего;
4. убедиться, что за Сергеем остались только те задачи, которые ему ещё нужны.

Для исполнителя я бы вообще не использовал строгий режим «только назначенные»: именно из-за таких передач. Исполнитель, который видит весь проект, в отпуск уходит без паники, потому что чужие задачи не пропадают из поля зрения.

Когда договор закончился

Завершение работы с клиентом — момент, о котором вспоминают реже всего. Контракт с «Альфой» закрыт, а Ирина продолжает заходить в систему и видеть историю. Это не катастрофа, но в ней сидят детали договорённостей, которые клиенту больше не нужны, а вам не хочется, чтобы они оставались доступны бессрочно.

Здесь поможет то, что доступ привязан к членству в проекте. Убрать Ирину из участников «Поддержки — Альфа» — значит закрыть ей путь в этот проект. История задач при этом сохранится у вас, а клиентские учётные записи, не состоящие больше ни в одном проекте, удобно заблокировать. Если сотрудник клиента был участником только одного проекта, после удаления членства ему просто нечего показывать.

Если вы хотите сохранить архив, но закрыть изменения, подумайте о том, чтобы перевести проект в закрытое состояние, а не удалять: так история остаётся для вас, а новых обращений в нём не появится. Как именно поведёт себя интерфейс для разных ролей при закрытии, проверьте на тестовом проекте.

Проверка на утечки: как убедиться, что стены стоят

Настроить роли — половина дела. Вторая половина — убедиться глазами пользователя. Для этого заведите две тестовые учётные записи: «Клиент Альфы» и «Клиент Беты». Войдите под каждой в отдельном окне и пройдите по списку:

• видны ли в списке проектов чужие проекты;
• что показывает общий список задач, когда открыт без выбора проекта;
• попадают ли чужие обращения в поиск;
• видны ли чужие затраты времени в отчётах и в журнале затрат;
• что показывает список пользователей;
• что будет, если подставить в адрес номер чужой задачи: возвращается ли страница с содержимым или отказ в доступе;
• какие письма с уведомлениями получает клиент и нет ли в них имён чужих проектов.

Последний пункт часто упускают. Уведомления — это отдельный канал, и в письме о задаче может прозвучать название проекта или список наблюдателей. Проверьте не только экран, но и входящую почту тестовой учётной записи.

И ещё одна проверка — под учётной записью Сергея. Он должен видеть оба проекта, но по-прежнему работать с ними раздельно: фильтры по проекту, отчёты по времени отдельно для «Альфы» и «Беты». Общего «зеркала», где клиенты видят друг друга, нет и быть не должно: исполнитель видит оба мира, а каждый клиент только свой. Про особенности самой платформы, её скорость и устаревшие места рассказано в материале про Redmine в 2026 году, он пригодится, если вы выбираете, стоит ли строить на этом сервис для клиентов.

Где разместить такую систему

Раз уж в системе живут данные нескольких клиентов, имеет смысл держать её на сервере, которым вы управляете сами: вы определяете, кто имеет доступ к самой машине и базе, а не только к интерфейсу Redmine. Для небольшого числа клиентов подойдёт скромный VPS; тарифы MAATRIX начинаются с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и растут до Djed (16 vCPU, 32 ГБ, 320 ГБ). Выбор ресурсов зависит от вашей нагрузки, и по цифрам тарифа нельзя заранее сказать, сколько клиентов выдержит система: это стоит проверять на практике. На VPS даётся root-доступ, серверы доступны в UK, US, RU и FR, а оплата возможна картой РФ и через СБП. Подробности и актуальное наличие образов смотрите на странице аренды VPS MAATRIX.

Как выглядит результат

Вернёмся к Сергею. Ирина заходит в «Поддержку — Альфа», видит свои обращения и их статусы: «новое», «в работе», «ждёт ответа». Открывает карточку, читает комментарий исполнителя и отвечает. Ни проекта «Беты», ни её сотрудников, ни её часов она не видит. Олег, зайдя в свой проект, получает такую же картину про свои кассы.

Сергей начинает день с двух проектов, переключается между ними и ведёт учёт времени отдельно по каждому. Внутренние заметки он оставляет приватными, а передачу дел Марине проводит одним добавлением в нужный проект. Витрины, где клиенты наблюдают друг за другом, нет: есть два закрытых пространства и один специалист, у которого ключи от обоих.