2011-03-03 03:58:21 +01:00
|
|
|
<?php
|
|
|
|
|
|
2015-06-15 10:02:26 +02:00
|
|
|
final class PhabricatorPHIDConstants extends Phobject {
|
2011-03-03 03:58:21 +01:00
|
|
|
|
|
|
|
|
const PHID_TYPE_UNKNOWN = '????';
|
|
|
|
|
const PHID_TYPE_MAGIC = '!!!!';
|
2011-07-05 17:35:18 +02:00
|
|
|
const PHID_TYPE_STRY = 'STRY';
|
2012-07-09 19:39:14 +02:00
|
|
|
const PHID_TYPE_TOBJ = 'TOBJ';
|
2013-07-03 20:15:45 +02:00
|
|
|
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_XCMT = 'XCMT';
|
|
|
|
|
|
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
|
|
|
}
|
