Page MenuHomePhabricator

Make bulk edit <select /> fields a little more natrual and set options for subtype transactions
ClosedPublic

Authored by epriestley on Jan 19 2018, 2:57 PM.
Tags
None
Referenced Files
F15524389: D18878.id45289.diff
Mon, Apr 21, 7:43 AM
F15521059: D18878.id45270.diff
Sun, Apr 20, 10:45 AM
F15516989: D18878.diff
Fri, Apr 18, 10:52 PM
F15504394: D18878.id.diff
Mon, Apr 14, 5:39 PM
F15416597: D18878.id45270.diff
Mar 20 2025, 12:22 PM
F15403849: D18878.id.diff
Mar 18 2025, 5:06 AM
F15402907: D18878.diff
Mar 18 2025, 12:57 AM
F15332003: D18878.diff
Mar 7 2025, 3:56 PM
Subscribers
None

Details

Summary

Ref T13025. This is some minor technical stuff: make the "select" bulk edit type a little more consistent with other types by passing data down instead of having it reach up the stack. This simplifies the implementation of a custom field "select" in a future change.

Also, provide an option list to the "select" edit field for object subtypes. This is only accessible via Conduit so it currently never actually renders anything in the UI, but with the bulk edit stuff we get some initialization order issues if we don't set anything. This will also make any future changes which expose subtypes more broadly more straightforward.

Test Plan
  • Bulk edited "select" fields, like "Status" and "Priority".
  • No more fatal when trying to getOptions() internally on the subtype field.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable