1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-05 05:02:44 +01:00
Commit graph

16012 commits

Author SHA1 Message Date
epriestley
8c78cde32f Stop "git blame" from printing "^" markers on root repository commits
Summary: Depends on D19391. Ref T13126. See that task for some details on what's going on here.

Test Plan:
  - Viewed a file which includes lines that were added during the first commit to the repository.
  - Before D19391: fatal.
  - After D19391: blank.
  - After this patch: accurate blame information.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13126

Differential Revision: https://secure.phabricator.com/D19392
2018-04-20 14:13:10 -07:00
epriestley
95e179d9a4 Fix a fatal in the document engine blame view with files that blame to the initial commit
Summary:
Ref T13126. When you view a file using the new document engine view and some lines were introduced in the initial commit to the repository, Git renders "^abc123" in the blame output.

We currently don't do anything about this, and later fail to look it up and fatal.

It's also unlikely-but-conceivably-possible to end up here if a commit has not imported yet or has been nuked with `bin/remove destroy`.

Let the whole thing run without fataling even if a `$commit` is missing. Future refinements could improve this behavior.

Test Plan: Viewed a file with lines introduced in the initial commit, got empty blame instead of a fatal.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13126

Differential Revision: https://secure.phabricator.com/D19391
2018-04-20 14:12:50 -07:00
epriestley
9bf4df2c1d Allow demoted builds to automatically promote if builds pass after a restart
Summary:
Ref T13124. See PHI584. When you create a draft revision and it automatically demotes to "Changes Planned + Draft" because builds fail, let it promote to "Needs Review" automatically if builds pass. Usually, this will be because someone restarted the builds and they worked the second time.

Although I'm a little wary about adding even more state transitions to the diagram in T13110#237736, I think this one is reasonably natural and not ambiguous.

Test Plan:
  - Created a failing build plan with a "Throw Exception" step.
  - Created a revision which hit the build plan, saw it demote to "Changes Planned" when Harbormaster failed.
  - Edited the build plan to remove the "Throw Exception" step, restarted the build, got a pass.
  - Saw revision promote again:

{F5526104}

I didn't exhaustively test that the other 40 state transitions still work properly, but I think the scope of this change is small enough that it's unlikely I did much collateral damage.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13124

Differential Revision: https://secure.phabricator.com/D19380
2018-04-20 10:50:58 -07:00
Austin McKinley
4dc8e2de56 Add unique constraint to AlmanacInterfaces
Summary: See discussion in D19379. The 4-tuple of (device, network, address, port) should be unique.

Test Plan: Created lots of duplicate interfaces, bound those interfaces to various services, observed migration script clean things up correctly.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, PHID-OPKG-gm6ozazyms6q6i22gyam

Differential Revision: https://secure.phabricator.com/D19388
2018-04-19 19:16:50 -07:00
epriestley
843bfb4fd8 Add a "commits" attachment to "differential.diff.search" for retrieving local commit information
Summary:
Ref T13124. See PHI593.

When you `arc diff` in a Git or Mercurial repository, we upload some information about the local commits in your working copy which the change was generated from.

In the future (for example, with T1508) we may increase the prominence of this feature.

Provide a stable way to read this information back via the API. This roughly mirrors the information we provide about commits in "diffusion.commit.search", although the latter is less fleshed-out today.

Test Plan: Used `differential.diff.search` to retrieve commit information about Git, Mercurial, and Subversion diffs. (There's no info for Subversion, but it doesn't crash or anything.)

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13124

Differential Revision: https://secure.phabricator.com/D19386
2018-04-19 17:25:06 -07:00
epriestley
19403fdb8e Improve color use in "[+++- ]" element for colorblind users
Summary:
Ref T13127. Users with red/green colorblindness may have difficulty using this element in its current incarnation.

We could give it different behavior if the "Accessibility" option is set for red/green colorblind users, but try a one-size-fits-all approach since the red/green aren't wholly clear anwyay.

Test Plan: {F5530050}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13127

Differential Revision: https://secure.phabricator.com/D19385
2018-04-19 17:24:44 -07:00
epriestley
70d67a3908 Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.

When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.

For now, test that notifications are visible when you open the menu and clear any that are not.

This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.

