Как я могу лучше всего воспользоваться Trac?

Ответ 1

1) индикатор прогресса на высоком уровне:

Вкладка "Дорожная карта" дает вам вид индикатора прогресса на высоком уровне. В нем перечислены все этапы, и для каждой вехи он показывает вам:

• название этапа
• краткое описание
• дата, на которую должна быть указана веха
• сколько времени осталось до тех пор (или как долго вы отстаете от графика)
• сколько билетов назначено на эту веху и сколько из них было закрыто, визуализируется как приятный зеленый индикатор прогресса. Эта полоса основана на предположении, что каждый билет имеет тот же вес, что может ввести в заблуждение.

Вы можете ограничить свои права доступа таким образом, чтобы ваш клиент мог получить доступ только к этому представлению.

В зависимости от отношений между вами и вашим клиентом вы можете дать ему возможность создавать новые билеты (разрешение TICKET_CREATE), что должно быть возможно без предоставления ему доступа для чтения к другим билетам (TICKET_VIEW и TICKET_MODIFY). Извините, но я не могу проверить, действительно ли это работает, может быть, кто-то может прокомментировать это.

2) ежедневные сводные отчеты

trac предлагает вам RSS-каналы для всего, о чем вы можете думать. Должно быть возможно генерировать ежедневные отчеты из этого, или вы просто скажете своему клиенту RSS, чтобы проверить канал один раз в день.

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

Другая конфигурация

В каждом проекте, который я делаю с trac, я создаю пользовательский запрос, чтобы перечислить все билеты, которым никто не владеет:

SELECT p.value AS __color__,
   owner AS __group__,
status,
   id AS ticket, summary, component, milestone, t.type AS type, time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
  WHERE status = 'new' AND (owner = '' OR owner = 'somebody'  OR owner = 'None' )
  ORDER BY owner, p.value, t.type, time

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

  SELECT p.value AS __color__,
   (CASE owner WHEN '$USER' THEN 
     (CASE status 
       WHEN 'assigned' 
       THEN 'Tickets that you accepted' 
       ELSE 'Tickets that were assigned to you, please accept or reassign' 
      END) 
     ELSE 'Tickets, that have your name in the cc' END) 
     AS __group__,
   id AS ticket, summary, component, version, milestone,
   t.type AS type, priority, time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
  WHERE t.status  'closed' AND (owner = '$USER' OR cc like '%$USER%')
  ORDER BY owner, (status = 'assigned') DESC, p.value, milestone, t.type, time

(этот код работает в trac 0.11b)

Это мой любимый билет. Он подает билеты тремя классами:

• Билеты, которыми вы владеете и принимаете
• Билеты, которые были назначены вам, но вы еще не приняли
• Билеты, которые у вас есть в cc (что фантастическая вещь, которую вы не получаете без этого запроса)

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

Плагины

Я рекомендую XML RPC-плагин, если вы работаете с eclipse. Он обеспечивает тесную интеграцию с Mylin. (Я думаю, что базовая интеграция работает даже без плагина), поэтому ваши разработчики могут выполнять множество задач из eclipse, не переключаясь на веб-интерфейс trac.

(Если вы используете eclipse, но не знаете mylin, вы должны посмотреть на него. Вы можете протестировать его без какой-либо конфигурации, потому что он поставляется с большинством распределений eclipse и может работать как автономный без trac.)

Ответ 2

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

Ответ 3

Что касается дополнительных плагинов, мы устанавливаем TocMacro, XmlRpcPlugin, WysiwygPlugin и TracRedirect. В частности, плагин WYSIWYG действительно хорош для того, чтобы поощрять меньший технический персонал поддерживать свои собственные документы в вики - вы можете даже C & P из MS Word, сохраняя форматирование, что помогает.

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

Я бы рекомендовал сделать ваш Trac-сервер аутентифицированным в отношении некоторой центральной системы проверки подлинности. Мы запускаем дерево LDAP с учетными данными auth в нем, и это используется всеми нашими внутренними системами, включая trac, svn, samba, openvpn и т.д.

Ответ 4

@Дэйв Данкин прав. Используйте Trac для внутреннего использования и используйте такую ​​систему, как Basecamp, чтобы дать своим клиентам обзор на высоком уровне того, что происходит в проект.

Ответ 5

Если он установлен на складе, база данных - это просто SQLite3, поэтому вы можете легко писать сценарии для получения "безопасной" информации, например, количества билетов или почему бы не один из отчетов. Таким образом, вы можете свободно обсуждать, пока имя билета одобрено. Также доступны версии, этапы, википажи, теги (если вы используете этот плагин).

Ответ 6

Возможно, вы могли бы отозвать все разрешения, кроме ROADMAP_VIEW от анонимного пользователя, но это, вероятно, будет немного слишком на высоком уровне, нет? Контроль доступа на уровне отдельных билетов или комментариев в настоящее время не поддерживается AFAIK. Подробнее о разрешениях трассировки см. http://trac.edgewall.org/wiki/TracPermissions.

Ответ 7

Как указано в одном из комментариев, вы не можете ограничивать доступ к билетам или комментариям на основе пользователя. Поиск или создание внешней системы отчетности - ваш лучший выбор.

Несколько вещей, основанных на опыте с Trac:

• Создание пользовательского workflow довольно прямой froward. Использование GraphViz - огромная помощь для взаимодействующих состояний и действий. Плагин рабочего процесса (например, AdvancedTicketWorkflowPlugin), который дополнительно расширяет встроенную функциональность, не слишком сложно сделать, если вам нужно более сложное состояние взаимодействие.

• Для пользовательской отчетности вы можете написать SQL-запросы, которые принимают именованные параметры, затем ссылку на них со страницы вики:

Например, запрос может содержать предложение WHERE, подобное этому:

WHERE datetime(t.changetime, 'unixepoch') >= datetime('now','-$DAYS days')

и страница wiki может иметь следующее:

Show activity for last [http://server.com/trac/report/9?DAYS=8 8] days.