Revisions and Commits
HarbormasterBuildStepCoreCustomField emits no fields if a BuildStep has no attached Implementation object. This dates from D15352 and is conceptually reasonable ("don't crash if a build step exists but the implementation no longer does") but should probably be represented differently (e.g., an explicit "InvalidImplementation").
By default, BuildStepQuery does not build or attach Implementation objects; instead, they are built and attached on-demand. This isn't a problem in and of itself.
Here, ApplicationSearchEngine does not include PhabricatorCustomFieldSearchEngineExtension in the list of BuildStep extensions because BuildStep does not expose any searchable fields. This is incorrect: it should be permissible for an object to have searchable fields only (although this would be a bit unusual), or result fields only, or both.
This partly occurs because a "generic" BuildStep (with no specific implementation) has no custom fields.
This is entangled with T13248 and only directly impacts the ability to return results from harbormaster.buildstep.search, which I can plausibly cheat my way through instead, perhaps.
- There is no way to pull custom field values with *.search. See above.
- There is no way to edit non-custom field values with *.edit. The underlying transactions haven't been modularized yet; they should be, then EditEngine should get appropriate EditField definitions.
- There's no way to identify which custom fields can be edited. This overlaps with T13248, but is also a Conduit API Console UI problem. The web UI should have some way to inspect parameter variations per object subtype for available subtypes.
- As a workaround, you can try to edit an invalid field. The error message will identify valid fields.
- There's no way to create steps with *.edit because you can't specify a step type. See T13449 for a general variation of the "type is required to initialize objects" problem.