Request Tracker Wiki - User contributions [en]

ManualTicketDates

2022-11-01T16:26:26Z

Sunnavy: /* Started */

Up: [[ManualUsingWebInterface]]

----

= Introduction =

Tickets in RT have several date fields:

* Created
* Starts
* Started
* Last Contact
* Due
* Closed
* Updated

Starts and Due dates work like expected (planned) time boundaries, while Started, Last Contact, Closed, and Updated are set after things happen. How this works is described below.

= Description =

== Created ==

This is the first date that is set during creation of a ticket and cannot be changed using the UI.

== Starts ==

Starts date is used to indicate the time when staff expects to begin to work on the current ticket. Editable and optional.

== Started ==

RT uses Started date to indicate the time when a user actually begins work on the ticket. This date is set to "now" automatically when status of the ticket is changed from initial(e.g. 'new') to any other non-initial values. So if the server is configured to 'auto open' tickets on correspond, then it's set on correspond. However, if somebody opens it before any correspondence then it's also set.

Try next tests:

* create a ticket, click the open action and look on the dates box
* create a ticket, click the resolve action and look on the dates box

== Starts vs. Started ==

There are no restrictions on these dates, so work on ticket could begin (started) earlier than it was expected (starts) or vice versa.

== Last Contact ==

Is set when inbound user replies to a ticket or can be set manually. Last time that requestors were notified by someone.

== Due ==

Due date defines a deadline for the ticket. You can implement SLA or projects' deadlines using this field. Editable and optional.

== Updated ==

This date is set automatically to now when ticket is changed in any way.

= Changing dates =

Users who have the correct rights can set Starts, Started, Last Contact, and Due dates. These dates and others can be set automatically as described above.

To change a date, open a ticket and click on title of the 'Dates' box or 'Dates' subtab in the menu. From this page, you can adjust dates of the ticket.

To change any of these dates, type the new date in the text box or use the calendar popup to pick a date, then click the Submit button.

'''NOTE:''' Acceptable date formats such as mm/dd/yy or dd/mm/yyyy vary by organization and country. If you're not sure, ask an administrator how to enter dates. Administrators can consult with [https://metacpan.org/pod/Time::ParseDate manual] for a date parsing perl module.

Dates can also be changed from the bulk update option. See [[ManualTicketsBulkUpdate]].

== Unset (delete) Date ==

To delete date or clear date, simply remove the date from the text box and save. This will change the date field to "not set".

= Searching by dates =

It's possible to search using not only absolute dates like '2009-11-30', but also relative dates like '7 days ago'. This is described more in details at [[TicketSQL#Date Syntax|Ticket SQL]].

