This commit heavily refactors Email::Receiver to both better handle
different emails and improve testability.
A primary focus of the refactor is reducing the usage of class
variables, in favor of actually passing parameters - making it possible
for multiple tests to use the same Receiver instance.
The EmailLog reported when a topic is created is reflected to put the
user's email in the to_address field, instead of the system address.
The discourse_email_parser function is renamed to
discourse_email_trimmer, and additional stopping conditions are added to
make up for EmailReplyParser's inability to deal with html at the start
of a line.
The force_encoding calls are refactored out to a 'fix_charset' method.
parse_body is renamed to select_body, and the scrub_html method is
dropped in favor of the new HtmlCleaner class.
A new parse_body method is added, which performs the job of the removed
lines of code in the 'process' method.
EmailUnparsableError is redefined again, to be encoding errors (when the
declared encoding is not what was delivered).
This class is in charge of stripping out most of the crap from the HTML
portion of emails that email clients generate, so that it can be sanely
post-processed for signatures and quoting boundaries.
A failure condition is eliminated where a topic would be created, but post
creation would fail, leaving the forum with a topic without any posts.
By asking PostCreator to create the topic instead, inside of its
transaction, this failure condition is eliminated.
Additionally, attachments are restored to working status. Previously,
the attachment code would build up the post raw, but then drop it and
not do anything with the result (creating orphaned uploads). By actually
placing the raw value back in the options hash, it is included in the
created post.
Use "Site Name <>" for the Reply-To header when the reply is to the site or a public topic.
Use "username <>" for the Reply-To header only when the reply is to a private message topic.
It adds a new setting 'email_prefix' to configure which [label] will be used in the subject of emails. Discourse currently uses '[title]'. The problem is that sometimes you need to set a longer title, that doesn't really work well for emails. I think this is very common since the HTML `<title>` tag is very important for SEO.
It will default to '[title]' if this setting is not used.
See: https://meta.discourse.org/t/where-to-change-the-email-subject-prefix/11989
- Replace implicit return code-system in Email::Receiver with proper exception system
- Update tests to check for exceptions instead
- Test the PollMailbox for expected failures
- Add proper email-handling of problematic emails
"
- Adds the advanced option to accept email from non-users per category email-address
- Adds tests covering the new feature
- Adds UI to configure this feature in the frontend
- allow the configuration of an inbox-email-address per category
- post emails to that email into that category instead of global
- Adds UI for configuration
- Adds Documentation for configuration
- Adds Tests for new feature
With the new email_in admin configuration setting, emails to the email_in_address fetched via POP will now be processed and posted as new topics to the forum.
With the email_in_min_trust you can control the trust level the user needs to have at least to be able to post an email as a new topic.
Also contains tests for the email-in feature and minor clean ups
Robin Ward
Sam
riking
Eyal Levin
Régis Hanol
Arpit Jalan
Neil Lalonde
Jeff Atwood
Peter N Lewis
Jorge Manrubia
Benjamin Kampmann
Allen Hancock