1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2025-02-10 22:08:32 +01:00
Commit graph

6 commits

Author SHA1 Message Date
Joshua Spence
495cb7a2e0 Mark PhabricatorPHIDType::getPHIDTypeApplicationClass() as abstract
Summary: Fixes T9625. As explained in a `TODO` comment, seems reasonable enough.

Test Plan: Unit tests.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, hach-que

Maniphest Tasks: T9625

Differential Revision: https://secure.phabricator.com/D14068
2015-11-03 06:47:12 +11:00
epriestley
04186e02cf Separate handle "status" and "availability"
Summary:
Ref T7707. Handles currently have a "status" field and a "disabled" field.

The "status" field has these possible values: "open", "closed", "1", "2". durp durp durp

Instead, do:

  - status = <open, closed>
  - availability = <full, partial, none, disabled>

I think these make more sense? And are a bit more general? And use the same kind of constants for all values!

Test Plan: Looked at all affected handles in all states (probably).

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7707

Differential Revision: https://secure.phabricator.com/D12832
2015-05-14 11:14:44 -07:00
Chad Little
12dc865a00 Expand typeahead document copy
Summary: Seems reasonable? At least, it always matches however a user might think about documents (app or document). Unclear if "Diffusion" for example, are actually needed.

Test Plan: tested searching for "phriction", "wiki", "document", etc.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12577
2015-04-27 10:06:38 -07:00
epriestley
b49645d25b Use a typeahead for "document types" in global search
Summary:
  - Now that we have "browse", this is a much more reasonable control for random sets of things.
  - The new explicit search scope selector reduces the need to fiddle with this field manually, too.

Test Plan:
{F379292}

{F379293}

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D12510
2015-04-22 15:25:34 -07:00
epriestley
09fb5667cc Allow users to back initiatives in Fund
Summary:
Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such.

Notable changes:

  - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird.
  - I think that's it?

Test Plan:
  - Backed an initiative.
  - Viewed that I became a backer.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5835

Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 06:31:11 -07:00
epriestley
e4f399b9fa Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.

You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).

Only notable decisions:

  - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
  - I think that's it?

Test Plan:
  - Created an initiative.
  - Edited an initiative.
  - Changed application policy defaults.
  - Searched for initiatives.
  - Subscribed to an initiative.
  - Opened/closed an initiative.
  - Used `I123` and `{I123}` in remarkup.
  - Destroyed an initiative.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5835

Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 13:38:58 -07:00