Test Plan:
  - As Alice, configured task stuff to notify me (instead of sending email).
  - As Bailey, added Alice as a subscriber to a task, then commented on it.
  - As Alice, loaded home and saw a notification count. Didn't click it yet.
  - As Bailey, set the task to private.
  - As Alice, clicked the notification bell menu icon.
    - Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
    - After change: bad notifications automatically cleared.

{F5530005}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13131, T13124, T8953

Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 17:24:19 -07:00
Austin McKinley
e81b2173ad Add edge tables for Phlux
Summary: Fixes T13129. This at least makes the existing UI work again before we banish Phlux to the shadow realm.

Test Plan: Edited the visibility for a Phlux variable, didn't get an error. Nothing showed up in the edge tables when I made those changes, but at least it doesn't error out anymore.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, PHID-OPKG-gm6ozazyms6q6i22gyam

Maniphest Tasks: T13129

Differential Revision: https://secure.phabricator.com/D19387
2018-04-19 15:49:08 -07:00
Austin McKinley
0a83f253ed Add unique constraint for Almanac network names
Summary:
The name of networks should be unique.

Also adds support for exact-name queries for AlamanacNetworks.

Test Plan: Applied migration with existing duplicates, saw networks renamed, attempted to add duplicates, got a nice error message.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, PHID-OPKG-gm6ozazyms6q6i22gyam

Differential Revision: https://secure.phabricator.com/D19379
2018-04-19 13:41:15 -07:00
epriestley
a817aa6c71 Add an "Abort Older Builds" build step to Harbormaster
Summary:
Ref T13124. See PHI531. When a revision is updated, builds against the older diff tend to stop being relevant. Add an option to abort outstanding older builds automatically.

At least for now, I'm adding this as a build step instead of some kind of special checkbox. An alternate implementation would be some kind of "Edit Options" action on plans with a checkbox like `[X] When this build starts, abort older builds.`

I think adding it as a build step is a bit simpler, and likely to lead to greater consistency and flexibility down the road, make it easier to add options, etc., and since we don't really have any other current use cases for "a bunch of checkboxes". This might change eventually if we add a bunch of checkboxes for some other reason.

The actual step activates //before// the build queues, so it doesn't need to wait in queue before it can actually act. T13088 discusses some plans here if this sticks.

Test Plan:
  - Created a "Sleep for 120 seconds" build plan and triggered it with Herald.
  - Added an "Abort Older Builds" step.
  - Updated a revision several times in a row, saw older builds abort.

Reviewers: amckinley

Reviewed By: amckinley

Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam

Maniphest Tasks: T13124

Differential Revision: https://secure.phabricator.com/D19376
2018-04-17 14:59:47 -07:00
epriestley
665529ab60 Restore coverage reporting to Diffusion browse UI
Summary:
Depends on D19377. Ref T13125. Ref T13124. Ref T13105. Coverage reporting in Diffusion didn't initially survive the transition to Document Engine; restore it.

This adds some tentative/theoretical support for multiple columns of coverage, but no way to actually produce them in the UI. For now, the labels, codes, and colors are hard coded.

Test Plan:
Added coverage with `diffusion.updatecoverage`, saw coverage in the UI:

{F5525542}

Hovered over coverage, got labels and highlighting.

Double-checked labels for "N" (Not Executable) and "U" (Uncovered). See PHI577.

Faked some multi-column coverage, but you can't currently get this yourself today:

{F5525544}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13125, T13124, T13105

Differential Revision: https://secure.phabricator.com/D19378
2018-04-17 14:51:47 -07:00
epriestley
21bb0215db Remove obsoleted "diffusion-browse-file" behavior for coverage
Summary: Ref T13105. After moving Diffusion to DocumnentEngine, this no longer has callers. It will become part of the document behavior.

Test Plan: Grepped for calls to the `diffusion-browse-file` behavior, found none.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13105

Differential Revision: https://secure.phabricator.com/D19377
2018-04-17 14:51:12 -07:00
epriestley
f9b3673fbb When mail (like "!history" mail) has multiple comments, label them separately
Summary:
Depends on D19372. Ref T13124. See PHI505. Currently, if you `!history` a task with a lot of comments, you get output like this:

> alice added a comment.
> bailey added a comment.
> alice added a comment.
> alice added a comment.
>
> AAAA
>
> BBBB
>
> AAAA
>
> AAAA

