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

11 commits

Author SHA1 Message Date
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