1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-14 19:02:41 +01:00
Commit graph

37 commits

Author SHA1 Message Date
Chad Little
bf44210dc8 Reduce application search engine results list for Dashboards
Summary: Ref T10390. Simplifies dropdown by rolling out canUseInPanel in useless panels

Test Plan: Add a query panel, see less options.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T10390

Differential Revision: https://secure.phabricator.com/D17341
2017-02-22 12:42:43 -08:00
epriestley
4997b6bd02 Never send normal mail to unverified addresses
Summary:
Ref T12237. This tightens our delivery rules, which previously sent normal mail to unverified addresses:

  - We sent general mail to unverified addresses so that you wouldn't miss anything between the time you sign up (or have an account created) and the time you verify your address. This was imagined as a slight convenience for users.
  - We sent automatic reply mail to unverified addresses if they sent mail to us first, saying "we don't recognize that address". This was imagined as a convenience for users who accidentally send mail "From" the wrong address (personal vs work, for example).

I think both behaviors are probably a little better for users on the balance, but not having mail providers randomly shut us off without warning is better for me, personally -- so stop doing this stuff.

This creates a problem which we likely need to solve before the release is cut:

  - On installs which do not require mail verification, mail to you will now mostly-silently be dropped if you never bothered to verify your address.

I'd like to solve this by adding some kind of per-user alert that says "We recently tried to send you some mail but you haven't verified your address.", and giving them links to verify the address and review the mail. I'll pursue this after restoring mail service to `secure.phabricator.com`.

Test Plan:
  - Added a unit test.
  - Unverified my address, sent mail, saw it get dropped.
  - Reverified my address, sent mail, saw it go through.
  - Verified that important mail (password reset, invite, confirm-this-address) either uses "Force Delivery" (skips this check) or "Raw To Addresses" (also skips this check).
    - Verified that Phacility instance stuff is also covered: it uses the same invite flow.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T12237

Differential Revision: https://secure.phabricator.com/D17329
2017-02-09 10:20:57 -08:00
epriestley
2b344b2bb5 Make caches misses throw by default intead of inline-generating
Summary:
Ref T4103. Ref T10078. Currently, when a user misses a cache we just build it for them.

This is the behavior we want for the the viewer (so we don't have to build every cache up front if we don't actually need them), but not the right behavior for other users (since it allows performance problems to go undetected).