This is impossible to read. Put the "alice added a comment." headers above the actual comments for comments after the first.

These types of mail messages are unusual, but occur in several cases:

  - The new `!history` command.
  - Multiple comments on a draft revision before it promotes out of draft.
  - (Probably?) Conduit API updates which submit multiple comment transactions for some reason.

Test Plan: Used `bin/mail receive-test` to send a `!history` command to a task, saw a much more readable rendering of the transaction log in the resulting email.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13124

Differential Revision: https://secure.phabricator.com/D19373
2018-04-16 12:28:24 -07:00
epriestley
25965260c4 Add a rough "!history" email command to get an entire object history via email
Summary:
See PHI505. Ref T13124. If you're an agent of a hostile state trying to exfiltrate corporate secrets, you might find yourself foiled if Phabricator is secured behind a VPN.

To assist users in this situation, provide a "!history" command which will dump the entire history of an object in a nice text format and get through the troublesome VPN.

Some issues with this:

  - You currently get all the "X added a comment." up top, and then all the comments below. This isn't terribly useful.
  - This goes through the "Must Encrypt" flag, but possibly should not? (On the other hand, this is a pretty willful way to bypass it the flag.)

Test Plan: Used `bin/mail receive-test ...` to send `!history` commands, got somewhat-useful response mail.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13124

Differential Revision: https://secure.phabricator.com/D19372
2018-04-16 12:27:52 -07:00
epriestley
b5f23b023e Add an "--auto" flag to "bin/differential migrate-hunk"
Summary:
Depends on D19370. See T13124. See PHI549. The particular install in PHI549 migrated a large amount of data via the fallback hunk migration script, which does not compress hunks.

Add a mode to `bin/differential migrate-hunk` that amounts to "compress all the hunks which would benefit from compression".

Test Plan: Ran `bin/differential migrate-hunk` with `--auto`, `--all`, `--to`, `--id`, and `--dry-run` in various mixtures. Forced a bunch of hunks to raw ("byte") format, saw it cleanly upgrade them to compressed ("gzde") format.

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D19371
2018-04-16 12:27:26 -07:00
epriestley
e3de7d09c0 Add an "--all" flag to "bin/differential migrate-hunk"
Summary:
Depends on D19369. Ref T13120. Add a flag to migrate every hunk.

This isn't terribly useful on its own, but I'm going to add an `--auto` flag next so that you can run `--auto --all` to migrate hunks to the preferred hunk format.

Test Plan: Ran `bin/differential migrate-hunk --all --to text`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120

Differential Revision: https://secure.phabricator.com/D19370
2018-04-16 12:26:48 -07:00
epriestley
6d1e007076 Try a more conventional spelling of "Convereted"
Summary: This is a good spelling, but maybe a better spelling is possible.

Test Plan: hmmm

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D19369
2018-04-16 12:26:29 -07:00
Austin McKinley
0bf0718fad Add isClusterDevice to Almanac query
Summary: Ref T13076. This will be used by the metric collection system to iterate over the cluster devices.

Test Plan: Created some cluster and non-cluster devices, searched and saw expected results.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T13076

Differential Revision: https://secure.phabricator.com/D19368
2018-04-16 10:05:57 -07:00
epriestley
c46be2a70b Allow Maniphest tasks to be queried by workboard Column PHID via SearchEngine
Summary:
Ref T13120. See PHI571. Fixes T5024. This adds a "View as Query" action to workboard columns, which builds a query in Maniphest that has the current query constraints plus an additional constraint to select only tasks in the specified column.

This is a normal query and can be turned into a dashboard panel, added to a menu, edited, saved as a link, etc.

Much of the complexity here is that finding tasks in a given column isn't entirely straightforward because of how board layout works: when you create a task, it isn't immediately placed in columns. It's only actually added to the "Backlog" column on any boards when someone looks at the board.

To get the right behavior, we must do "board layout" for any queried columns before we can constrain results. This isn't enormously efficient, but should be OK for reasonable boards.

Test Plan:
  - Used "View as Query" for normal columns and milestome columns, got appropriate queries in Maniphest.
  - Applied filters to the board (e.g., "Priorities: wishlist"), then used "View As Query" and had my custom filters respected.
  - Queried some large boards/columns with more than a thousand tasks, got results back within a second or so.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T5024

