2011-03-03 03:58:21 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorPHIDConstants {
|
|
|
|
|
|
|
|
const PHID_TYPE_USER = 'USER';
|
|
|
|
const PHID_TYPE_MLST = 'MLST';
|
|
|
|
const PHID_TYPE_DREV = 'DREV';
|
|
|
|
const PHID_TYPE_TASK = 'TASK';
|
|
|
|
const PHID_TYPE_FILE = 'FILE';
|
|
|
|
const PHID_TYPE_PROJ = 'PROJ';
|
|
|
|
const PHID_TYPE_UNKNOWN = '????';
|
|
|
|
const PHID_TYPE_MAGIC = '!!!!';
|
2011-03-07 07:29:22 +01:00
|
|
|
const PHID_TYPE_REPO = 'REPO';
|
|
|
|
const PHID_TYPE_CMIT = 'CMIT';
|
2011-04-04 07:23:31 +02:00
|
|
|
const PHID_TYPE_OPKG = 'OPKG';
|
2011-06-10 08:53:53 +02:00
|
|
|
const PHID_TYPE_PSTE = 'PSTE';
|
2011-07-05 17:35:18 +02:00
|
|
|
const PHID_TYPE_STRY = 'STRY';
|
2011-07-08 20:13:11 +02:00
|
|
|
const PHID_TYPE_POLL = 'POLL';
|
2011-07-11 17:54:22 +02:00
|
|
|
const PHID_TYPE_WIKI = 'WIKI';
|
2011-07-17 03:44:48 +02:00
|
|
|
const PHID_TYPE_APRJ = 'APRJ';
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
const PHID_TYPE_ACMT = 'ACMT';
|
|
|
|
const PHID_TYPE_DRYR = 'DRYR';
|
|
|
|
const PHID_TYPE_DRYL = 'DRYL';
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
const PHID_TYPE_OASC = 'OASC';
|
|
|
|
const PHID_TYPE_OASA = 'OASA';
|
2012-04-12 22:09:04 +02:00
|
|
|
const PHID_TYPE_POST = 'POST';
|
2012-07-09 19:39:14 +02:00
|
|
|
const PHID_TYPE_TOBJ = 'TOBJ';
|
2012-07-19 18:03:10 +02:00
|
|
|
const PHID_TYPE_BLOG = 'BLOG';
|
2012-08-10 19:44:04 +02:00
|
|
|
const PHID_TYPE_QUES = 'QUES';
|
|
|
|
const PHID_TYPE_ANSW = 'ANSW';
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
const PHID_TYPE_MOCK = 'MOCK';
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
const PHID_TYPE_MCRO = 'MCRO';
|
2012-12-28 00:20:09 +01:00
|
|
|
const PHID_TYPE_CONF = 'CONF';
|
2013-01-25 02:23:05 +01:00
|
|
|
const PHID_TYPE_CONP = 'CONP';
|
2013-03-21 02:01:52 +01:00
|
|
|
const PHID_TYPE_PVAR = 'PVAR';
|
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 17:10:34 +01:00
|
|
|
const PHID_TYPE_ACNT = 'ACNT';
|
|
|
|
const PHID_TYPE_PDCT = 'PDCT';
|
|
|
|
const PHID_TYPE_PRCH = 'PRCH';
|
|
|
|
const PHID_TYPE_PAYM = 'PAYM';
|
|
|
|
const PHID_TYPE_CHRG = 'CHRG';
|
2013-04-25 18:45:07 +02:00
|
|
|
const PHID_TYPE_CART = 'CART';
|
2013-05-23 15:47:54 +02:00
|
|
|
const PHID_TYPE_CDWN = 'CDWN';
|
2013-07-03 20:15:45 +02:00
|
|
|
const PHID_TYPE_LEGD = 'LEGD';
|
|
|
|
const PHID_TYPE_LEGB = 'LEGB';
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
|
2012-12-11 22:59:20 +01:00
|
|
|
const PHID_TYPE_XACT = 'XACT';
|
|
|
|
const PHID_TYPE_XCMT = 'XCMT';
|
2013-04-19 20:40:13 +02:00
|
|
|
const PHID_TYPE_XUSR = 'XUSR';
|
2012-12-11 22:59:20 +01:00
|
|
|
|
2013-05-20 19:18:26 +02:00
|
|
|
const PHID_TYPE_BOOK = 'BOOK';
|
|
|
|
const PHID_TYPE_ATOM = 'ATOM';
|
2013-06-17 19:48:41 +02:00
|
|
|
const PHID_TYPE_AUTH = 'AUTH';
|
2013-06-25 00:54:36 +02:00
|
|
|
const PHID_TYPE_XOBJ = 'XOBJ';
|
2013-05-20 19:18:26 +02:00
|
|
|
|
Provide "builtin" files and use them to fix Pholio when files are deleted
Summary:
Fixes T3132. Currently, if a user deletes a file which is present in a mock, that mock throws an exception when loading. If the file is also the cover photo, the mock list throws an exception as well.
In other applications, we can sometimes deal with this (a sub-object vanishing) by implicitly hiding the parent object (for example, we can just vanish feed stories about objects which no longer exist). We can also sometimes deal with it by preventing sub-objects from being directly deleted.
However, neither approach is reasonable in this case.
If we vanish the whole mock, we'll lose all the comments and it will generally be weird. Vanishing a mock is a big deal compared to vanishing a feed story. We'll also need to load more data on the list view to prevent showing a mock on the list view and then realizing we need to vanish it on the detail view (because all of its images have been deleted).
We permit total deletion of files to allow users to recover from accidentally uploading sensitive files (which has happened a few times), and I'm hesitant to remove this capability because I think it serves a real need, so we can't prevent sub-objects from being deleted.
So we're left in a relatively unique situation. To solve this, I've added a "builtin" mechanism, which allows us to expose some resource we ship with as a PhabricatorFile. Then we just swap it out in place of the original file and proceed forward normally, as though nothing happened. The user sees a placeholder image instead of the original, but everything else works reasonably and this seems like a fairly acceptable outcome.
I believe we can use this mechanism to simplify some other code too, like default profile pictures.
Test Plan: Deleted a Pholio mock cover image's file. Implemented change, saw functional Pholio again with beautiful life-affirming "?" art replacing soul-shattering exception.
Reviewers: btrahan, chad
Reviewed By: chad
CC: aran
Maniphest Tasks: T3132
Differential Revision: https://secure.phabricator.com/D5870
2013-05-09 03:12:52 +02:00
|
|
|
const PHID_TYPE_VOID = 'VOID';
|
|
|
|
const PHID_VOID = 'PHID-VOID-00000000000000000000';
|
|
|
|
|
2011-03-03 03:58:21 +01:00
|
|
|
}
|