The edge editing should block on edge support in ApplicationTransaction (T2104).

Filtering stuff should probably block on T2625.

I was about to implement this as a test ground for edge transactions, but maybe it needs a little more thought -- in particular, maybe we should move toward all project-linked items having at most one "primary" project (which they inherit policies from) and then zero or more auxiliary projects (basically, tags). Possibly we should split these more explicitly.

In particular, if we have some secret project (like "April Fools Prank"), I think objects in that project should generally inherit the project's visibility and policies, so normal users can't see all the tasks/mocks in the project.

However, if objects can be associated with more than one project in this way, I think this will quickly lead to visibility rules which very expensive to execute (undesirable, but not the end of the world) and incomprehensible to users (more of a showstopper).

I guess I see a few options:

1. Add a "Projects" field, which can be empty or have any number of projects (similar to how Maniphest works today).
   • Pro: Very simple.
   • Con: Putting a mock in the "April Fools Prank" project won't hide it from the world. You'd have to explicitly set the policy to be the same as the project. I'm not sure this is really that bad, but I'm very wary of it: I think it will defy user expectations and make policies a lot harder to understand. My gut feeling is that "stuff in project X has the same policies as project X" is the right implementation to pursue.
2. Add a "Project" field, which can be empty or have one project.
   • Pro: Very simple.
   • Con: This effectively drops tag support. I'm not sure how valuable tags really are, especially outside of Maniphest. I don't think they're necessarily all that useful; users generally don't seem to want to use them to solve problems (they ask for first-class implementations of features which can reasonably approximated with tags). I can't think of many things I'd want to use tags for in, e.g., Differential or Pholio (especially after "severity").
3. Add a "Project" field (which can be empty or have one project) AND a "Tags" field (which can have be empty or have any number of projects; the "Project" automatically becomes a "Tag" as well).
   • Pro: Addresses both the policy and tagging use cases.
   • Con: More complex, and ugly/gross.
4. Add a "Project" field which can be empty or have more than one project, but only a maximum of one "heavyweight" project, where "heavyweight" projects are defined by project types that we add in T390.
   • Pro: Addresses both the policy and tagging use cases. Not so ugly.
   • Con: Probably way harder for users to figure out than (3).

I think I lean toward (3), I just don't love adding extra fields. :/

I actually lean towards 4. It seems the same as 3, just more work that I think we have to do anyways in the long term.

I think having Policies only available on 'super-projects' makes sense and with the updated project 'tokens' I think it would be something we could make clear to users. Right now we don't do much in the design to really establish secret and public projects. But I think with Workphlow, we pick up some design elements that makes it much more clear the Policy of the super-project and the objects within it. I do think this is something we're going to have to solve (how to visually represent Policy) across the various applications. It might be something we can work uniformly into the object's header like we're looking at in Workphlow.

So a workflow for me might be this, we have a super-project called 'Phacility' and I add that as my Project when uploading a Mock. Then in Pholio we'll say put a lock before 'M21 Accounting Index Mock' that would indicate that the mock has limited visibility distribution. A tooltip could explain 'visible only to members of Phacility'.

If the super-project were open, like 'Pholio V2', then I could still only tag it to one super-project, plus any number of other tags.

Overall, I just want to be able to sort the mocks once they get long, and just like tasks, 'projects' are usually the easiest.

For right now it seems just allowing me to tag it to any public project is sufficient.

These were the update project tokens/tags, just to be clear. We should maybe provide a different color for super-projects as well.

{F35329}

So, what do we actually want here?

If approach 4, this is blocked on finishing making projects awesome, right? Thus I think we should table this in terms of unbeta-ing this or... take approach 1.

Probably best to do this the "right way", and wait for T390. I don't see any benefit to doing this before then as they won't really be discoverable that way.

Agreed that this shouldn't block un-beta'ing. I want to sweep through ~every app and build this on shared infrastructure once we sort it out.

◀ Merged tasks: T1773.

◀ Merged tasks: T793.

https://github.com/facebook/phabricator/issues/401 discusses this for Phame specifically.

D9340 provides basic support.

D9341 is an approximate example of implementation in an application.

These objects should support projects, by implementing this interface and gaining appropriate edit controls (similar to D9341):

• PholioMock (straightforward)
• PonderQuestion (straightforward?)
• PhabricatorRepository (some existing support)
• DifferentialRevision (uses CustomField)
• PhabricatorRepositoryCommit (some existing support)
• CalendarEvent (probably complicated?)
• SlowvotePoll (straightforward, less important)
• Countdown (straightforward, less important)
• ManiphestTask (very complicated)

Some of these will be very similar to D9341. Others will be more involved, weird, or funky.

• PhabricatorRepositoryCommit should wait for T4896.
• ManiphestTask should wait for T5245.
• CalendarEvent should wait for T5464.

• PhabricatorRepositoryCommit is good to go. It has some UI already, so I think the remaining work is mostly swapping it over to use ApplicationTransactions.
• ManiphestTask got taken care of during T5245.
• CalendarEvent is still waiting for T5464.