Differential Revision: https://secure.phabricator.com/D19366
2018-04-13 16:07:44 -07:00
epriestley
ca49fffc1b Fix the legacy "25, 50, 100, unlimited" Harbormaster log links to respect generation selection
Summary:
See PHI565. Ref T13120. Although this older log is on the chopping block (see T13088), there's some migration guidance and other complexity around just replacing it.

Until it gets replaced, make clicking the "number of lines" elements respect the current "Build Generation" setting. Prior to this change, clicking the links would lose the generation information and jump you to the most recent build generation.

Also fix some collateral damage from T13105 where we ended up with white text on a white background in some cases.

Test Plan:
  - Restarted a build to get multiple generations.
  - On each generation, clicked the various "25", "50", etc., links.
  - Saw generation and log window sizes both respected by the links.

Reviewers: amckinley

Reviewed By: amckinley

Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam

Maniphest Tasks: T13120

Differential Revision: https://secure.phabricator.com/D19367
2018-04-13 11:55:44 -07:00
epriestley
6556536d06 Allow repository cluster bindings to be marked as not "writable", making them read-only
Summary:
Depends on D19356. Fixes T10883. Ref T13120.

  - Add a "writable" property to the bindings, defaulting to "true" with a nice dropdown.
  - When selecting hosts, allow callers to request a writable host.
  - If the caller wants a writable host, only return hosts if they're writable.
  - In SVN and Mercurial, we sometimes return only writable hosts when we //could// return read-only hosts, but figuring out if these request are read-only or read-write is currently tricky. Since these repositories can't really cluster yet, this shouldn't matter too much today.

Test Plan:
  - Without any config changes, viewed repositories via web UI and pushed/pulled via SSH and HTTP.
  - Made all nodes in the cluster read-only by disabling "writable", pulled and hit the web UI (worked), tried to push via SSH and HTTP (got errors about read-only).
  - Put everything back, pulled and pushed.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T10883

Differential Revision: https://secure.phabricator.com/D19357
2018-04-12 16:10:36 -07:00
epriestley
7c7e6d555b Give getAlmanacServiceURI() an "options" parameter to prepare for read-only devices
Summary:
Depends on D19355. Ref T10883. Ref T13120. Rather than adding a million parameters here, wrap the selector-parameters in an `$options`.

The next change adds a new "writable" option to support forcing selection of writable hosts.

Test Plan: Pulled and pushed via HTTP and SSH, viewed repositories via Diffusion.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T10883

Differential Revision: https://secure.phabricator.com/D19356
2018-04-12 16:10:12 -07:00
epriestley
6f810d7813 Turn the "closed" property on cluster repositories into a nice boolean
Summary:
Ref T10883. Ref T13120. There's an existing "closed" property on repository services that stops new repositories from being allocated there.

Turn it into a nice boolean.

Test Plan: Toggled the value on/off using a nice `<select />` with helpful labels instead of a text area.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T10883

Differential Revision: https://secure.phabricator.com/D19355
2018-04-12 16:09:32 -07:00
epriestley
4068aaef61 Toggle revision "shouldBroadcast" correctly when "--draft" is used with prototypes off
Summary:
See PHI573. Ref T13120. Drafts were recently changed so that "draft" and "broadcast" are separate flags, and you can have non-broadcasting revisions in states other than "draft" if builds fail on a draft or you abandon a draft.

However, when draft mode is entered with `arc diff --draft` and you have prototypes off, this flag wasn't being set correctly.

Test Plan: Disabled prototypes, created a revision with `arc diff --draft`, observed that `draft.broadcast` is now correctly `false`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120

Differential Revision: https://secure.phabricator.com/D19360
2018-04-12 16:08:43 -07:00
epriestley
c52e10d1ec Respect external unmentionable PHIDs in Differential revision editor
Summary:
See PHI574. Ref T13120. When you `Ref Txx` or `Fixes Txxx`, we mark it "unmentionable" to prevent the task from generating both a reference and a mention.

If you add a reference to an object (like a commit hash) to a custom remarkup field, there's currently no real way to prevent it from generating a mention, except that you can explicitly mark the PHID as unmentionable on the Editor.

This isn't exactly a first-class feature, but we technically do it in `PhabricatorRepositoryCommitMessageParserWorker`, and it probably doesn't hurt or interfere with anything to support it slightly better.

