1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-24 06:20:56 +01:00
Commit graph

3 commits

Author SHA1 Message Date
epriestley
b16db61a87 Allow "send me an email" in personal rules to punch through settings
Summary:
Fixes T7731. When a user writes a "Send me an email" rule, always try send them an email, even if their notification settings would normally downgrade it to a notification.

In particular, this is stronger than these downgrades:

  - Downgrades due to "self actions";
  - downgrades due to "mail tags".

Test Plan:
  - Wrote various Herald rules with "Send me an email" rules.
  - Used `bin/mail list-outbound` / `show-outbound` to vet generated mail.
  - Mail reacted properly to a variety of conditions (disabled accounts, settings, "send me an email" rule, forced delivery).

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7731

Differential Revision: https://secure.phabricator.com/D12300
2015-04-06 10:01:32 -07:00
epriestley
c0e26c65e0 Make mail delivery reasons code-based; include positive and negative reasons
Summary:
Ref T7731. Looking forward to T5791, I eventually anticipate writing an interface which looks like a webmail UI where users can review mail they've been sent and understand why they recieved (or did not receive) the mail. Roughly like `bin/mail list-outbound` / `bin/mail show-outbound` work today, but policy-aware (so you can only see messages where delivery was attempted to you).

We currently record a list of "reasons" why a mail is undeliverable, but this list is string-based (so it can not be translated once we start persisting it) and has only negative reasons (so it can not be used to fully understand reasons for delivery or nondelivery).

Make it code-based (so it can be translated) and allow both positive and negative reasons to be listed (so positive reasons can be understood).

Test Plan: Used `bin/mail show-outbound` to review mail delivery reasons, including the positive reason we currently have (forced delivery of authentication mail).

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7731

Differential Revision: https://secure.phabricator.com/D12297
2015-04-06 10:01:11 -07:00
epriestley
293a475e39 Show why recipients were excluded from mail
Summary:
Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities:

  # We just let you see everything from the web UI.
    - This makes debugging easier.
    - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link).
  # We let you see everything, but only for messages you were a recipient of or author of.
    - This makes it much more difficult to debug issues with mailing lists.
      - But maybe we could just say mailing list recipients are "public", or define some other ruleset.
    - Generally this gets privacy and ease of use right.
  # We could move the whole thing to the CLI.
    - Makes the UI/UX way worse.
  # We could strike an awkward balance between concerns, as we do now.
    - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great.

I'm inclined to probably go with (2) and figure something out for mailing lists?

Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else.

Test Plan:
{F49546}

  - Looked at a bunch of mail.
  - Sent mail from different apps.
  - Checked that recipients seem correct.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3306

Differential Revision: https://secure.phabricator.com/D6413
2013-07-10 15:17:38 -07:00