import rt 2.0.14
[freeside.git] / rt / docs / design_docs / subscription-definitions.txt
diff --git a/rt/docs/design_docs/subscription-definitions.txt b/rt/docs/design_docs/subscription-definitions.txt
new file mode 100755 (executable)
index 0000000..deda35c
--- /dev/null
@@ -0,0 +1,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.
+
+