Page MenuHomePhabricator

Add project tags to Pholio, Ponder, Differential, and other applications
Closed, ResolvedPublic

Tokens
"Love" token, awarded by svemir."Mountain of Wealth" token, awarded by frgtn."Like" token, awarded by allan.laal.
Assigned To
Authored By
chad, Feb 28 2013

Description

See https://secure.phabricator.com/T2628#comment-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).

Original ask: When I create a Mock in Pholio, I want to assign it to a Project for sorting / discovery. Bonus points for adding a filter search as well.

Event Timeline

chad added subscribers: chad, epriestley.
epriestley triaged this task as Normal priority.Feb 28 2013, 10:32 PM
epriestley edited projects, added Pholio; removed OS Students 2013.
epriestley edited this Maniphest Task.Feb 28 2013, 10:32 PM
epriestley edited this Maniphest Task.

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

Filtering stuff should probably block on T2625.

epriestley edited this Maniphest Task.Mar 3 2013, 7:29 PM

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. :/

chad added a comment.Mar 10 2013, 9:30 PM

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.

chad added a comment.Mar 10 2013, 9:32 PM

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

{F35329}

chad added a subscriber: btrahan.Mar 10 2013, 9:33 PM

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.

chad added a comment.Aug 20 2013, 5:38 PM

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.

btrahan edited this Maniphest Task.Aug 20 2013, 5:39 PM
btrahan updated the task description. (Show Details)Aug 20 2013, 5:40 PM

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.

btrahan edited this Maniphest Task.Aug 20 2013, 7:43 PM
epriestley renamed this task from Add project tags to Pholio to Add project tags to Pholio, Ponder, Differential, and other applications.Aug 22 2013, 12:24 PM

◀ Merged tasks: T1773.

epriestley edited this Maniphest Task.Aug 22 2013, 12:24 PM
epriestley added subscribers: aran, jungejason, cadamo and 5 others.

◀ Merged tasks: T793.

brent added a subscriber: brent.Oct 13 2013, 12:33 AM
epriestley edited this Maniphest Task.Oct 19 2013, 10:56 PM
hwinkel added a subscriber: hwinkel.Dec 1 2013, 9:35 AM
epriestley edited this Maniphest Task.Dec 26 2013, 10:55 PM
epriestley edited this Maniphest Task.Jan 3 2014, 1:19 AM
epriestley edited this Maniphest Task.Jan 3 2014, 5:21 PM
epriestley edited this Maniphest Task.Jan 3 2014, 8:24 PM
epriestley edited this Maniphest Task.
frgtn added a subscriber: frgtn.Mar 14 2014, 6:28 PM
chad lowered the priority of this task from Normal to Low.Mar 21 2014, 5:22 AM
chad moved this task to On Deck on the Pholio board.
chad moved this task from On Deck to v2 on the Pholio board.Mar 23 2014, 1:32 AM
qgil added a subscriber: qgil.Apr 24 2014, 4:45 AM
svemir added a subscriber: svemir.Apr 30 2014, 2:13 PM
wez removed a subscriber: wez.Apr 30 2014, 5:56 PM

You can ignore most of the discussion on this issue, it's slightly more than a year old and the direction has evolved since then.

I'm going to implement some kind of interface which formalizes objects that can belong to projects. This is likely to be a bit complicated, and probably easier for me to just build than try to describe.

Once it's implemented, this task will break down as going through every application and implementing it on major objects (DifferentialRevision, PholioMock, PonderQuestion, PhrictionDocument, etc), adding UI for it, and testing it. I'll give you a proper list once this is ready to go.

epriestley edited this Maniphest Task.May 30 2014, 11:24 PM
epriestley edited this Maniphest Task.May 30 2014, 11:27 PM

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.

epriestley edited this Maniphest Task.Jun 4 2014, 12:19 AM
epriestley edited this Maniphest Task.Jun 4 2014, 12:22 AM
epriestley edited this Maniphest Task.Jun 14 2014, 10:02 PM
epriestley edited this Maniphest Task.Jun 24 2014, 4:39 PM
  • PhabricatorRepositoryCommit should wait for T4896.
  • ManiphestTask should wait for T5245.
  • CalendarEvent should wait for T5464.
epriestley edited this Maniphest Task.Jun 24 2014, 4:41 PM
epriestley edited this Maniphest Task.Jun 24 2014, 5:24 PM
epriestley edited this Maniphest Task.Jun 26 2014, 5:01 AM
epriestley edited this Maniphest Task.Jul 10 2014, 7:35 PM
epriestley closed subtask Restricted Maniphest Task as Wontfix.Aug 6 2014, 9:00 PM
  • 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.
lpriestley removed lpriestley as the assignee of this task.Nov 17 2014, 7:06 PM
lpriestley added a subscriber: lpriestley.
jayvdb added a subscriber: jayvdb.Feb 5 2015, 12:03 AM
epriestley raised the priority of this task from Low to Normal.

Oh, I actually meant T5595.

epriestley removed epriestley as the assignee of this task.Apr 18 2015, 2:33 PM
epriestley lowered the priority of this task from Normal to Low.
eadler added a subscriber: eadler.Apr 29 2015, 6:26 AM
chad changed the visibility from "All Users" to "Public (No Login Required)".Jul 18 2015, 11:02 PM
epriestley closed this task as Resolved.Aug 5 2015, 8:59 PM
epriestley claimed this task.

I think everything actually implements PhabricatorPolicyInterface now, and the rest of this is covered by T8633 / T8634 (when modernized, project filtering happens for free).