1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-28 17:52:43 +01:00
Commit graph

119 commits

Author SHA1 Message Date
epriestley
9d59086d01 Consolidate transaction generation in EditType objects
Summary:
Ref T9132. This is a bit more cleanup to make adding CustomField support easier.

Right now, both `EditField` and `EditType` can actually generate a transaction. This doesn't matter too much in practice today, but gets a little more complicated a couple of diffs from now with CustomField stuff.

Instead, always use `EditType` to generate the transaction. In the future, this should give us less total code and make more things work cleanly by default.

Test Plan: Used web UI and Conduit to make various edits to pastes, including doing race-condition tests on "Projects".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14607
2015-11-30 09:01:00 -08:00
epriestley
56be700561 Improve code structure of PHID fields in EditEngine
Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better.

Test Plan:
  - Edited subscribers and projects.
  - Verified things still show up in Conduit.
  - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14601
2015-11-30 09:00:37 -08:00
epriestley
50f257adee Allow EditEngine Conduit endpoints to accept object IDs and monograms
Summary:
Ref T9132. This is a quality-of-life improvement for new `application.edit` endpoints.

Instead of strictly requiring PHIDs, allow IDs or monograms. This primarily makes these endpoints easier to test and use.

Test Plan: Edited objects via API by passing IDs, PHIDs and monograms.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14600
2015-11-30 09:00:24 -08:00
epriestley
acd955c6c9 Modularize application extensions to EditEngine
Summary:
Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this:

```
if ($object instanceof Whatever) {
  do_magic();
}

if ($object instanceof SomethingElse) {
  do_other_magic();
}
```

...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface.

This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this.

T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too.

Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us.

Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon).

Test Plan:
{F1007575}

  - Observed that all fields still appear on the form and seem to work correctly.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14599
2015-11-30 08:59:27 -08:00
epriestley
37893ba2e6 Allow EditEngine configurations to be disabled and marked as "Default"
Summary:
Ref T9132.

Let configurations be enabled/disabled. This doesn't do much right now.

Let configurations be marked as default entries in the application "Create" menu. This makes them show up in the application in a dropdown, so you can replace the default form and/or provide several forms.

In Maniphest, we'll do this to provide a menu something like this:

  - New Bug Report
  - New Feature Request
  - ADVANCED TASK CREATION!!11~ (only available for Community members)

Test Plan: {F1005679}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14584
2015-11-29 08:27:26 -08:00
Chad Little
a6e24cb2be Remove pro-white-background, re-style PHUIDocumentViewPro
Summary: This makes document views a little more automatic, and a little more style to the page. The Document itself remains on a pure white centered background, but footer and preceeding objects go back to the original body color. This provides a bit more depth and separation over content and definitions/comments.

Test Plan:
Tested Phriction, Diviner, Legalpad, Phame, Email Commands, HTTP Commands, with and without a footer.

{F1005853}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14582
2015-11-28 07:20:55 -08:00
epriestley
c034752578 Support comments as an EditEngine field
Summary:
Ref T9132. This adds an automatic "Comments" field, like the Subscribers/Projects/Policy fields.

The primary goals here are:

  - Allow users to make comments via Conduit.
  - In the future, get stackable action support.

