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

28 commits

Author SHA1 Message Date
Chad Little
a939bbc4fa Update EditEngine for two column
Summary: Cleans up EditEngine, adds new layout to EditEngine and descendents

Test Plan: Test creating a new form, reordering, marking and unmarking defaults. View new forms.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15531
2016-03-28 09:18:55 -07:00
Chad Little
fe5cd4ca2c Move FontIcon calls to Icon
Summary: Normalizes all `setFontIcon` calls to `setIcon`.

Test Plan: UIExamples, Almanac, Apps list, etc.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, hach-que, yelirekim

Differential Revision: https://secure.phabricator.com/D15129
2016-01-28 08:48:45 -08:00
epriestley
f24318f308 Make "profile menu" configuration mostly work
Summary:
Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus).

This includes:

  - Editing builtin items (e.g., you can rename the default items).
  - Creating new items (for now, only links are available).

This does not yet include:

  - Hiding items.
  - Reordering items.
  - Lots of fancy types of items (dashboards, etc).
  - Any UI changes.
  - Documentation (does feature: TODO link for documentation).

Test Plan:
{F1060695}

{F1060696}

{F1060697}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10054

Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 11:45:31 -08:00
epriestley
ecc3314a25 Modularize transaction/comment indexing in the FulltextEngine
Summary:
Ref T9979. This is currently hard-coded but can be done in a generic way.

This has one minor behavioral changes: answer text is no longer included in the question text index in Ponder. I'm not planning to accommodate that for now since I don't want to dig this hole any deeper than I already have. This behavior should be different anyway (e.g., index the answer, then show the question in the results or something).

Test Plan:
  - Put a unique word in a Maniphest comment.
  - Searched for the word.
  - Found the task.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14837
2015-12-21 17:24:40 -08:00
epriestley
38e31375ea Improve UX for customizing EditEngine forms a little bit
Summary:
Ref T10004. Tweaks some of the UX a little to be more intuitive/inviting?

  - Button says "Configure Form" instead of "Actions".
  - Root list is less "developer-ey" and more "explain what this is for-ey".

Test Plan:
{F1028928}

{F1028929}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14808
2015-12-17 08:40:00 -08:00
epriestley
2f8e409876 Allow EditEngine forms to be marked as "edit" forms
Summary:
Ref T9132. Ref T9908. This attempts to move us forward on answering this question:

> Which form gets used when a user clicks "Edit Task"?

One answer is "the same form that was used to create the task". There are several problems with that:

  - The form might not exist anymore.
  - The user might not have permission to see it.
  - Some of the fields might be hidden, essentially preventing them from being edited.
  - We have to store the value somewhere and old tasks won't have a value.
  - Any instructions on the form probably don't apply to edits.

One answer is "force the default, full form". That's not as problematic, but it means we have no ability to create limited access users who see fewer fields.

The answer in this diff is:

  - Forms can be marked as "edit forms".
  - We take the user to the first edit form they have permission to see, from a master list.

This allows you to create several forms like:

  - Advanced Edit Form (say, all fields -- visible to administrators).
  - Basic Edit Form (say, no policies -- visible to trusted users).
  - Noob Edit Form (say, no policies, priorities, or status -- visible to everyone).

Then you can give everyone access to "noob", some people access to "basic", and a few people access to "advanced".

This might only be part of the answer. In particular, you can still //use// any edit form you can see, so we could do these things in the future:

  - Give you an option to switch to a different form if you want.
  - Save the form the task was created with, and use that form by default.

If we do pursue those, we can fall back to this behavior if there's a problem with them (e.g., original form doesn't exist or wasn't recorded).

There's also no "reorder" UI yet, that'll be coming in the next diff.

I'm also going to try to probably make the "create" and "edit" stuff a little more consistent / less weird in a bit.

Test Plan: Marked various forms as edit forms or not edit forms, made edits, hit permissions errors, etc.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132, T9908

Differential Revision: https://secure.phabricator.com/D14702
2015-12-08 13:00:30 -08:00
epriestley
5caee3521e Clean up some EditEngine policy issues
Summary:
Ref T9908.

  - You should not need edit permission on a task in order to comment on it.
  - At least for now, ignore any customization in Conduit and Stacked Actions. These UIs always use the full edit form as it's written in the application.

Test Plan:
  - Verified a non-editor can now comment on tasks they can see.
  - Verified a user still can't use an edit form they can't see.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14691
2015-12-07 11:13:04 -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
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
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
Bob Trahan
99b4941c9a Conpherence - use some handle pools for Durable column perf
Summary:
Ref T7708.

This changes things to $viewer->loadHandles where applicable in the durable column render stack. I saw some big wins on my test data like 34 queries => 24 queries on a newly created room as my default thread.

