2013-08-07 12:01:49 -04:00
|
|
|
# See zulip_trac.py for installation and configuration instructions
|
2013-02-13 13:47:23 -05:00
|
|
|
|
|
|
|
# Change these constants to configure the plugin:
|
2013-08-07 12:01:49 -04:00
|
|
|
ZULIP_USER = "trac-bot@example.com"
|
|
|
|
ZULIP_API_KEY = "0123456789abcdef0123456789abcdef"
|
2013-02-13 13:47:23 -05:00
|
|
|
STREAM_FOR_NOTIFICATIONS = "trac"
|
|
|
|
TRAC_BASE_TICKET_URL = "https://trac.example.com/ticket"
|
|
|
|
|
2013-02-13 15:52:47 -05:00
|
|
|
# Most people find that having every change in Trac result in a
|
|
|
|
# notification is too noisy -- in particular, when someone goes
|
|
|
|
# through recategorizing a bunch of tickets, that can often be noisy
|
2013-02-13 16:28:19 -05:00
|
|
|
# and annoying. We solve this issue by only sending a notification
|
|
|
|
# for changes to the fields listed below.
|
2013-02-13 15:52:47 -05:00
|
|
|
#
|
2016-01-09 23:21:31 -05:00
|
|
|
# TRAC_NOTIFY_FIELDS lets you specify which fields will trigger a
|
|
|
|
# Zulip notification in response to a trac update; you should change
|
|
|
|
# this list to match your team's workflow. The complete list of
|
|
|
|
# possible fields is:
|
|
|
|
#
|
2013-02-13 15:52:47 -05:00
|
|
|
# (priority, milestone, cc, owner, keywords, component, severity,
|
2013-02-13 16:28:19 -05:00
|
|
|
# type, versions, description, resolution, summary, comment)
|
2013-08-07 12:01:49 -04:00
|
|
|
TRAC_NOTIFY_FIELDS = ["description", "summary", "resolution", "comment", "owner"]
|
2013-02-13 15:52:47 -05:00
|
|
|
|
2013-08-06 15:32:15 -04:00
|
|
|
## If properly installed, the Zulip API should be in your import
|
2013-02-13 13:47:23 -05:00
|
|
|
## path, but if not, set a custom path below
|
2013-08-07 12:01:49 -04:00
|
|
|
ZULIP_API_PATH = None
|
2013-02-13 15:52:47 -05:00
|
|
|
|
2015-08-21 12:34:54 -04:00
|
|
|
# Set this to your Zulip API server URI
|
2016-11-04 15:16:57 -04:00
|
|
|
ZULIP_SITE = "https://zulip.example.com"
|