Commit graph

22 commits

Author SHA1 Message Date
Lin Jen-Shin
8c0b619d40 Split tests into their own classes 2016-05-24 17:30:36 +08:00
Lin Jen-Shin
1f5d55907a Merge the places where exceptions could be raised 2016-05-24 01:23:07 +08:00
Lin Jen-Shin
c2bc15a766 Use the authentication_token for finding the user 2016-05-20 17:38:08 -05:00
Lin Jen-Shin
9436a444f3 Rename reply_key to mail_key 2016-05-20 13:05:57 -05:00
Lin Jen-Shin
4b341dea55 Actually there's no such case 2016-05-20 12:52:53 -05:00
Lin Jen-Shin
a7c823a573 Give ProjectNotFound when the project is not readable 2016-05-18 17:57:14 -05:00
Lin Jen-Shin
c337e748d3 so we use separate classes to handle different tasks 2016-05-18 17:25:45 -05:00
Lin Jen-Shin
8156475ea5 Report better errors. TODO: Enable skipped test 2016-05-16 21:27:16 +00:00
Lin Jen-Shin
a065c8d5d8 Create a new issue via: incoming+group/project+AUTH_TOKEN@... 2016-05-16 21:27:16 +00:00
Lin Jen-Shin
347ee6cc91 Alloy empty reply for new issues, but not response 2016-05-16 21:27:16 +00:00
Lin Jen-Shin
6cfd028278 Implement #3243 New Issue by email
So we extend Gitlab::Email::Receiver for this new behaviour,
however we might want to split it into another class for better
testing it.

Another issue is that, currently it's using this to parse project
identifier:

    Gitlab::IncomingEmail.key_from_address

Which is using:

    Gitlab.config.incoming_email.address

for the receiver name. This is probably `reply` because it's used
for replying to a specific issue. We might want to introduce another
config for this, or just use `reply` instead of `incoming`.

I'll prefer to introduce a new config for this, or just change
`reply` to `incoming` because it would make sense for replying to
there, too.

The email template used in tests were copied and modified from:
`emails/valid_reply.eml` which I hope is ok.
2016-05-16 21:27:16 +00:00
Lin Jen-Shin
2375b437bd Fix a typo 2016-05-16 21:27:16 +00:00
Rémy Coutable
9f218fc184 Improve and finish the fallback to the In-Reply-To and References header for the reply-by-email feature
A few things to note:
- The IncomingEmail feature is now enabled even without a
  correctly-formatted sub-address
- Message-ID for new thread mail are kept the same so that subsequent
  notifications to this thread are grouped in the thread by the email
  service that receives the notification
  (i.e. In-Reply-To of the answer == Message-ID of the first thread message)
- To maximize our chance to be able to retrieve the reply key, we look
  for it in the In-Reply-To header and the References header
- The pattern for the fallback reply message id is "reply-[key]@[gitlab_host]"
- Improve docs thanks to Axil
2016-03-25 13:05:15 +01:00
David Padilla
31e76baf61 Fix #2364. Fall back to In-Reply-To header when reply key not available 2016-03-25 13:05:15 +01:00
Douwe Maan
1e927d39b4 Update spec 2016-01-07 15:51:12 +01:00
Douwe Maan
13d6bab177 Tag lib specs 2015-12-09 11:55:42 +01:00
Douwe Maan
ee028d9d60 Rename reply_by_email to incoming_email to prepare for the future. 2015-09-21 10:35:37 +02:00
Douwe Maan
69708dab9f Block blocked users from replying to threads by email. 2015-08-21 10:14:45 -07:00
Douwe Maan
48e25a019a Add stub_reply_by_email_setting helper. 2015-08-20 13:21:22 -07:00
Douwe Maan
54b04f1c5b Add fixture_file helper. 2015-08-20 12:41:47 -07:00
Douwe Maan
2b5a2b8f39 Removed unused fixtures. 2015-08-20 12:29:03 -07:00
Douwe Maan
8ec5fb138d Test Gitlab::Email::Receiver. 2015-08-20 12:17:59 -07:00