Paul Martin
2016-04-30 a502d96a860456ec5e8c96761db70f7cabb74751
commit | author | age
5e3521 1 ## Setting up Tickets
JM 2
5d0f71 3 *SINCE 1.4.0*
5e3521 4
JM 5 By default, Gitblit is not configured for Tickets.  There are several reasons for this, but the most important one is that you must choose the persistence backend that works best for you.
6
7 ### tickets.service
8
9 *RESTART REQUIRED*
10
11 The hardest part of setting up Gitblit Tickets is deciding which backend to use.  Three implementations are provided, each with different strengths and weaknesses.
12
13 #### File Ticket Service
14
15     tickets.service = com.gitblit.tickets.FileTicketService
16
17 Your ticket journals are persisted to `tickets/{shard}/{id}/journal.json`.  These journals are stored on the filesystem within your .git directory.
18
19 #### Branch Ticket Service
20
21     tickets.service = com.gitblit.tickets.BranchTicketService
22
c134a0 23 Your ticket journals are persisted to `id/{shard}/{id}/journal.json`.  These journals are stored on an orphan branch, `refs/meta/gitblit/tickets`, within your repository.  This allows you to easily clone your entire ticket history to client working copies or to mirrors.
5e3521 24
JM 25 #### Redis Ticket Service
26
27     tickets.service = com.gitblit.tickets.RedisTicketService
28
29 Your ticket journals are persisted to a Redis data store.  *Make sure you configure your Redis instance for durability!!*  This particular service is highly-scalable and very fast.  Plus you can use all of the power of Redis replication, should you want.
30
5b3669 31 The main drawback to this service is that Redis is primarily a Unix tool and works best on a Unix server.  Microsoft is engaged with the Redis community and they do maintain a semi-active port of Redis for Windows servers.
5e3521 32
JM 33     tickets.redis.url = redis://(:{password}@){hostname}:{port}(/{databaseId})
34
35 **examples**
36
37     tickets.redis.url = redis://localhost:6379
38     tickets.redis.url = redis://:password@localhost:6379/2
39
40 ### Other Settings
41
42 You should also review the following settings before using Gitblit Tickets to understand what controls are available.
43
44 #### web.canonicalUrl
45
46     web.canonicalUrl = https://localhost:8443
47
48 The Tickets feature sends rich email notifications to those who are participating or watching a ticket.  In order for the links in those emails to work properly, you really should set the canonical web url of your Gitblit install.  This url should be your public url used to browse and navigate the website.
49
50 #### tickets.acceptNewTickets
51
52     tickets.acceptNewTickets = true
53
54 This setting is used to globally disable manual creation of tickets through the web ui.  You may still create proposal tickets by pushing patchsets.
55
56 You may decide to disable creation of new tickets at the repository level in the *Edit Repository* page, however if this global setting is false, it will trump the repository setting.
57
58 #### tickets.acceptNewPatchsets
59
60     tickets.acceptNewPatchsets = true
61
62 This setting is used to globally disable accepting new patchsets.  If this set false, you can not create proposal tickets BUT you can still create tickets through the web ui, assuming *tickets.acceptNewTickets=true*.
63
64 You may decide to disable accepting new patchsets at the repository level in the *Edit Repository* page, however if this global setting is false it will trump the repository setting.
65
66 #### tickets.requireApproval
67
68     tickets.requireApproval = false
69
70 This setting is the default for requiring an approve review score (+2) before enabling the merge button in the web ui.  This setting is not considered during the push process so an integrator may push a merged ticket disregarding this approval setting.  The setting only affects the web ui and may be configured per-repository.
71
72 #### tickets.indexFolder
73
74 *RESTART REQUIRED*
75
76     tickets.indexFolder = ${baseFolder}/tickets/lucene
77
78 This is the destination for the unified Lucene ticket index.  You probably won't need to change this, but it's configurable if the need arises.
79
80 ### Setting up a Repository
81
82 #### Controlling Tickets
83
84 Each repository can accept or reject tickets and/or patchsets by the repository settings.
85
86 ##### Issue-Tracker, no patchsets
87
88     allow new tickets = true
89     accept patchsets = false
90
91 ##### Proposals only, no user-reported issues
92
93     allow new tickets = false
94     accept patchsets = true
95
96 ##### Issue-tracker AND Proposals
97
98     allow new tickets = true
99     accept patchsets = true
100
101 ##### No tickets whatsoever
102
103     allow new tickets = false
104     accept patchsets = false
105
106 #### Controlling Merges
107
108 Gitblit has a simple review scoring mechanism designed to indicate overall impression of the patchset.  You may optionally configure your repository to require an approval score for a patchset revision BEFORE the Merge button is displayed/enabled.  This per-repository setting is not respected if an integrator pushes a merge.  This setting is only used to control the web ui.
109
110 #### Milestones
111
a5086d 112 Milestones are a way to group tickets together.  Milestones are specified for each repository and are stored in the repository git config file.  Repository owners may create milestones through the web ui in the *Tickets* page on the *Milestones* tab.
5e3521 113
JM 114     [milestone "v1.5.0"]
115         status = Open
116         due = 2014-06-01
117         color = "#00f000"
118
119 Please note the date format for the *due* field: yyyy-MM-dd.