In Differential, respect any existing value and append new values to it rather than overwriting the value.

Test Plan: Edited a revision summary to include `Ref Txxx`, saw only a reference (not a mention) generate.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120

Differential Revision: https://secure.phabricator.com/D19361
2018-04-12 16:07:55 -07:00
epriestley
70056a9072 When creating a file by downloading a URI, truncate the length of the default name
Summary:
See <https://discourse.phabricator-community.org/t/embedding-external-images-url-show-error-for-long-urls/1339>.

When we download a file from a URI, we provide a default name based on the URI. However, if the URI is something like `http://example.com/very-very-very-....-long.jpg` with more than 255 characters, we may suggest a name which won't fit into the `name` column of `PhabricatorFile`.

Instead, suggest a default name no longer than 64 bytes.

Test Plan:
  - Used the `{image ...}` example from the Discourse report locally; got an image with a truncated name.
  - Used a normal `{image ...}`, got an image file with a normal name.

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D19353
2018-04-12 13:29:53 -07:00
epriestley
37a03402bc When following a link to a particular line ("/example.txt$12"), scroll to that line
Summary:
Depends on D19349. Ref T13105. This was the behavior in Diffusion before with a little hard-coded snippet.

Remove that snippet ("diffusion-jump-to") and add a more general-purpose snippet to SourceView.