= Working with date in scripts =
If you need to search for the dates in script, consult [https://docs.bestpractical.com/rt/4.4.4/RT/Date.html official docs]. To display the correct local time shift use <tt>Timezone => ‘user’</tt> in your functions. Example:
$date->Set(Format => ‘ISO’,Value => $ticket->Created);
say $date->LocalizedDateTime(Timezone => ‘user’);
say $date->ISO(Timezone => ‘user’);

----

Up: [[ManualUsingWebInterface]]
[[Category:RT User Manual]]
[[Category:RT44]]

Integrating RT Email with Google Mail (Gmail)

2022-05-19T14:23:18Z

Sunnavy: Created page with "== Incoming emails == Assuming "your_account@gmail.com" is RT's correspond address: Set( $CorrespondAddress, 'your_account@gmail.com' ); === Using getmail 5.6+ to fetch emails === ==== Set up OAuth2 client on google side ==== Based on https://developers.google.com/identity/protocols/oauth2/native-app, here are some notes: Enable "Gmail API" On "OAuth consent screen" create, select "Internal" user type, add scrop: "Gmail API .../auth/gmail.modify Read,..."

== Incoming emails ==

Assuming "your_account@gmail.com" is RT's correspond address:

Set( $CorrespondAddress, 'your_account@gmail.com' );

=== Using getmail 5.6+ to fetch emails ===

==== Set up OAuth2 client on google side ====

Based on https://developers.google.com/identity/protocols/oauth2/native-app, here are some notes:

Enable "Gmail API"

On "OAuth consent screen" create, select "Internal" user type, add scrop: "Gmail API .../auth/gmail.modify Read, compose, and send emails from your Gmail account"

On client id create, set the application type to "Desktop app"

Save the "Client ID" and "Client secret" values, which we will need in the next step.

==== Setup getmail on RT server ====

Based on https://www.bytereef.org/howto/oauth2/getmail.html

1. Get initial OAuth2 token

Create /home/user/.getmail/gmail.json

{"scope": "https://mail.google.com/",
"user": "your_account@gmail.com",
"client_id": "xzy.apps.googleusercontent.com",
"client_secret": "foo",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"redirect_uri": "http://localhost/",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs"}

Fill "client_id" and "client_secret" with the real values from previous step.

Note that redirect_uri "urn:ietf:wg:oauth:2.0:oob" does '''not''' work any more, we need to give it a URL, which google will redirect to once user approves the access.

chmod 600 /home/user/.getmail/gmail.json

Then run command:

getmail-gmail-xoauth-tokens --init /home/user/.getmail/gmail.json

It outputs a google URL, go to that URL and approves it as "your_account@gmail.com", which will redirects to URL like:

http://localhost/?code=A-VERY-LONG-STRING&scope=https://mail.google.com/

Copy the code value from URL and paste it to the previous getmail-gmail-xoauth-tokens command window, then hit "Return".
If everything goes well, getmail-gmail-xoauth-tokens shall quit silently.

2. Fetch emails

Create /home/user/.getmail/getmailrc

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = your_account@gmail.com
use_xoauth2 = True
password_command = ("getmail-gmail-xoauth-tokens", "/home/user/.getmail/gmail.json")

[destination]
type = MDA_external
path = /opt/rt5/bin/rt-mailgate
user = root
group = root
arguments = ("--url", "http://localhost", "--queue", "General", "--action", "correspond",)

[options]
read_all = false

Test it:

/usr/bin/getmail --rcfile=/home/user/.getmail/getmailrc

Then edit /etc/cron.d/rt to fetch mail regularly:

*/3 * * * * user /usr/bin/getmail --rcfile=/home/user/.getmail/getmailrc --quiet

== Outgoing emails ==

=== Route through Google ===

Based on https://support.google.com/a/answer/2956491, here are a few extra notes:

In step 6(Allowed senders section), choose "Only addresses in my domains"
In step 7(Authentication section), choose "Only accept mail from the specified IP addresses", do '''not''' choose "Require SMTP Authentication"
In step 8(Add allowed IP), add public IP address of RT server

Turn on sender envelope in RT site config:

Set( $SetOutgoingMailFrom, 1 );

Reminders

2021-11-29T20:49:08Z

Sunnavy:

'''Reminders''' can be attached to a particular ticket (and are really tickets themselves).

Each Reminder has:

* Subject
* Owner
* Due date
* Status (new, open, resolved, ...)

When given an Owner and a Due date, the Reminder will appear on that person's "At-a-glance" page by default.

You can setup RT to send notification emails about reminders due soon using [[UseRtCrontool|rt-crontool]]. Add a line like the one below to your RT crontab:

0 6 * * * root /opt/rt4/bin/rt-crontool \
--search RT::Search::FromSQL \
--search-arg 'Type = "reminder" and (Status = "open" or Status = "new")' \
--condition RT::Condition::BeforeDue \
--condition-arg 2d \
--action RT::Action::SendEmail \
--action-arg Owner \
--transaction first \
--template 'Reminder due soon'

And create a Template (Tools → Configuration → Global → Templates → Create) named "Reminder due soon" with the following Content:

To: { $Target = $Ticket->RefersTo->First->TargetObj; ($Argument eq 'TicketOwner' ? $Target : $Ticket)->OwnerObj->EmailAddress }
Subject: {$Ticket->Subject} is due {$Ticket->DueObj->AsString}

Just a friendly heads up. This reminder is for ticket #{$Target->Id}.

{RT->Config->Get('WebURL')}Ticket/Display.html?id={$Target->Id}

This will send a notification email to the Owner of the reminder 2 days before it is due.

For third-party contributed reminder notification utilities, see:

* [[DueDateRemindersByEmail]]
* [[rt-reminder]]
* [[rtReminderMails]]
* [[UseRtReminder]]

EmailInterface

2018-05-16T19:48:38Z

Sunnavy:

== RT's config file ==

You should start configuration from [[SiteConfig|SiteCo]], all options are briefly described in the main config template, so here we'll try to add additional information that will help you understand importance of each option. As it's not complete description then you '''MUST''' always read description in the main config file.

Very '''important''' options are OwnerEmail, RTAddressRegexp and NotifyActor.

=== Basic options ===

'''$rtname''' (scalar) - name of the RT instance, is used in subject of emails to get/store ID of tickets. See also [[RenameInstance]].

RT 3.8 has subject tag option per each queue that can allow you override strings used in subject.

'''$SendmailArguments''' (string) -- To change the return-path, you need to add the -f switch followed by your email address e.g.: <code>-oi -t -f whatever(leftbracket)at(rightbracket)yourdomain.tld</code>

'''$OwnerEmail''' (email address) - address of RT's administrator important error messages are send to.

=== Loops prevention ===

'''$LoopsToRTOwner''' (boolean) - send or not loops to owner

'''$StoreLoops''' (boolean) - record message even if it's loop

'''$RTAddressRegexp''' (regular expression) - used to prevent RT from ending up in a loop within itself, for example when '''$ParseNewMessageForTicketCcs''' is enabled. This can get complicated if there are several names for the server; for this reason, it's recommended you place your RT email addresses into a namespace such as <code>rt-foo\@example.com</code>, <code>rt-bar\@example.com</code>, etc. to make this as straightforward as possible.
#See also [[RTAddressRegexp]] which describes how to write this regular expression.

=== Attachments handling ===

'''$MaxAttachmentSize''' (int, bytes) - sets the maximum size of attachments stored in the database

$TruncateLongAttachments, '''$DropLongAttachments''' (boolean) - truncate or drop long attachments, note that truncation most probably will corrupt binary files, like images, word documents and other.

=== Other options ===

'''$ParseNewMessageForTicketCcs''' (boolean) - when '''$ParseNewMessageForTicketCcs''' is true, RT automatically adds email addresses found in the Cc header to the ticket's Cc at creation.

See also [[ParseFollowupMessageForTicketCcs]].

'''$NotifyActor''' (boolean) - normally, when someone updates a ticket, etc., email is sent to the apropriate people, excluding the person who performed the action. RT reasons the person knows what they did. If '''$NotifyActor''' is set to a true value (e.g. 1, or just about anything but 0 or empty string), the performer of the action will be included in the notifications. Default is false (0).

== RT's mail gate ==

RT handles its incoming emails with a rt-mailgate script that passes emails over http protocol to a RT's web server.

Note that the HTTP interface used by mailgate is not protected by default and you '''must''' take care of it yourself. Read [[MailGatewayAccessControl]] to understand how to '''improve security''' of this interface.

First of all you have to add email aliases for each queue. See the following:

* [[ManualInstallation]]
* [[Qmail]] - Using Qmail Aliases w/ RT
* [http://web.archive.org/web/20070703225014/http://www.geert.triple-it.nl/node/rt_procmail.html Using Procmail to deliver RT-mail to queues]
* [[EximConfig]]
* [[EximConfigVirtualDomain]]
* [[PostfixConfig]]

=== Delivering mail without many aliases ===

* [[SendmailWithoutQueueAliases]]
* [[ConfigEximFromRTDB]]

=== Fetching emails from POP/IMAP/MBOXes ===

The following articles describe several ways to obtain incoming email for RT from POP/IMAP servers or mboxes:

* [[fetchmail]]
* [[Mbox2Rt]]
* [[POP3Mailgate]]

=== Mail server is another host ===

You can install the mailgate script on any server that has access by http(s) to a server you're running RT on. Read [[InstallMailgateOnly]].

=== Handling spam ===

* [[SpamFiltering]]

=== Handling bounces ===

* [[RtBounceHandler]]

=== Other ===

* [[EmailRouting]]
* [[html2mime]]
* [[VirtualDomain]]
* [[MSExchangeRelay]] - Configure Exchange to relay mail to and from RT
* [[PostFixSQLAliasProblem]] - Problems with alias map in a Postfix SQL database.
* [[GoogleApps]] - How to configure RT for use with [[GoogleApps]].

= Configuring outgoing email =

== Technical part ==

Outgoing emails can be sent using a command line program (like sendmail) or via SMTP server. It's recommended to use a robust command line program to avoid penalties. You may read '''perfomance considerations''' on [[SendmailTips]] page.

Notifications and other outgoing emails are controlled by [[Scrip]]s. You can change them using the web UI.

== Config ==

'''DESCRIBE ME'''

== Sending via SMTP server ==

* [[mailx]] - Sending outgoing email from RT to a remote smtp-server instead of a local MTA
** mailx is a poor option. It will always override your /Content-Type/ headers, and so can't properly handle email attachments as it will replace the /multipart/mime; boundary=xxxxxx/ header with /text/plain/. -- comment from a user
* [[msmtp]] is a great option. It's very easy to use, supports attachments, TLS.

== Configuring notification scrips ==

* [[ManualScrips]] - default set of scrips
* [[ScripAction]] - basics on creating a new actions
* [[NotificationsTuning]] - very good article on tuning notifications

== Other ==

* [[MultipleOutgoingEmailAddresses]]
* [[SuppressOutgoingMail]]