For my test data, the next big perf win would be to change how remarkup rendering works and try to multiload all objects of a certain type in one shot.
e.g. `PhabricatorEmbedFileRemarkupRule` implements `loadObjects` as do all classes which inherit from `PhabricatorObjectRemarkupRule`. This is because `PhabricatorObjectRemarkupRule` implements its `didMarkupText` method using `loadObjects`, and `didMarkupText` gets called per transaction over in `PhabricatorMarkupEngine->process()`. Instead, the `loadObjects` in `didMarkupText` should be hitting some cache, and we should do a bulk load for all `PhabricatorEmbedFileRemarkupRule` that had matches earlier in the rendering stack.  ...I think.

Test Plan: carefully looked at "Services" tab in dark console and noted fewer queries with changes post changes versus pre changes

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7708

Differential Revision: https://secure.phabricator.com/D12780
2015-05-08 18:14:04 -07:00
epriestley
f5580c7a08 Make buildWhereClause() a method of AphrontCursorPagedPolicyAwareQuery
Summary:
Ref T4100. Ref T5595.

To support a unified "Projects:" query across all applications, a future diff is going to add a set of "Edge Logic" capabilities to `PolicyAwareQuery` which write the required SELECT, JOIN, WHERE, HAVING and GROUP clauses for you.

With the addition of "Edge Logic", we'll have three systems which may need to build components of query claues: ordering/paging, customfields/applicationsearch, and edge logic.

For most clauses, queries don't currently call into the parent explicitly to get default components. I want to move more query construction logic up the class tree so it can be shared.

For most methods, this isn't a problem, but many subclasses define a `buildWhereClause()`. Make all such definitions protected and consistent.

This causes no behavioral changes.

Test Plan: Ran `arc unit --everything`, which does a pretty through job of verifying this statically.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: yelirekim, hach-que, epriestley

Maniphest Tasks: T4100, T5595

Differential Revision: https://secure.phabricator.com/D12453
2015-04-20 10:06:09 -07:00
epriestley
2794c69db5 Remove getPagingColumn() / getReversePaging()
Summary: Ref T7803. Remove these in favor of more generalized paging and ordering.

Test Plan: Sorted and paged results in various applications.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7803

Differential Revision: https://secure.phabricator.com/D12378
2015-04-13 11:58:32 -07:00
epriestley
7427a6e648 Extend TransactionCommentQuery for Differential
Summary: Ref T2009. Ref T1460. Replace hard-coded garbage with a real Query-layer query.

Test Plan: Submitted inline comments in Differential.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2009, T1460

Differential Revision: https://secure.phabricator.com/D12027
2015-03-09 14:11:20 -07:00
epriestley
4d86d51125 Prepare TransactionCommentQuery for extension
Summary:
Ref T2009. Ref T1460. The way Diffusion and Differential load inlines is horrible garbage right now:

  - Differential does an ad-hoc query to get the PHIDs, then does a real load to policy check.
  - Diffusion completely fakes things. In practice this is not a policy violation, but it's dangerous.

Make TransactionCommentQuery extensible so we can subclass it and get the query building correctly in the right Query layer.

Specifically, the Diffusion and Differential subclasses of this Query will add appropriate `withX()` methods to let us express the query in SQL.

Test Plan: Loaded, previewed, edited, and submitted inlines in Differential and Diffusion

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2009, T1460

Differential Revision: https://secure.phabricator.com/D12026
2015-03-09 14:11:18 -07:00
Bob Trahan
d6341cfffe Transactions - add pagination to application transactions
Summary: Ref T4712. This adds pagination. Future diffs will need to deploy `buildTransactionTimeline` everywhere and massage this stuff as necessary if we hit any special cases.

Test Plan: Set page size to "5" to make it need to paginate often. Verified proper transactions loaded in and the javascript actions worked.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T4712

Differential Revision: https://secure.phabricator.com/D10887
2014-12-02 13:10:29 -08:00
epriestley
2f1b5ae010 Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:

  - Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
  - Make properties more generic so Services, Bindings and Devices can all have them.

The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.

I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.

This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.

Test Plan: {F229172}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10777
2014-11-05 15:27:16 -08:00
epriestley
01572d9d93 Implement "Repository" as a new-style CustomField in Differential
Summary:
Ref T3886. Ref T418.

  - Adds new capabilities for CustomField:
    - Controls can now bulk-load PHIDs (e.g., for tokenizers).
    - Transactions can now bulk-load PHIDs (e.g., for relationship changes).
  - Implements "Repository" control.
  - Improves tokenizer StandardCustomField controls.

Test Plan:
{F115942}

{F115943}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T418, T3886

Differential Revision: https://secure.phabricator.com/D8286
2014-02-21 11:53:37 -08:00
epriestley
3103ce33b8 Load and attach objects when loading application transactions
Summary:
Ref T3886. Fixes the removed TODO. This also implements the generally reasonable policy "you have to be able to see an object in order to see its transactions". That was implicit before (we never load transactions without loading an object first) but is now explicit.

