summaryrefslogtreecommitdiff
path: root/rt/docs/design_docs/basic-definitions.txt
blob: 23d2c574821d5f8d27de6c7970375e0a32e7957f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
(todo ... basically, those are untouched from 1.0)
Ticket
Queue
(...more?)

Requestor

  (...definition of a requestor .. blahblah)

  I'm often doing a distinction between "Internal Requestors" and "External
  Requestors" (see below).  The system doesn't make any difference between
  requestors, but the distinction might be useful to discuss usage patterns,
  templates and configurations.


External Requestor

  Might be a customer or a potential customer.  The External Requestor
  should be treated as a VIP.  (S)he shouldn't need to see too much of RT.
  The support (s)he gets should be as personal as possible.  The external
  requestor might eventually get access to the Web UI, but only to track
  her/his own requests.  If you're not planning to use RT for handling
  external customers, all your requestors are probably "Internal
  Requestors".


Watcher

  Somebody that are "subscribing" to a queue or a ticket (or something
  differently).  Basicly, somebody watching a queue or a ticket should get
  all updates by email.  A requestor is a (special) watcher.


Regular Watcher

  People within the same organization, people that have read access to whole
  queues.

  I consider "Regular Watchers" as well as "Internal Requestors" as more
  robust and capable human beeings than the fragile customers.  We don't
  mind letting them get entagled with RT, and we let them access the Web UI.
  They can live with beeing just the Cc or Bcc at an email.


Internal Requestor

  An Internal Requestor is usually internal to the company.  He might be 1st
  line support sending matters to tech support or similar. Might be an
  internal employee sending matters to tech support (or even 1st line
  support if he's not sure where to send matters).  It might also be that
  "ordinary" requestors actually might be treated as intelligent human
  beeings rather than VIPs, i.e. in open source projects ... we'll still
  call them "Internal Requestors" as they don't need the special VIP
  treatment.