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

83 commits

Author SHA1 Message Date
epriestley
5cc3bbf721 Use application PHIDs for application transactions
Summary: Ref T2715. Ref T3578. Load application transactions through application PHID infrastructure.

Test Plan: Viewed feed, saw successful loads of application transaction objects and rendered feed stories.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2715, T3578

Differential Revision: https://secure.phabricator.com/D6617
2013-07-29 12:04:15 -07:00
epriestley
cf9dc5d189 Fix bug when multiple comment forms appear on a single page
Summary:
Ref T3373. The submit listener doesn't properly scope the form it listens to right now, so several forms on the page mean that comments post to one of them more or less at random.

Scope it properly by telling it which object PHID it is associated with.

Test Plan: Made Question comments, saw comments Ajax in on the question itself rather than on an arbitrary answer.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3373

Differential Revision: https://secure.phabricator.com/D6611
2013-07-29 12:04:10 -07:00
epriestley
9383abc6b0 Remove unnecessary empty checks from willFilterPage()
Summary: Fixes T3600. These checks are obsolete after D6512.

Test Plan: Syntax / static / inspection.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3600

Differential Revision: https://secure.phabricator.com/D6563
2013-07-24 15:30:26 -07:00
Bob Trahan
9838251515 Make PhabricatorActionListView logged-out user savvy
Summary:
Fixes T2691. Now, all PhabricatorActionListViews in the codebase setObjectHref to $request->getRequestURI. This value is passed over to PhabricatorActionItems right before they are rendered. If a PhabricatorActionItem is a workflow and there is no user OR the user is logged out, we used this objectURI to construct a log in URI.

Potentially added some undesirable behavior to aggressively setUser (and later setObjectURI) from within the List on Actions... This should be okay-ish unless there was a vision of actions having different user objects associated with them. I think this is a safe assumption.

Test Plan: played around with a mock all logged out (Ref T2652) and it worked!

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T2691

Differential Revision: https://secure.phabricator.com/D6416
2013-07-12 11:39:47 -07:00
Chad Little
f1bf27959f PHUIList, PHUIDocument updates
Summary:
This diff covers a bit of ground.

- PHUIDocumentExample has been added
- PHUIDocument has been extended with new features
- PhabricatorMenuView is now PHUIListView
- PhabricatorMenuItemView is now PHUIItemListView

Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later.

Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 08:41:43 -07:00
epriestley
6dda35897a Use setContentSourceFromRequest() in more places
Summary: I introduced this helper at some point, clean up all the code duplication around content sources.

Test Plan: Grepped; hit edit interfaces for most/all of these.

Reviewers: btrahan, chad, edward

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6030
2013-05-24 10:48:34 -07:00
epriestley
49ef13e876 Add WePay as a one-time payment provider
Summary:
Ref T2787.

I //think// we could also use WePay as a recurring payment provider, but this is somewhat messy (OAuth + requires account) -- basically it's "add a WePay account" instead of "add a credit card".

The WePay checkout workflow is a bit upsell-y but basically reasonable.

I like that their API just has a `request($method, $params)` method instead of 30,000 lines of methods for each request type. I did hit one bug; I'll send a pull for that.

Test Plan: Got as far as the charge callback in testing; the rest isn't implemented for any provider yet.

Reviewers: btrahan, vrana, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5982
2013-05-21 15:34:46 -07:00
epriestley
5263c2d0f3 Show prices in "$... USD" in Phortune
Summary:
Ref T2787. See discussion in D5834.

  - Replace `PhortuneUtil` with `PhortuneCurrency`, which feels a little better and more flexible / future-proof.
  - Add unit tests.
  - Display prices explicitly as "$... USD".

Test Plan: Hit product list, cart, purchase flow, verified displays.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5841
2013-05-06 18:04:45 -07:00
epriestley
b51117790e Add initial cut of PayPal and pay-once-at-checkout providers to Phortune
Summary:
Paypal doesn't let us capture cards in a PCI-free way like Stripe and Balanced do, but we can provide a "pay with paypal" option at checkout. (For subscriptions, we'll have to invoice monthly to retain control over billing, but this doesn't seem wildly unreasonable.) The bitcoin provider MtGox works in a similar way, as do some other providers we might some day want to implement.

This adds:

  - Hooks to providers so they can offer "pay once at checkout" workflows.
  - Hooks so providers can have controllers, for redirect-based third-party workflows.
  - Basic Paypal integration using the "Express Checkout Merchant API", which seems like the best fit for our use case. This only goes as far as shoving the user through the payment flow; we don't actually capture payments yet (paypal has around 35 different APIs, but this one seems to be the only PCI-free one which wouldn't give users an awful experience).

This diff is fairly checkpointey, but Phortune doesn't really bill anything yet anyway. Ref T2787.

Test Plan: Ran through Paypal sandbox workflow; "paid" for stuff.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5834
2013-05-06 11:44:24 -07:00
epriestley
f30f0b30f8 Allow PhortuneTestProvider to add payment methods
Summary: Provide a bare implementation so that you can add PhortuneTestProvider as a payment method. Ref 2787.

