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

12 commits

Author SHA1 Message Date
Joshua Spence
af1b586990 Fix method visibilities
Summary: See also D13186.

Test Plan: Ran `arc unit --everything`

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D13201
2015-06-09 07:17:44 +10:00
epriestley
bf87976d25 Support ordering in SearchField
Summary:
Ref T8441. Ref T7715. Automatically generate a modern "Order" control in ApplicationSearch for engines which fully support SearchField.

Notably, this allows the standard "Order" control to automatically support custom field orders. We do this in Maniphest today, but in an ad-hoc way.

Test Plan: Performed order-by queries in Almanac (Services), Pholio, Files, People, Projects, and Paste.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7715, T8441

Differential Revision: https://secure.phabricator.com/D13193
2015-06-08 12:21:48 -07:00
epriestley
55e49d7e31 Provide more buildXClause() and buildXClauseParts() on PolicyAwareQuery
Summary:
Ref T4100. Ref T5595. These functions are trivial for now, but move us toward being able to define more default query behavior by default.

Future changes will give these methods meaningful, nontrivial behaviors.

Test Plan: `arc unit --everything`

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5595, T4100

Differential Revision: https://secure.phabricator.com/D12454
2015-04-20 10:06:10 -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
9437414f17 Improve browsability of Almanac service datasource query
Summary: Ref T5750. Update the Almanac service query to be browsable.

Test Plan:
  - Browsed and reordered Diffusion.
  - Browsed and reordered services in Almanac.

{F373735}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5750

Differential Revision: https://secure.phabricator.com/D12433
2015-04-17 11:06:57 -07:00
epriestley
e0f4e19c3f Add an Almanac service typeahead datasource
Summary: Ref T5833. Ref T6238. This will probably be useful somewhere in the upstream eventually, and is materially useful in the Instances application right now.

Test Plan: tippy typey typey

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6238, T5833

Differential Revision: https://secure.phabricator.com/D11016
2014-12-19 12:36:14 -08:00
epriestley
d2df3064bc Allow Almanac services to be locked
Summary:
Fixes T6741. This allows Almanac services to be locked from the CLI. Locked services (and their bindings, interfaces and devices) can not be edited. This serves two similar use cases:

  - For normal installs, you can protect cluster configuration from an attacker who compromises an account (or generally harden services which are intended to be difficult to edit).
  - For Phacility, we can lock externally-managed instance cluster configuration without having to pull any spooky tricks.

Test Plan:
  - Locked and unlocked services.
  - Verified locking a service locks connected properties, bindings, binding properties, interfaces, devices, and device properties.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6741

Differential Revision: https://secure.phabricator.com/D11006
2014-12-18 14:31:36 -08:00
epriestley
c85327ca3e Give AlmanacServices a service type
Summary:
Ref T5833. This allows services to be typed, to distinguish between different kinds of services. This makes a few things easier:

  - It's easier for clients to select the services they're interested in (see note in T5873 about Phacility). This isn't a full-power solution, but gets is some of the way there.
  - It's easier to set appropriate permissions around when modifications to the Phabricator cluster are allowed. These service nodes need to be demarcated as special in some way no matter what (see T6741). This also defines a new policy for users who are permitted to create services.
  - It's easier to browse/review/understand services.
  - Future diffs will allow ServiceTypes to specify more service structure (for example, default properties) to make it easier to configure services correctly. Instead of a free-for-all, you'll get a useful list of things that consumers of the service expect to read.

The "custom" service type allows unstructured/freeform services to be created.

Test Plan:
  - Created a new service (and hit error cases).
  - Edited an existing service.
  - Saw service types on list and detail views.
  - Poked around new permission stuff.
  - Ran `almanac.queryservices` with service class specification.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10995
2014-12-17 11:10:27 -08:00
epriestley
4505724cc4 Allow repositories to be bound to an AlmanacService
Summary:
Ref T2783. This is primarily exploratory and just figuring out what we're blocked on:

  - Allow a Repository to be bound to a Service. The Service may eventually define multiple read/write nodes, etc.
    - There's no UI to do this binding yet, you have to touch the database manually.
  - If a repository is bound to a Service, effect Conduit calls via calls to the remote service instead of executing them in-process.
    - These don't actually work yet since there's no authentication (see T5955).

Test Plan:
  - Made a nice Service with a nice Binding to a nice Interface on a nice Device.
  - Force-associated a repository with the service using a raw MySQL query.
  - Saw Phabricator try to make a remote call to the service (on localhost) and fail because of missing auth stuff.
  - Also ran `almanac.queryservices`.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2783

Differential Revision: https://secure.phabricator.com/D10982
2014-12-12 12:07:11 -08:00
epriestley
fcad9435ea Allow Almanac Devices and Bindings to have properties
Summary:
Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings.

  - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc.
  - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc.

Test Plan: Added properties to Devices and Bindings.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10781
2014-11-05 15:28:36 -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
796921021b Build AlmanacService
Summary: Ref T5833. See that task for functional goals and some discussion of design.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 05:01:57 -07:00