Make inline cache generation strict by default, then make sure all the things that rely on cache data request the correct data (well, all of the things identified by unit tests, at least: there might be some more stuff I haven't hit yet).

This fixes test failures in D16040, and backports a piece of that change.

Test Plan: Identified and then fixed failures with `arc unit --everything`.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4103, T10078

Differential Revision: https://secure.phabricator.com/D16042
2016-06-05 08:51:54 -07:00
epriestley
547abfe873 Make packages mailable and subscribable
Summary:
Ref T10939. Fixes T7834.

  - Make packages into mailable objects, like projects and users.
  - Packages resolve recipients by resolving project and user owners into recipients.

Test Plan:
  - Added a comment to a revision with a package subscriber.
  - Used `bin/mail show-outbound` to see that owners got mail.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7834, T10939

Differential Revision: https://secure.phabricator.com/D15912
2016-05-13 17:18:57 -07:00
epriestley
8463ad2659 Replace subscribe/unsubscribe for projects with explicit mail setting
Summary:
Ref T10054. Ref T6113. Users can currently subscribe to projects, which causes them to receive:

  # mail about project membership changes, description changes, etc; and
  # mail to the project, e.g. when the project is added as a subscriber on a task, or a reviewer on a revision.

Almost no one cares about (1), and after D15061 you can use Herald to get this stuff if you really want it. (It will get progressively more annoying in the future with external membership sources causing automated project membership updates.)

A lot of users are confused about (2) and how it relates to membership, watching, etc, and most users who want (2) don't want (1).

Instead, add an explicit option for this and explain what it does.

This is fairly verbose but I've hidden it on the member/watch screen, which is now the "explain how projects work" screen, I guess.

Test Plan:
{F1064929}

{F1064930}

{F1064931}

  - Disabled/enabled mail for a project.
  - Sent mail to a project with mail disabled, verified I didn't get a copy.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6113, T10054

Differential Revision: https://secure.phabricator.com/D15065
2016-01-19 19:39:02 -08:00
epriestley
7a1bbe6634 Add basic support for Herald outbound rules
Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in.

Test Plan:
{F715209}

{F715211}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 10:54:33 -07:00
epriestley
3b987a93ce Consolidate outbound mail status in a new class
Summary: Ref T5791. This collects outbound mail status in one place and makes the list view a little spiffier.

Test Plan: Looked at list and detail views. Grepped for changed classes/constants.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13884
2015-08-14 04:31:42 -07:00
epriestley
8c06d89070 Flesh out web UI for mail a bit to prepare for Herald outbound rules
Summary:
Ref T9141. Ref T5791. Ref T7013. Major changes here is:

  - Currently, we don't store the headers we actually sent, or the reasons we actually did or did not deliver a mail.
    - Start storing these (as `headers.sent` and `actors.sent`).
    - Show them in the web UI.
    - Show them in `bin/mail show-outbound` (previously, we sort of re-computed them in a hacky way).
    - Take them into account in `bin/mail volume`.

Then some minor changes:

  - Show mail bodies.
  - Show more mail information.
  - Start renaming "MetaMTA" to "Mail", at least in the web UI.

Test Plan:
{F707501}
{F707502}
{F707503}
{F707504}
{F707505}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5791, T7013, T9141

Differential Revision: https://secure.phabricator.com/D13878
2015-08-12 12:27:31 -07:00
epriestley
50e084dcda Add a rough bin/mail volume command for showing mail volume
Summary: Ref T7013. This might help us understand the problem better.

Test Plan:
```
$ ./bin/mail volume
+==============+============+
| User         | Unfiltered |
+==============+============+
| admin        | 136        |
| dog          | 31         |
| epriestley   | 24         |
| ducksey      | 18         |
| saurus       | 8          |
| example-list | 7          |
| squeakybirdo | 3          |
| nnn          | 3          |
| facebooker   | 2          |
+==============+============+

Mail sent in the last 30 days.
"Unfiltered" is raw volume before preferences were applied.
```

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7013

Differential Revision: https://secure.phabricator.com/D13813
2015-08-06 11:32:17 -07:00
Joshua Spence
acb1eb81cc Move some PhabricatorSearchField subclasses
Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application.

Test Plan: N/A.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 22:52:05 +10:00
epriestley
14a395ed8e Merge branch 'master' into redesign-2015 2015-06-25 10:06:50 -07:00
Bob Trahan
c1dca8238f MetaMTA - make the new mail app UI a little less bad
Summary: Ref T5791. Makes the result page a little less ugly and adds the time created. Makes the detail page include more useful information about the message.

Test Plan: viewed results page and detail page and they looked better

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13410
2015-06-23 18:30:05 -07:00
epriestley
729606ba93 Update BulkJob and MetaMTA search engines for redesign-2015 2015-06-23 13:39:27 -07:00
Bob Trahan
7e0249d68c MetaMTA - more progress to mail app
Summary:
Ref T5791. This diff adds a "sensitive" flag to `PhabricatorMetaMTAMail`, defaults it to true in the constructor, and then sets it to false in teh application transaction editor. Assumption here is that sensitive emails are basically all the emails that don't flow through the application transaction editor.

This diff also gets a basic "mail view" page up and going.

This diff also fixes a bug writing recipient edges; the actor was being included.

This bug also fixes a querying bug; we shouldn't do the automagic join of $viewer is recipient or $viewer is actor if folks are querying for recipients or actors already. The bug manifested itself as having the "inbox" be inbox + outbox.

Test Plan: viewd list of messages. viewed message detail.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13406
2015-06-23 12:55:44 -07:00
Bob Trahan
dfef8e2f07 MetaMTA - more progress towards a mail application
Summary:
Ref T5791. This diff does a few things...

 - Adds code to write recipients to edges on save
 - Makes Query performance for policy filtering okay-ish
 - Adds a Search Engine for PhabricatorMetaMTAMail
 - Adds "working" List Controller
   - Inbox and Outbox both work
 - Adds stub View Controller

Test Plan: ran `./bin/storage upgrade` and saw my inbox and outbox start getting data. played with application and saw new entries in inbox and outbox

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13397
2015-06-23 11:37:14 -07:00
Bob Trahan
ea5462fb60 MetaMTA - lay some ground work for having an application
Summary:
Ref T5791. This does a few bits there. Namely:

 - Adds PHID column to PhabricatorMetaMTAMail
   - Implements a PhabricatorMetaMTAMailPHIDType
   - Script to backpopulate them.
 - Makes PhabricatorMetaMTAMail implement PolicyInterface.
   - View policy is NOONE and the author and recipients have automatic view capabilities
   - No edit capability.
 - Adds a PhabricatorMetaMTAMailQuery for PhabricatorMetaMTAMail.

Test Plan: ran `./bin/storage upgrade` successfully. commented on a maniphest task and verifed the metamta mail object in the database was created successfully with a shiny new phid

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13394
2015-06-22 13:46:26 -07:00
Joshua Spence
b6d745b666 Extend from Phobject
Summary: All classes should extend from some other class. See D13275 for some explanation.

Test Plan: `arc unit`

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 18:02:27 +10:00
epriestley
0bc8382dfd Support Spaces in ApplicationEmail
Summary:
Ref T8498. Allow ApplicationEmail addresses to be put into spaces:

  - You can only see and send to addresses in Spaces you have access to.
  - Objects are created into the same space their address is associated with.

Test Plan:
  - Used `bin/mail receive-test` to send mail to various `xyz-bugs@...` addresses.
  - Saw objects created in the proper space.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8498

Differential Revision: https://secure.phabricator.com/D13247
2015-06-11 10:23:56 -07:00
epriestley
6d6211d441 Use ApplicationTransactions in ApplicationEmail
Summary:
Ref T8498. I want to add Spaces to these, and the logic for getting Spaces right is a bit tricky, so swap these to ApplicationTransactions.

One new piece of tech: made it easier for Editors to raise DuplicateKeyException as a normal ValidationException, so callers don't have to handle this case specially.

One behavioral change: we no longer require these addresses to be at the `auth.email-domains` domains -- I think this wasn't quite right in the general case. It's OK to require users to have `@mycompany.com` addresses but add `@phabricator.mycompany-infrastructure.com` addresses here if you want.

Test Plan:
  - Tried to create a duplicate email.
  - Tried to create an empty email.
  - Tried to create an invalid email.
  - Created a new email.
  - Deleted an email.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8498

Differential Revision: https://secure.phabricator.com/D13246
2015-06-11 10:15:49 -07:00
epriestley
ba6cb62b49 Remove mailing lists application
Summary: Ref T8387. This is now completely obsoleted by mailing list users.

Test Plan: Grepped for `mailinglist` and related symbols.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: eadler, epriestley

Maniphest Tasks: T8387

Differential Revision: https://secure.phabricator.com/D13129
2015-06-03 18:42:36 -07:00
epriestley
f5580c7a08 Make buildWhereClause() a method of AphrontCursorPagedPolicyAwareQuery
Summary:
Ref T4100. Ref T5595.

To support a unified "Projects:" query across all applications, a future diff is going to add a set of "Edge Logic" capabilities to `PolicyAwareQuery` which write the required SELECT, JOIN, WHERE, HAVING and GROUP clauses for you.

With the addition of "Edge Logic", we'll have three systems which may need to build components of query claues: ordering/paging, customfields/applicationsearch, and edge logic.

For most clauses, queries don't currently call into the parent explicitly to get default components. I want to move more query construction logic up the class tree so it can be shared.

For most methods, this isn't a problem, but many subclasses define a `buildWhereClause()`. Make all such definitions protected and consistent.

This causes no behavioral changes.

Test Plan: Ran `arc unit --everything`, which does a pretty through job of verifying this statically.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: yelirekim, hach-que, epriestley

Maniphest Tasks: T4100, T5595

Differential Revision: https://secure.phabricator.com/D12453
2015-04-20 10:06:09 -07:00
epriestley
4fba6e7730 Remove trivial implementations of getPagingColumn()
Summary:
Ref T7803. Some Query subclasses implement getPagingColumn() in a trivial way, usually to provide a table alias.

Formalize the concept of a primary table alias, and remove obsoleted getPagingColumn() implementations.

Test Plan: Issued affected queries.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7803

Differential Revision: https://secure.phabricator.com/D12356
2015-04-13 11:58:19 -07:00
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
86404a1a18 Fix handling of notifications with project members
Summary: Fixes T7377. We don't expand projects into members when sending notifications right now. Instead, expand them.

Test Plan:
  - Added a project as a reviewer to a revision, made a comment, saw project members receive a read notification + email (with appropriate preferences).
  - There's meaningful test coverage on the core mail stuff.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7377

Differential Revision: https://secure.phabricator.com/D12142
2015-03-24 12:47:38 -07:00
Bob Trahan
fe0ca0abf2 Application Emails - add datasource so we can have a typeahead
Summary: Ref T5039. This will be necessary for Herald integration so users can make rules like "if app email is one of x, y, or z add projects foo, bar, and metallica." I think its best to do an actual typeahead here -- users select full email addresses -- rather than support prefix, suffix, etc stuff on the email address. I think the latter approach would yield lots of confusion, as well as prevent us from (more) easily providing diagnostic tools about what happened when and why.

Test Plan: hacked a maniphest tokenizer to use this new datasource and it worked

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T5039

Differential Revision: https://secure.phabricator.com/D11546
2015-01-28 14:35:42 -08:00
Bob Trahan
53b06408f4 MetaMTA - add (basic) application emails and deploy to Maniphest
Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works.

Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T3404, T5952

Differential Revision: https://secure.phabricator.com/D11418
2015-01-19 16:07:26 -08:00
Joshua Spence
97a8700e45 Rename PHIDType classes
Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives.

Test Plan: Ran unit tests.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: epriestley, Korvin, hach-que

Maniphest Tasks: T5655

Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 08:05:46 +10:00
lkassianik
dfcccd4cb8 Add config to require real name, respect config when creating new users, drop real name from full name if not provided.
Summary: Fixes T4728, first pass, Make real name optional on user accounts

Test Plan: Default real name config should be false (not required). Create new user, real name should not be required. Toggle config, real name should be required. Users with no real name should be always listed by their usernames.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T4728

Differential Revision: https://secure.phabricator.com/D9027
2014-05-12 09:51:41 -07:00
epriestley
b1243e549c Allow unsubscription from projects
Summary:
Fixes T4379. Several changes:

  - Migrate all project members into subscribers.
  - When members are added or removed, subscribe or unsubscribe them.
  - Show sub/unsub in the UI.
  - Determine mailable membership of projects by querying subscribers.

Test Plan:
  - As `duck`, joined a project.
  - Added the project as a reviewer to a revision.
  - Commented on the revision.
  - Observed `duck` receive mail.
  - Unsubscribed as `duck`.
  - Observed no mail.
  - Resubscribed as `duck`.
  - Mail again.
  - Joined/left project, checked sub/unsub status.
  - Ran migration, looked at database.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, asherkin

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8189
2014-02-11 07:45:56 -08:00
epriestley
eca7d3feda Expand aggregate email recipients prior to multiplexing
Summary:
Ref T4361. Before we figure out which To/CC are addressable, try to expand To/CC. Specifically, the supported expansion right now is project PHIDs expanding to all their members.

Because of the way multiplexing works, we have to do this in two places: explicitly in `multiplexMail()`, and when sending mail that wasn't multiplexed. This is messy; eventually we can get rid of it (after ApplicationTransactions are everywhere).

This has some rough edges, but should basically give us what we need to make stuff like projects mailable. Particularly, it deals with most issues in D7436:

  - I got around the resolution/multiplexing issue by resolving aggregate mailables separately from mailable actors.
  - We get to keep the Project PHID as a To/CC/Reviewer/Whatever until the last second.
  - Users won't get two emails for being a CC and also a member of a CC'd project.
  - We can degrade to the list stuff this way if we want, by having the project aggregate yield a single list PHID.

Test Plan: Added a comment to a revision with a project reviewer, got mail to all the project's members.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4361

Differential Revision: https://secure.phabricator.com/D8117
2014-02-01 14:35:55 -08:00
epriestley
7f11e8d740 Improve handling of email verification and "activated" accounts
Summary:
Small step forward which improves existing stuff or lays groudwork for future stuff:

  - Currently, to check for email verification, we have to single-query the email address on every page. Instead, denoramlize it into the user object.
    - Migrate all the existing users.
    - When the user verifies an email, mark them as `isEmailVerified` if the email is their primary email.
    - Just make the checks look at the `isEmailVerified` field.
  - Add a new check, `isUserActivated()`, to cover email-verified plus disabled. Currently, a non-verified-but-not-disabled user could theoretically use Conduit over SSH, if anyone deployed it. Tighten that up.
  - Add an `isApproved` flag, which is always true for now. In a future diff, I want to add a default-on admin approval queue for new accounts, to prevent configuration mistakes. The way it will work is:
    - When the queue is enabled, registering users are created with `isApproved = false`.
    - Admins are sent an email, "[Phabricator] New User Approval (alincoln)", telling them that a new user is waiting for approval.
    - They go to the web UI and approve the user.
    - Manually-created accounts are auto-approved.
    - The email will have instructions for disabling the queue.

I think this queue will be helpful for new installs and give them peace of mind, and when you go to disable it we have a better opportunity to warn you about exactly what that means.

Generally, I want to improve the default safety of registration, since if you just blindly coast through the path of least resistance right now your install ends up pretty open, and realistically few installs are on VPNs.

Test Plan:
  - Ran migration, verified `isEmailVerified` populated correctly.
  - Created a new user, checked DB for verified (not verified).
  - Verified, checked DB (now verified).
  - Used Conduit, People, Diffusion.

Reviewers: btrahan

Reviewed By: btrahan

CC: chad, aran

Differential Revision: https://secure.phabricator.com/D7572
2013-11-12 14:37:04 -08:00
Bob Trahan
1cb0db8755 Move PhabricatorUser to new phid stuff
Summary: Ref T2715. Had to start loading status information in the query class. Debated trying to clean up some of the attach / load stuff but decided to just add status under the new paradigm for now.

Test Plan: phid.query  also made a status and checked that out. also played in conpherence.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T2715

Differential Revision: https://secure.phabricator.com/D6585
2013-07-26 14:05:19 -07:00
epriestley
db3a0c90bb Use Application PHIDs for XUSR
Summary: Ref T2715. XUSR -> apps

Test Plan: `phid.query`

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2715

Differential Revision: https://secure.phabricator.com/D6558
2013-07-24 14:12:39 -07:00
epriestley
c5a06a624a Use application PHIDs for mailing lists
Summary:
Ref T2715. Ref T603. Ref T2625.

  - Implement policies.
  - Use policy queries.
  - Use ApplicationSearch.
  - Use application PHIDs.

Test Plan: Browsed things with lists CC'd; edited lists; created a list, used `phid.query` to query handles.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603, T2625, T2715

Differential Revision: https://secure.phabricator.com/D6513
2013-07-22 12:17:33 -07:00
epriestley
544a84ebb9 Move outbound mail lists to CLI and enhance details
Summary: Finish off moving all this stuff to the CLI. Ref T3306.

Test Plan:
  PROPERTIES
  ID: 6483
  Status: void
  Retry Count: 0
  Next Retry: 1373494457
  Related PHID: PHID-DREV-5bnb33yeuhuaulyc3exg
  Message: Message has no valid recipients: all To/Cc are disabled, invalid, or configured not to receive this mail.

  PARAMETERS
  from: PHID-USER-lqiz3yd7wmk64ejugvov
  is-html:
  parent-message-id: null
  thread-id: differential-rev-PHID-DREV-5bnb33yeuhuaulyc3exg-req
  is-first-message: null
  is-bulk: 1
  mailtags: ["differential-comment"]
  cc: ["PHID-USER-cluwcdowc35gmperlkbi"]
  subject: D22: quack quack
  subject-prefix: [Differential]
  vary-subject-prefix: [Commented On]
  worker-task: 936546

  HEADERS
  Thread-Topic: D22: quack quack
  X-Herald-Rules: none
  X-Differential-Author: <PHID-USER-lqiz3yd7wmk64ejugvov>
  X-Differential-CC: <PHID-USER-ly3pvrtdkw7lbgs72jvr>
  X-Differential-CC: <PHID-USER-cluwcdowc35gmperlkbi>
  X-Differential-CC: <PHID-MLST-wkxaantg3q6pgdkty5pt>
  X-Differential-CC: <PHID-USER-aeabc4ipqbifny3rw4ok>
  X-Differential-CC: <PHID-USER-zqxtb3oi4pouwxnxlv3f>
  X-Differential-CC: <PHID-USER-cknqtm2dzw7twnwyiaye>
  X-Differential-CCs: <PHID-USER-ly3pvrtdkw7lbgs72jvr>, <PHID-USER-cluwcdowc35gmperlkbi>, <PHID-MLST-wkxaantg3q6pgdkty5pt>, <PHID-USER-aeabc4ipqbifny3rw4ok>, <PHID-USER-zqxtb3oi4pouwxnxlv3f>, <PHID-USER-cknqtm2dzw7twnwyiaye>
  X-Differential-Explicit-CC: <PHID-USER-ly3pvrtdkw7lbgs72jvr>
  X-Differential-Explicit-CC: <PHID-USER-cluwcdowc35gmperlkbi>
  X-Differential-Explicit-CC: <PHID-MLST-wkxaantg3q6pgdkty5pt>
  X-Differential-Explicit-CC: <PHID-USER-aeabc4ipqbifny3rw4ok>
  X-Differential-Explicit-CC: <PHID-USER-zqxtb3oi4pouwxnxlv3f>
  X-Differential-Explicit-CC: <PHID-USER-cknqtm2dzw7twnwyiaye>
  X-Differential-Explicit-CCs: <PHID-USER-ly3pvrtdkw7lbgs72jvr>, <PHID-USER-cluwcdowc35gmperlkbi>, <PHID-MLST-wkxaantg3q6pgdkty5pt>, <PHID-USER-aeabc4ipqbifny3rw4ok>, <PHID-USER-zqxtb3oi4pouwxnxlv3f>, <PHID-USER-cknqtm2dzw7twnwyiaye>
  X-Phabricator-To: <PHID-USER-lqiz3yd7wmk64ejugvov>
  X-Phabricator-Cc: <PHID-USER-ly3pvrtdkw7lbgs72jvr>
  X-Phabricator-Cc: <PHID-USER-cluwcdowc35gmperlkbi>
  X-Phabricator-Cc: <PHID-MLST-wkxaantg3q6pgdkty5pt>
  X-Phabricator-Cc: <PHID-USER-aeabc4ipqbifny3rw4ok>
  X-Phabricator-Cc: <PHID-USER-zqxtb3oi4pouwxnxlv3f>
  X-Phabricator-Cc: <PHID-USER-cknqtm2dzw7twnwyiaye>

  RECIPIENTS
  ! dog (dog)
      - This user is disabled; disabled users do not receive mail.

  BODY
  epriestley has commented on the revision "quack quack".

    zxcbzxcb

  REVISION DETAIL
    http://local.aphront.com:8080/D22

  To: epriestley
  Cc: Unknown User, dog, list, duck, epriestley992, asana

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3306

Differential Revision: https://secure.phabricator.com/D6423
2013-07-10 18:52:22 -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