Pholio needs a way to resolve mocks. The easiest path here is just to allow closing of mocks like we can close tasks. It could be we add review later, but I haven't seen external need for that with Pholio in the past year, and I have seen (and want personally) the need to clean up / resolve / archive old mocks.
My suggestion would be:
Closed
Closed, Launched
Closed, Just an idea
Closed, Archived
I suppose these should be settable like Maniphest phases as well.
| rP Phabricator | |||
| D9145 | rP3d457a53be60 Close pholio mocks | ||
I opened this back up, it's reasonable (and I would use it here) to offer some resolution of a mock. This would make the Pholio home experience much nicer as well and help build useful Dashboard Panels.
Do you think this should be separate from T2693? i.e., we should have both "Severity" and "Resolution"? I think this is a good idea, but that we can cover both ideas with one field that has options like: Draft, Hey Maybe Look At This, Kinda Want Some Feedback, Abandoned, Shipped
I'm tempted to close the severity task, I it's use is fairly narrow and I haven't seen much interest in it, like any.
Maybe we merge that here? We can start with:
...and leave room for that list to eventually have a few "open" states and maybe a few "closed" states?
Same deal as Slowvote, except we should use a VARCHAR(12) NOT NULL COLLATE utf8_bin column instead of a bool column, and store the values "open" and "closed" instead of 0 and 1, because we anticipate a reasonable chance that we'll want to put more stuff on there eventually. We should also migrate, so the patch will look something like:
ALTER TABLE {$NAMESPACE}_pholio.pholio_mock ADD COLUMN status VARCHAR(12) NOT NULL COLLATE utf8_bin; UPDATE {$NAMESPACE}_pholio.pholio_mock SET status = "open" WHERE status = "";
Also, PhabricatorSlowvotePHIDTypePoll and PholioPHIDTypeMock should call this in loadHandles() for closed objects:
$handle->setStatus(PhabricatorObjectHandleStatus::STATUS_CLOSED);
You can look at DifferentialPHIDTypeRevision for an example of an implementation. This will make the global search work properly, and let the objects be drawn correctly with strikethru when appropriate.
You don't need to plan for more statuses beyond using a VARCHAR for the moment, we have a pretty reasonable/compelling use case for "Closed" vs "Open" but aren't really sure we want/need multiple closed/open statuses yet. T2693 has some more discussion about possibly building a bit more structure on the tool, but we should wait until we get more feedback before locking things down here too much.