As a side effect, this also allows you to put comments on create forms. This is a little silly but seems fine, and may be relevant on edit forms (which I'm not 100% sure how I want to handle yet). I've just hidden them by default for now.

Test Plan:
{F976036}

{F976037}

{F976038}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14515
2015-11-22 16:27:17 -08:00
epriestley
269e0bfc94 Allow EditEngine form fields to be locked and hidden
Summary:
Ref T9132. Allows fields to be locked (shown, but not modifiable) and hidden (not shown).

In both cases, default values are still respected.

This lets you do things like create a form that generates objects with specific projects, policies, etc.

Test Plan:
  - Set defaults.
  - Locked and hid a bunch of fields.
  - Created new objects using the resulting form.

{F975801}

{F975802}

{F975803}

{F975804}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14509
2015-11-22 16:25:32 -08:00
epriestley
53d5cd3950 Allow EditEngine forms to have defaults assigned
Summary: Ref T9132. Allow form configurations to include defaults (like default projects, spaces, policies, etc).

Test Plan:
Defaulted "Language" to "Rainbow", plus other adjustments:

{F975746}

{F975747}

{F975748}

{F975749}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14508
2015-11-22 16:25:00 -08:00
epriestley
9aee90f8c1 Allow form configurations to retitle and reorder forms and add preambles
Summary:
Ref T9132. This just makes edited forms do //something//, albeit not anything very useful yet.

You can now edit a form and:

  - Retitle it;
  - add a preamble (instructions on top of the form); and
  - reorder the form's fields.

Test Plan:
{F974632}

{F974633}

{F974634}

{F974635}

{F974636}

Reviewers: chad

Reviewed By: chad

Subscribers: hach-que

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14503
2015-11-22 15:12:57 -08:00
epriestley
12dd9ec3ff Have EditEngine API methods provide the correct application to Conduit
Summary:
Fixes T9799. Currently, if you can't see an application like Paste, we fatal when trying to generate a result for `conduit.query`, because the new EditEngine-based `paste.edit` method doesn't "know" that it's a "Paste" method.

Straighten this out, and use policies and queries a little more correctly/consistently.

Test Plan:
  - Called `conduit.query` as a user who does not have permission to use Paste.
  - Before change: fatal.
  - After change: results, excluding "paste.*" methods.

Reviewers: chad

Reviewed By: chad

Subscribers: cburroughs

Maniphest Tasks: T9799

Differential Revision: https://secure.phabricator.com/D14492
2015-11-16 10:02:50 -08:00
epriestley
7e3d8082df Fix missing EditEngineConfig on indirect pathway through conduit.query
Summary: Fixes T9772. We now need an EditEngineConfiguration to do interesting things with EditEngine, but this public API wasn't properly making sure we have one.

Test Plan: Called `conduit.query` from web console. Fatal prior to patch; success afterward.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9772

Differential Revision: https://secure.phabricator.com/D14475
2015-11-12 11:22:37 -08:00
epriestley
0398097498 Allow ApplicationEditor forms to be reconfigured
Summary:
Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs.

Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like:

  - "New Bug Report"
  - "New Feature Request"

These would be views of the "Create Task" form, but with various adjustments:

  - A form might have additional instructions ("how to file a good bug report").
  - A form might have prefilled values for some fields (like particular projects, subscribers, or policies).
  - A form might have some fields locked (so they can not be edited) or hidden.
  - A form might have a different field order.
  - A form might have a limited visibility policy, so only some users can access it.

This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way".

This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future.

Test Plan:
ApplicationEditor forms now let you manage available forms and edit the current form:

{F959025}

There's a new (bare bones) list of all available engines:

{F959030}

And if you jump into an engine, you can see all the forms for it:

{F959038}

The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14453
2015-11-10 10:24:40 -08:00
epriestley
621f806e3b Provide formal Users/Projects/Mailable fields for EditEngine
Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean.

Test Plan:
  - Did `/?subscribers=...` with various values (good, bad, mis-capitalized).
  - Did `/?projects=...` with various values (good, bad, mis-capitalized).
  - Reviewed documentation.
  - Reviewed {nav Config > HTTP Parameter Types}.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 12:05:41 -08:00
epriestley
9de4bc6f3a Slightly improve organization of PhabricatorApplicationEditEngine
Summary: Ref T9132. This just moves code around, breaks it up into some smaller chunks, tries to reduce duplication, and adds a touch of documentation.

Test Plan: Created and edited pastes.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14398
2015-11-04 12:05:06 -08:00
Chad Little
39f8feab5a PHUIDocumentViewPro tweaks
Summary: Use in MailCommands and HTTP Parameters

Test Plan: Tested MailCommands in Paste, HTTP Parameters in Paste, Legalpad, Diviner. Mobile and Desktop breakpoints.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14397
2015-11-03 13:43:26 -08:00
epriestley
5030ba0401 Roughly generate transaction-oriented API methods from EditEngines
Summary:
Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines.

These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added.

Test Plan:
  - Used new `paste.edit` to create a new Paste.
  - Used new `paste.edit` to update an existing paste.
  - Applied a variety of different transactions.
  - Hit a reasonable set of errors.

{F941144}

{F941145}

{F941146}

{F941147}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5873, T9132

Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 10:12:37 -08:00
epriestley
3dec4c7dbd Provide contextual documentation explaining how to prefill ApplicationEditor create forms
Summary:
Ref T9132. Although forms do generally support prefilling right now, you have to guess how to do it.

Provide an explicit action showing you which values are supported and how to prefill them. This is generated automatically when an application switches to ApplicationEditor.

Test Plan:
{F939804}

{F939805}

{F939806}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14392
2015-11-03 10:12:17 -08:00
epriestley
105cbaaee1 Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.

This mostly looks and works like ApplicationSearch, and is heavily modeled on it.

Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.

This has no functional changes, except:

  - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
  - Subscribers are now editable.
  - Form field order is a little goofy (this will be fixed in a future diff).
  - Subscribers and projects are now race-resistant.

The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.

Test Plan:
  - Created pastes.
  - Created pastes via API.
  - Edited pastes.
  - Edited every field.
  - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4768, T9132

Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 10:11:54 -08:00