summaryrefslogtreecommitdiff
path: root/rt/docs/design_docs/subscription-definitions.txt
blob: deda35cda4a8a42d61688f887b0550393bb13db8 (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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
NEW SCRIP NOTES


RT Actions:


   EmailOwnerAsComment
	Send mail to the ticket owner from the queue's comment address
	
   EmailOwnerOrAdminWatchersAsComment
	Send mail to the ticket owner, or if there is no owner, the ticket's admin watchers
	from the queue's comment addresses

   EmailAdminWatchersAsComment
	Send mail to the ticket's adminstrative watchers from the queue's comment address



   EmailOwner
	Send mail to the ticket owner from the queue's correspond address
	
   EmailOwnerOrAdminWatchers
	Send mail to the ticket owner, or if there is no owner, the ticket's admin watchers
	from the queue's correspond addresses

   EmailAdminWatchers
	Send mail to the ticket's adminstrative watchers from the queue's correspond address

   EmailWatchers
	Send mail to the ticket watchers from the queue's correspond address

   AutoReply 
	Sendmail to the requestor from the queue's correspond address.
	     
   

RT Conditions:
   OnCreate
   OnEachTransaction
   OnComment
   OnCorrespond
   




What is an Action?

...some piece of code that can do something whenever a transaction is done.
The actions shipped with RT sends email and can handle some logic that makes
sense for some instances.  site-specific modules can be dropped in to
perform special actions.


What can an Action do?

- decide whether it's applicable or not
- prepare
- commit
- describe itself

...and if it's a subclass of SendEmail, you can also override a lot.

Currently the schema.mysql contains a list of the basic subscription-related
actions that will be bundled with RT.


What is a Scrip?

...it's an entry in the database that tells that an action is to be
performed with a certain template and argument.  Template and argument
doesn't make sense in all contexts.  A scrip can be limited to transaction
types; the current implementation allows a comma-separated list (though for
a "cleaner" schema design, it should be a separate table for this?).  It has
a name and a description.


What is a ScripScope?

...an indication of what queues the different Scrips applies to.  It should
be easy to remove/insert ScripScope objects by the admin tools.


What is a Watcher?

...it's a request for beeing kept updated on a ticket and/or a queue
and/or whatever.  It is to be used by the Actions.  Watcher items can
easily be enabled/disabled through the `Quiet' attribute.  `Type' might
indicate what emails the watcher wants to get and how to get them.

The Bcc/Cc watchers should be handled by the NotifyWatchers action which is
run regardless of the Scrips.


What is a Template?

...A template is a text template that is to be used for outgoing email -
or for different use for different actions.  One template can be used by
several Scrips.


How does the system determinate whom to send mail to?

The ScripScope table in the DB should indicate whether a Scrip is relevant
for a queue or not /* TobiX thinks that this might eventually be extended to
keywords, tickets, etc, and not only Queues */ ... the Scope table should
indicate whether the Scrip is relevant for a given transaction type ... then
the given Action should determinate whether it applies or not, and finally
the Action has to find out (via the Watchers table) whom it applies to, and
how to contact them ... and the Template tells how the mails that are sent
out should look like.