Test Plan: Added "cards" through the test provider.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5772
2013-04-25 09:50:08 -07:00
epriestley
7a5f622820 General cleanup for adding payment methods in Phortune
Summary:
This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular:

  - Move more shared form behaviors into the common JS form component.
  - Move more error handling into shared pathways.
  - Make the specialized Stripe / Balanced methods do less work.

This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better.

Ref T2787.

Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 09:49:32 -07:00
epriestley
6efba56448 Implement Balanced Payments as a PhortunePaymentProvider
Summary:
Allows Balanced payment methods to be added. This works essentially the same way as Stripe, except everything is a little bit different.

Slightly more stuff could be shared, but I feel //mostly// good about this. I'll probably do a bit more cleanup next. Some of the error handling is messy, in particular.

Ref T2787.

Test Plan: Added Balanced and Stripe payment methods.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5765
2013-04-25 09:48:04 -07:00
epriestley
a8bc87578e Clean up rendering of credit card form
Summary:
General cleanup and separation into generic vs Stripe blocks of code.

  - There was an old CC form view for Stripe stuff that I never cleaned up; clean that up.
  - Move non-Stripe CC form rendering into a base class (Balanced can reuse it).
  - Move non-Stripe CC form JS into a shareable class.
  - Simplify JS a bit (JX.Workflow can add extra parameters to a request, so we don't need hidden inputs).
  - Genericize CSS.
  - Depend on Stripe JS directly, if they're down we're not going to be able to add cards anyway.

Ref T2787.

Test Plan: Hit all Stripe errors and added new cards.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5758
2013-04-25 09:46:59 -07:00
epriestley
9c43029277 Genericize "Add Payment Method" form
Summary:
Ref T2787. For payment methods that allow you to add a billable method (i.e., a credit card), move all the logic into the provider. In particular:

  - Providers may (Stripe, Balanced) or may not (Paypal, MtGox) allow you to add rebillable payment methods. Providers which don't allow rebillable methods will appear at checkout instead and we'll just invoice you every month if you don't use a rebillable method.
  - Providers which permit creation of rebillable methods handle their own data entry, since this will be per-provider.
  - "Add Payment Method" now prompts you to choose a provider. This is super ugly and barely-usable for the moment. When there's only one choice, we'll auto-select it in the future.

Test Plan: Added new Stripe payment methods; hit all the Stripe errors.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5756
2013-04-25 09:46:32 -07:00
epriestley
f790a2aeec Add basic payment providers to Phortune
Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787.

Test Plan: Ran unit tests.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 09:45:43 -07:00
epriestley
2b5c0c4b3b Add "Carts" to Phortune
Summary: Although I imagine we aren't really going to have an "add to cart" type storefront, putting this in place makes a lot of other workflows simpler. No storage yet, just allows reasonable construction of a "buy stuff" page.

Test Plan: {F41342}

Reviewers: chad, btrahan

Reviewed By: chad

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5745
2013-04-25 09:45:07 -07:00
epriestley
1e6deff8ba Don't use deprected "1" value to cURL CURLOPT_SSL_VERIFYHOST
Summary: Fixes T2962. That task discusses this issue.

Test Plan: Read php-curl documentation to verify this change makes sense. Sent an email with SES.

Reviewers: btrahan, garoevans

Reviewed By: garoevans

CC: aran

Maniphest Tasks: T2962

Differential Revision: https://secure.phabricator.com/D5669
2013-04-12 08:10:22 -07:00
Chad Little
c51f45fbcd Add actions to mobile crumbs
Summary: Adds in the ActionList into Crumbs for mobile on many applications.

Test Plan: Tested each application except probably drydock since not sure how to test that. Also cleaned up Ponder a little.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D5648
2013-04-10 13:08:36 -07:00
epriestley
abdaf90239 Phortune v0.1: products
Summary:
Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative.

Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts.

Generally, this is very basic for the moment.

Test Plan:
{F37594}
{F37595}
{F37596}

Reviewers: chad, btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 09:13:07 -07:00
epriestley
4f3b5f0ea9 Phortune v0.1: add payment methods
Summary:
Hook @btrahan's Stripe form to the rest of Phortune.

  - Users can add payment methods.
  - They are saved to Stripe and associated with PhortunePaymentMethods on our side.
  - Payment methods appear on account overview.

Test Plan:
{F37548}
{F37549}
{F37550}

Reviewers: chad, btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 09:11:42 -07:00
epriestley
960ac3b2a6 Phortune v0
Summary:
Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are:

  - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account.
  - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account.
  - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else.
  - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support.
  - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill.

This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues.

This only implements `Account`, and that only partially.

Test Plan: {F37531}

Reviewers: chad, btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 09:10:34 -07:00
epriestley
a22bea2a74 Apply lint rules to Phabricator
Summary: Mostly applies a new call spacing rule; also a few things that have slipped through via pull requests and such

Test Plan: `find src/ -type f -name '*.php' | xargs -n16 arc lint --output summary --apply-patches`

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D5002
2013-02-19 13:33:10 -08:00
vrana
6bb7a282b1 Convert AphrontFormControl to safe HTML
Summary: Everything here now should properly handle plain strings and safe HTML.

Test Plan: /settings/panel/display/

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T2432

Differential Revision: https://secure.phabricator.com/D4826
2013-02-05 15:52:46 -08:00
epriestley
f9030885c4 Merge branch 'master' into phutil_tag
(Just synchronizing master into the tag branch.)
2013-01-27 06:02:06 -08:00
epriestley
f6622f43e6 Replace all array_combine(x, x) with array_fuse(x) in Phabricator
Summary: Fixes various array_combine() warnings for PHP < 5.4

Test Plan: lint/unit/grep

Reviewers: btrahan, vrana, chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D4660
2013-01-25 17:06:55 -08:00
epriestley
3093d1663d Add javelin_tag(), convert easy callsites
Summary:
  - Implements `javelin_tag()`, which is `javelin_render_tag()` on top of `phutil_tag()` instead of `phutil_render_tag()`.
  - Manually converts all or almost all of the trivial callsites.

Test Plan:
  - Site does not seem any more broken than before.

Reviewers: vrana

Reviewed By: vrana

CC: aran

Differential Revision: https://secure.phabricator.com/D4639
2013-01-25 12:57:17 -08:00
vrana
f8dbfdd59d Convert phutil_render_tag(X, Y) to phutil_tag
Summary:
Created with spatch:

  lang=diff
  - phutil_render_tag
  + phutil_tag
    (X, Y)

(and null manually)

Test Plan: Loaded homepage

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D4500
2013-01-24 19:08:54 -08:00
vrana
ef214e94ce Move setUser() to AphrontView
Summary: This is used in every other view.

Test Plan: Browsed around.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D4248
2012-12-20 14:49:52 -08:00
vrana
ef85f49adc Delete license headers from files
Summary:
This commit doesn't change license of any file. It just makes the license implicit (inherited from LICENSE file in the root directory).

We are removing the headers for these reasons:

- It wastes space in editors, less code is visible in editor upon opening a file.
- It brings noise to diff of the first change of any file every year.
- It confuses Git file copy detection when creating small files.
- We don't have an explicit license header in other files (JS, CSS, images, documentation).
- Using license header in every file is not obligatory: http://www.apache.org/dev/apply-license.html#new.

This change is approved by Alma Chao (Lead Open Source and IP Counsel at Facebook).

Test Plan: Verified that the license survived only in LICENSE file and that it didn't modify externals.

Reviewers: epriestley, davidrecordon

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T2035

Differential Revision: https://secure.phabricator.com/D3886
2012-11-05 11:16:51 -08:00
vrana
0acb7734cd Use pht()
Summary:
This is the first step in Phabricator internationalization.
It adds a translation selector and calls it at startup.
Installations can add custom selectors to override some texts.
We can add official translations in future.

Next step is to allow user to choose his translation which will override the global one.

This is currently used only for English plurals.

Test Plan: Displayed a diff with unit test error, verified that it says 'Detail' or 'Details' and not 'Detail(s)'.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T1139

Differential Revision: https://secure.phabricator.com/D2753
2012-06-14 16:25:20 -07:00
vrana
6cc196a2e5 Move files in Phabricator one level up
Summary:
- `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`.
- [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php`
- Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`.

NOTE: `arc diff` timed out so I'm pushing it without review.

Test Plan:
/D1234
Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general.

Auditors: epriestley

Maniphest Tasks: T1103
2012-06-01 12:32:44 -07:00
epriestley
09c8af4de0 Upgrade phabricator to libphutil v2
Summary: Mechanical changes from D2588. No "Class.php" moves yet.

Test Plan: See D2588.

Reviewers: vrana, btrahan, jungejason

Reviewed By: vrana

CC: aran

Maniphest Tasks: T1103

Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 14:26:29 -07:00
Bob Trahan
cc586b0afa For discussion -- Stripe integration
Summary:
various stripe stuff, including

- external stripe library
- payment form
- test controller to play with payment form, sample business logic

My main questions / discussion topics are...

- is the stripe PHP library too big? (ie should I write something more simple just for phabricator?)
-- if its cool, what is the best way to include the client? (ie should I make it a submodule rather than the flat copy here?)
- is the JS I wrote (too) ridiculous?
-- particularly unhappy with the error message stuff being in JS *but* it seemed the best choice given the most juicy error messages come from the stripe JS such that the overall code complexity is lowest this way.
- how should the stripe JS be included?
-- flat copy like I did here?
-- some sort of external?
-- can we just load it off stripe servers at request time? (I like that from the "if stripe is down, stripe is down" perspective)
- wasn't sure if the date control was too silly and should just be baked into the form?
-- for some reason I feel like its good to be prepared to walk away from Stripe / switch providers here, though I think this is on the wrong side of pragmatic

Test Plan: - played around with sample client form

Reviewers: epriestley

Reviewed By: epriestley

CC: aran

Differential Revision: https://secure.phabricator.com/D2096
2012-04-04 16:09:29 -07:00