This is a tiny bit hacky still (and probably doesn't work quite right with Quicksand) but gets things working again and works in all of Files, Paste, and Diffusion.

Test Plan: Followed links to particular lines in Paste, Files and Diffusion; got scrolled to the right place.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13105

Differential Revision: https://secure.phabricator.com/D19350
2018-04-11 17:29:22 -07:00
epriestley
5b3a351852 Use pseudoelements, not Zero Width Space, to implement copy/paste behavior in Paste/Diffusion
Summary:
Depends on D19348. Ref T13105. When copying text from Paste or Diffusion, we'd like to copy only source, not line numbers.

We currently accomplish this with zero-width spaces plus a trigger that fires on "copy" in Paste and Diffusion. This is quite gross.

In the new-style Harbormaster logs, we use an approach that seems slightly better: CSS psuedoelements.

This isn't a complete solution (see also PHI504 / T5032) but puts us in a slightly better place.

Use it in Paste/Files/Diffusion too.

This gives us good behavior in all browsers in Files and Paste.

This gives us good behavior in Chrome and Firefox in Diffusion. Safari will copy (but not visually select) blame information in Diffusion. I think we can live with that for now.

Test Plan: Selected and copy/pasted stuff in Diffusion, Files, and Paste. Got good behavior everywhere except Safari + Diffusion.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13105

Differential Revision: https://secure.phabricator.com/D19349
2018-04-11 17:28:46 -07:00
epriestley
c5c53e277a Make line selection in source code views less fragile and more consistent
Summary:
Depends on D19347. Ref T13105. See PHI565. The "highlight lines" behavior is interacting poorly with the new blame element in Diffusion.

Make the behavior a little simpler and hopefully more robust.

Test Plan:
  - Clicked commit/revision links in Diffusion, saw the links get followed instead of the lines highlighted.
  - Highlighted lines in Diffusion, saw just the line/code highlight instead of the whole thing.
  - Highlighted lines in Paste and new-style Harbormaster build logs, saw consistent behavior.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13105

Differential Revision: https://secure.phabricator.com/D19348
2018-04-11 17:27:34 -07:00
epriestley
ac570fd4bc When you make the file tree huge, scroll to the right, and then toggle it, stop it from growing
Summary: Depends on D19346. Ref PHI568. I love Javascript.

Test Plan:
  - Viewed a revision.
  - Dragged file tree view really wide.
  - Scrolled document to the right.
  - Toggled file tree off and on by pressing "f" twice.
    - Before patch: file tree grew wider and wider after it was toggled.
    - After patch: file tree stayed the same size after it was toggled.
  - Dragged to various widths and reloaded to make sure the "sticky across reloads" behavior still works.
  - Scrolled right, dragged the tree a bit, then reloaded and didn't see it flip out.

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D19347
2018-04-11 17:25:31 -07:00
epriestley
55619e8964 Restore an explicit white background color to files in Paste
Summary:
Ref T13105. Previously, the "source code" view in Paste rendered on a brown/orange-ish background. I've been using this element in more contexts (Files, Diffusion) and removed the colored background to make text (particularly syntax-highlighted text) easier to read and reduce visual noise with the new blame colors.

In Diffusion the view is in a box with a white background so removing the background left us with white, but in Paste it's just directly on the page so the background was bleeding through. Instead, set it to white explicitly.

Test Plan: Viewed source files in Files, Diffusion and Paste; saw text on a white background.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13105

Differential Revision: https://secure.phabricator.com/D19346
2018-04-11 17:21:33 -07:00
epriestley
d6ef32a7b7 Give the "Filetree" UI element an explicit background color
Summary:
See PHI568. If you make the file tree UI very wide so that the page generates a horizontal scrollbar and then scroll the page, the page content can paint underneath the menu.

The menu already has a z-index to make it render above the content, but doesn't actually have a background. Give it a background.

The "transparent" rule was added in D16346 but I don't see any reason why we actually need it there, so I think this probably won't break anything.

Test Plan: {F5518822}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120

Differential Revision: https://secure.phabricator.com/D19344
2018-04-11 10:42:41 -07:00
epriestley
ea9187ea92 Allow Almanac properties to be set and deleted via Conduit
Summary:
Depends on D19342. Ref T12414. Ref T13120. This adds an EditEngine extension for editing Almanac properties.

The actual wire format is a little weird. Normally, we'd have a transaction for each property, but since you can pick any property names you want we can't really do that (we'd have to generate infinite transactions).

The transaction wire format anticipates that transactions may eventually get some kind of metadata -- each transaction looks like this:

```
{
  "type": "title",
  "value": "Example title"
}
```

...and we can add more keys there. For example, I could have made this transaction look like this:

```
{
  "type": "property.set",
  "almanac.property.key": "some-key",
  "value": "some-value"
}
```

However, I don't want to just accept any possible key freely, and it might be a decent chunk of work to formalize this better. It also doesn't feel great.

I just built special transaction types intead, so you:

```
{
  "type": "property.set",
  "value": {
   "some-key": "some-value",
   ...
  }
}
```

Internally, we may generate more than one transaction as a result (if the "value" has more than one key).

This feels a bit more natural and is probably easier for clients to use anyway.

Test Plan: Set and deleted Service, Device and Binding properties via the API.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19343
2018-04-11 10:42:10 -07:00
epriestley
c1558031c2 Make various small quality-of-life improvements for Almanac properties
Summary:
Depends on D19341. Ref T12414. Ref T13120.

  - Fix a bug where default-valued properties didn't get rendered in grey as they're supposed to (as a hint that the value isn't customized).
  - When resetting a builtin property won't do anything, visually disable the button as a hint.
  - Allow Services to specify properties on their Bindings.
  - Specify that repository bindings have a "protocol" property, so it becomes an explicit thing in the UI. Previously, you had to read the documentation to figure this out.
  - When editing bindings, use the EditField and its configuration if possible. This turns the "Protocol" property into a dropdown in the UI where you select between "http", "https" and "ssh".
  - Give the "protocol" binding a smart default based on the port number of the corresponding interface.

Test Plan:
  - Viewed properties on Services, Devices and Bindings.
  - Saw them render sensibly, and grey out + grey button when a builtin value has a default setting.
  - Saw "Protocol" appear as a default property on repository cluster bindings and get a smart value.
  - Edited "protocol", got a nice dropdown.

{F5518791}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19342
2018-04-11 10:38:41 -07:00
epriestley
d56a37b636 Allow Almanac Bindings to be enabled/disabled via API and support the "properties" attachment
Summary:
Depends on D19340. Ref T12414. Ref T13120. See T12414 for some discussion about direction here.

Since I think retaining "enabled/disabled" as a simple flag is reasonable, expose it via the API for readers and writers.

Also expose binding properties.

Test Plan:
  - Searched for bindings and properties with "alamanc.binding.search".
  - Enabled and disabled bindings with "almanac.binding.edit".

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19341
2018-04-11 10:38:09 -07:00
epriestley
208504a5e3 Provide "almanac.binding.search" and "almanac.binding.edit"
Summary:
Depends on D19338. Ref T13120. Ref T12414. These are the last of the new API methods.

This stuff still doesn't work:

  - You can't actually enable/disable bindings yet. I want to take a look at the use cases and consider changing "disabled" to "status", or providing a different way to solve the problem.
  - You can't edit properties via the API. I expect to enable this for all `AlmanacPropertyInterface` objects with an extension in a future change.

Test Plan:
  - Searched for bindings via API.
  - Viewed binding web UI for API methods.
  - Created bindings via API.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19340
2018-04-11 10:37:38 -07:00
epriestley
e502df509d Implement "almanac.interface.search" and "almanac.interface.edit"
Summary: Depends on D19337. Ref T13120. Ref T12414. These are slightly more substantive than namespace/network, but pretty much standard fare.

Test Plan:
  - Searched for interfaces with "almanac.interface.search".
  - Created and edited interfaces with "almanac.interface.edit".
  - Created and edited interfaces with web UI since some stuff got tweaked.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19338
2018-04-11 10:35:03 -07:00
epriestley
10947c8684 Add "almanac.namespace.edit" and "almanac.namespace.search" API methods
Summary: Depends on D19336. Ref T13120. Ref T12414. These are simple, straightforward, and uninteresting.

Test Plan:
  - Searched for namespaces with "almanac.namespace.search".
  - Created and edited namespaces with "almanac.namespace.edit".

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19337
2018-04-11 10:34:30 -07:00
epriestley
9022e14082 Use a more conventional spelling of "Almanac" for "almanac.service.edit" class
Summary: Depends on D19335. Ref T13120. Ref T12414. There are many good ways to spell "almanac", but stick with convention here.

Test Plan: (O_O)

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19336
2018-04-11 10:34:04 -07:00
epriestley
a8c4da13c0 Add "almanac.network.edit" and "almanac.network.search" API methods
Summary: Depends on D19334. Ref T13120. Ref T12414. These are pretty straightforward, but no one really has a use case for them anyway today so they're primarily just for completeness.

Test Plan:
  - Queried networks with `almanac.network.search`.
  - Created and edited networks with `almanac.network.edit`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19335
2018-04-11 10:33:41 -07:00
epriestley
4bce3fc8e6 Modularize Almanac property transactions
Summary:
Depends on D19329. Ref T13120. Ref T12414. Recent changes have mostly modularized Almanac transactions, but the "property" transactions remained written in an older style with the logic on the Editor/Transaction classes.

This moves them to modern modular transactions. These end up being a little bit copy-pastey, but it doesn't feel too terribly bad.

Test Plan: Created, edited, and deleted properties on services, devices and bindings. Grepped for removed constants.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19334
2018-04-11 10:33:18 -07:00
epriestley
71c77fcc3a Modularize transactions for Almanac Device
Summary:
Depends on D19328. Ref T13120. Ref T12414.

Prior work has left us with just a NAME transaction here, which is straightforward to modularize.

Test Plan:
  - Created and renamed devices.
  - Tried to set no name, a bad name, a duplicate name (got errors).
  - Tried to create/rename into a namespace I could not edit (got an error).
  - Grepped for `AlmanacDeviceTransaction::`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19329
2018-04-11 10:31:46 -07:00
epriestley
4e156a0385 Remove TYPE_INTERFACE transaction from Almanac Device
Summary:
Depends on D19325. Ref T13120. Ref T12414.

This no longer has any callers in the upstream or in Phacility support libraries, so get rid of it.

This will make modularizing Device transactions significantly easier, since the other transactions are reasonable, normal sorts of transactions.

For existing devices, this leaves some "author edited this object." transactions in the log. I might just leave those since they aren't really hurting anything, or maybe I'll clean them up or hide them later once I have more confidence that these changes are stable.

Test Plan: Grepped for `TYPE_INTERFACE` and `AlmanacDeviceTransaction`, found no callsites.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19328
2018-04-11 10:31:25 -07:00
epriestley
d240969e47 Use Interface transactions, not Device transactions, to destroy Interfaces
Summary:
Depends on D19324. Ref T13120. Ref T12414.

This moves "Destroy Interface" to use Interface transactions instead of Device transactions, so we can ultimately get rid of the complex and difficult-to-modernize `AlmanacDeviceTransaction::TYPE_INTERFACE`.

This transaction is a bit weird since it makes the interface delete itself, but this should work OK for now. At some point in the future I'd probably want to change this into more of a "disable" action, but I don't think we face any immediate peril by retaining this behavior for now.

Test Plan:
  - Destroyed interfaces on devices using the web UI, saw them vanish.
  - Ran daemons, nothing fataled/exploded even though the transaction is weird and destroys the object it affects.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19325
2018-04-11 10:30:15 -07:00
epriestley
6ccf35f9a2 Edit Interfaces in Almanac with EditEngine
Summary:
Depends on D19323. Ref T13120. Ref T12414.

Move editing to modern stuff and fix some implementation errors from D19323 (mostly copy/paste stuff).

Test Plan:
  - Created and edited interfaces.
  - Tried to create/edit an interface with a bogus/empty address/port, got errors.
  - Tried to create an interface on a bogus device, got an error.
  - Tried to create an interface on a device I could not edit, got an error.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19324
2018-04-11 10:29:50 -07:00
epriestley
f9c6a69d9c Add skeleton code for Almanac Interfaces to have real transactions
Summary:
Depends on D19322. Ref T13120. Ref T12414.

Currently, `AlmanacDevice` has a bit of a beast of a `TYPE_INTERFACE` transaction that fully creates a complex Interface object. This isn't very flexible or consistent, and Interfaces are complex enough to reasonably have their own object behaviors (for example, they have their own PHIDs).

The complexity of this transaction makes modularizing `AlmanacDevice` transactions tricky. To simplify this, move Interface toward having its own set of normal transactions.

This change just adds some reasonable-looking transactions; it doesn't actually hook them up in the UI or make them reachable. I'll test that they actually work as I swap the UI over.

We may also have some code using the `TYPE_INTERFACE` transaction in Phacility support stuff, so that may need to wait a week to actually phase out.

Test Plan: Ran `bin/storage upgrade` and `arc liberate`. This code isn't reachable yet.

Reviewers: amckinley

Reviewed By: amckinley

Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19323
2018-04-11 10:29:26 -07:00
epriestley
580409b562 Modularize Almanac Network transactions
Summary: Depends on D19321. Ref T13120. Ref T12414. Move transactions for Almanac Networks (just "name") to ModularTransactions.

Test Plan:
  - Created a new network.
  - Renamed a network.
  - Tried to create a network with no name (got an error).
  - Grepped for `AlmanacNetworkTransaction::`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19322
2018-04-11 10:29:05 -07:00
epriestley
f62494355d Modularize Almanac Binding transactions
Summary: Depends on D19320. Ref T13120. Ref T12414. Move transactions for Almanac Bindings to ModularTransactions.

Test Plan:
  - Created a new binding.
  - Tried to create a duplicate binding, got an error.
  - Edited a binding to rebind it to a different device.
  - Disabled and enabled bindings.
  - Grepped for `AlmanacBindingTransaction::` constants.

When a binding is created, it currently renders a bad "changed the interface from ??? to X" transaction. This is because creation isn't currently using EditEngine. I plan to swap it shortly, which will turn this into a real "Create" transaction and fix the issue.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19321
2018-04-11 10:28:42 -07:00
epriestley
5ada1211cd Modularize Almanac Namespace transactions
Summary: Depends on D19318. Ref T13120. Ref T12414. Move transactions for Almanac Namespaces ("name" is the only meaningful one) to ModularTransactions.

Test Plan:
  - Created a new namespace.
  - Edited a namespace.
  - Tried to choose no name, an invalid name, a duplicate name, and a name in a namespace I can't edit; got appropriate errors.
  - Grepped for `AlmanacNamespaceTransaction::TYPE_NAME`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19320
2018-04-11 10:24:10 -07:00
epriestley
6983479e4f Allow "almanac.service.edit" to create services
Summary:
Depends on D19317. Ref T13120. Ref T12414. See PHI145. See PHI473.

This adds a Conduit-only "type" transaction for Almanac services. This is very similar to the approach in D18849 for Drydock blueprints.

Test Plan:
  - Tried to create an empty service via "almanac.service.edit", was told to pick a type.
  - Tried to pick a bad type, was told to pick a good type.
  - Created a new Almanac service via "almanac.service.edit".
  - Tried to edit the service to change the type, wasn't allowed to.
  - Created and edited via the web UI, nothing changed from before.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13120, T12414

Differential Revision: https://secure.phabricator.com/D19318
2018-04-11 10:23:50 -07:00