Time for an additional Angular OU select component for forms

[Galen Charlton]

While poking at bug 1838784, including making an attempt at implementing ControlValueAccessor for eg-org-select, I think it's time to consider creating an additional component to select an organization unit _in the context of a form_, including eg-edit-fm-record.

Broadly speaking, I see two different primary uses of the current eg-org-select:

- As a _selector_, where you chose an OU and something either happens right away or when you press another button. These include the selectors used to filter a grid.
- As part of a form where the OU is a field in a record.

eg-org-select has been trying to fulfill both broad use cases, but since it has accreted functionality over the years, its current form has rather complicated startup logic, including different ways of specifying an initial value, a persist key that can override any initial value supplied to the control in other ways, and multiple ways of conveying whether a value has been chosen. As a consequence, my attempt to implement ControlValueAccessor only partially succeeded.

For example, eg-org-select's persistKey will override the value coming in from the form - in fact, this is _already_ a problem with the statistical category admin forms, where once you save a stat cat, the OU you happened to use will be displayed as the owner for any other stat cat you edit regardless of the stat cat's actual owner.

In order the get to the point where we have an Angular OU selection component that plays well with forms (and NgForm in particularly), I propose to create a new component that's _just_ for the forms use case. Let's call it eg-form-org-select for the purpose of argument.

Here's the characteristics that I imagine eg-form-org-select would have:

- data access is _only_ through ngModel / ngModelChange
- its value can be cleared (assuming that the field it provides a value form is not required) and will return "null" to the model in that case. (Note that eg-org-select values down here; you can clear it, but if you tab out of the input, it will then apply the OU root)
- it is not responsible for providing its own default value when used in a form to create a new record; the controlling form should set its default value if desired (i.e., the workstation OU, a value set in a persist key, or some other value that makes sense in context). Doing this would _greatly_ simplify the startup logic over eg-org-select.
- it can handle both aou IdlObject's and OU ID values transparently
- it can optionally provide a default value (either the workstation OU, an OU explicitly passed from a controlling component, or a value set in a persist key), but _only_ in the context where a new record is to be created
- its display would be identical to eg-org-select's

Input attributes it would have would include:

- disabled
- placeholder
- ariaLabel
- domId
- name
- displayField (with same meaning as eg-org-select)
- readOnly
- required
- limitPerms
- orgClassCallback (maybe)
- hideOrg (maybe - would be needed to allow the new selector to be used in the holdings editor)

Inputs from eg-org-select that I hope _not_ to bring over include

- disabledOrgs (hoping that limitPerms will suffice)
- initialOrg / initialOrgId / fallbackOrg / fallbackOrgId / persistKey (the form that uses it is responsible for supplying any desired default value)
- applyOrg / applyOrgId / onChange / selectedOrg / selectedOrgId (data access is _only_ through ngModel)
- componentLoaded (because hopefully the initialization will be much simpler and the containing forms will not need to care)

The notion would be to end up with something that is _solid_ for the forms use case, including cooperating with form validation. That would leave eg-org-select for the select-an-OU-then-do-something use case.

Once a forms-optimized OU selector exists, I could imagine a desire to either further simplify eg-org-select (since it would no longer need to concern itself with the forms use case) or to otherwise reunify the selectors. However, one step at a time - I think eg-org-select's current state is more complicated than it needs to be.

[Galen Charlton (gmc)]

The branch working/user/gmcharlt/lp2054233_eg-form-org-select-wip has my WIP. Thus far, looking good for making it possible to mark an OU field as required in an FM editor form.

Noting that it's possible that I may end up working my way towards figuring out that eg-org-select can be modified to support CVA and behave fully properly in forms - though if so, at minimum persistKey's behavior would have to change.