This fixes bad (nonspecialized) rendering of custom field transactions in Projects, and shortly in Differential, where stories would read "alincoln edited this object." instead of a more specific string.

Test Plan: Viewed a project edit, saw a more specific string. Browed ApplicationTransaction applications.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3886

Differential Revision: https://secure.phabricator.com/D8273
2014-02-18 16:32:35 -08:00
epriestley
2a5c987c71 Lock policy queries to their applications
Summary:
While we mostly have reasonable effective object accessibility when you lock a user out of an application, it's primarily enforced at the controller level. Users can still, e.g., load the handles of objects they can't actually see. Instead, lock the queries to the applications so that you can, e.g., never load a revision if you don't have access to Differential.

This has several parts:

  - For PolicyAware queries, provide an application class name method.
  - If the query specifies a class name and the user doesn't have permission to use it, fail the entire query unconditionally.
  - For handles, simplify query construction and count all the PHIDs as "restricted" so we get a UI full of "restricted" instead of "unknown" handles.

Test Plan:
  - Added a unit test to verify I got all the class names right.
  - Browsed around, logged in/out as a normal user with public policies on and off.
  - Browsed around, logged in/out as a restricted user with public policies on and off. With restrictions, saw all traces of restricted apps removed or restricted.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7367
2013-10-21 17:20:27 -07:00
epriestley
6fd1e01fe7 Run Maniphest batch edits through modern editor
Summary:
Ref T2217. Swaps batch edits to modern editor.

Also, fix some issues with required fields and viewers being required to render certain standard fields (notably, date).

Test Plan: Made various batch edits, verified they went through properly.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7083
2013-09-23 14:32:22 -07:00
Bob Trahan
b902005bed Kill PhabricatorObjectDataHandle
Summary: Ref T603. Killing this class is cool because the classes that replace it are policy-aware. Tried to keep my wits about me as I did this and fixed a few random things along the way. (Ones I remember right now are pulling a query outside of a foreach loop in Releeph and fixing the text in UIExample to note that the ace of hearts if "a powerful" card and not the "most powerful" card (Q of spades gets that honor IMO))

Test Plan: tested the first few changes (execute, executeOne X handle, object) then got real mechanical / careful with the other changes.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran, FacebookPOC

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D6941
2013-09-11 12:27:28 -07:00
epriestley
5cc3bbf721 Use application PHIDs for application transactions
Summary: Ref T2715. Ref T3578. Load application transactions through application PHID infrastructure.

Test Plan: Viewed feed, saw successful loads of application transaction objects and rendered feed stories.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2715, T3578

Differential Revision: https://secure.phabricator.com/D6617
2013-07-29 12:04:15 -07:00
epriestley
644f377915 Move non-comment transactions to a separate history view in Ponder
Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page.

Test Plan: Viewed question page; viewed history page for question and answer.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3373

Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 12:04:11 -07:00
epriestley
9db4feda09 Further corrections to Conpherence updates
Summary:
Apparently I am crazy and didn't test D5537 propertly at all. In particular:

  - Currently, the update sends back new "people" and "files" widgets. The "people" widget has a tokenizer, which fatals when the behavior initializes without the widget in the DOM. For now, disable widget updates on replies. I'll fix this in a future diff.
  - Currently, we don't update the "last_transaction_id" in the form itself, so the first reply sends back 1 message, the next 2 messages, etc. Update the input.
  - The transaction paging doesn't and has never worked, I am crazy. Make it actually work.

Test Plan:
computers are too hard

(also, this is why I hate Javascript)

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D5538
2013-04-02 11:27:58 -07:00
vrana
b3a63a62a2 Introduce PhabricatorEmptyQueryException
Summary: It's dumb to execute a query which we know will return an empty result.

Test Plan: Looked at comment preview with "11", didn't see "1 = 0" in DarkConsole.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D5177
2013-03-06 19:22:00 -08:00
epriestley
26dd2a0eef Allow ApplicationTransaction comments to be edited and deleted
Summary:
Allows you to edit or delete comments in appplications which support ApplicationTransactions.

UI/UX stuff:

  - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks.
  - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this.
  - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable.
  - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted).

Test Plan:
Transaction view, note "Edit" and "Edited" links:

{F26914}

Edit view, has some design issues but I want to do a pass on dialogs in general:

{F26915}

History view:

{F26913}

Reviewers: vrana, btrahan, chad

Reviewed By: vrana

CC: aran

Maniphest Tasks: T1082

Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 14:01:51 -08:00
epriestley
7b6fa0db12 Genericize transactions in Pholio
Summary:
Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for:

  - Editing and deleting comments.
  - Setting visibility of individual comments (I'm not a fan of this feature but we'll see).

I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code.

Tons of work left to do here, but I think it basically works. Here's a screenshot:

{F26820}

Test Plan: Made transactions in Pholio.

Reviewers: btrahan, vrana, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2104

Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 13:59:20 -08:00