Missing links to secondary admin pages

Another one:

MARC Search/Facet Fields: https://bugs.launchpad.net/evergreen/+bug/1847810

And another:

MARC Coded Value Maps: no access to composite attribute entry definitions (bug 1843969)

Marking as High priority since the cumulative effect is to make Angular admin pages difficult or impossible to use in many cases.

There's already an implicit relationship between primary and secondary admin pages in the IDL, i.e., the primary class should have a link to the secondary. Would it make sense to add a "config_field" attribute to IDL links to make the relationship explicit? Then the admin page component could check for the attribute when loading the IDL class definition; if config_field = true, it could add a link to the grid directing the user to the appropriately-filtered secondary admin page.

For example, the IDL class definition for config.z3950_source has a link to config.z3950_attr. We would add a "config_field" attribute to the link field, like so:

<field reporter:label="Attrs" name="attrs" oils_persist:virtual="true" reporter:datatype="link" config_field:"true"/>

Since we have a config_field attribute, the Z39.50 Sources grid would use the other IDL attributes
to construct a link to this URL:
/eg2/en-US/staff/admin/server/config/z3950_attr?gridFilters={"source":"oclc"}

Working branch user/jeffdavis/lp1847800-secondary-admin-pages doesn't construct that link yet, but it attempts to make the config_field IDL attribute available to Angular in order to do so:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1847800-secondary-admin-pages

Additional Server Administration pages that are missing links to secondary pages:
- Authority Control Sets
- Authority Thesauri
- Import Match Sets
- MARC Record Attributes

I have made progress building atop Jeff's config_field branch. Work in progress:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1847800-secondary-admin-pages

As it stands, the admin page for z3950_source can build a filtered link to the z3550_attr page. However, the links only allow you to open the destination page when opening the link in a new tab. This is the result of the admin page / basic admin page components not being built to handle route changes within an instance of the component. (They are not watching for route changes and re-initing themselves).

Options I'm exploring, each with little unexpected complexities:

Teach the components to watch for route changes.
Change the route reuse strategy for the admin pages to force non-reuse of components
Use a regular 'href' instead of a 'routerLink' for navigating between pages.

More later

New branch pushed with my work squashed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1847800-secondary-admin-pages-1

I opted to use regular href links to resolve the issue noted in my previous comment about component re-use. It was the least disruptive option and works fine, especially for pages where speed of navigation is not the primary concern.

I also added config_field=true values for z3950_attr => z3950_source (to cover the reverse direction) and for hard_due_date <=> hard_due_date_values.

I'm hoping whoever tests this can add the additional IDL config_field entries as needed as test those. Note that some of the bugs referenced in the bug description have been resolved via other mechanisms (custom UI's, etc. eg. Floating Groups).

Thanks, Bill! The new branch works great for me after a quick test. I've asked some other Sitka folks to test too. If all goes well, I'll work on adding more config_field entries for other affected UIs.

Working branch user/jeffdavis/lp1847800-secondary-admin-pages-1-continued has my attempts to add config_field links to some other admin pages identified in this bug. The links work, but in several cases, when trying to add a new entry on the secondary page, fm-editor fails to load.

Example 1: Server Admin > MARC Import Remove Fields > Fields > New Import/Overlay Fields for Removal fails with the following console error:

core.js:6014 ERROR Error: Uncaught (in promise): TypeError: item[selector] is not a function
TypeError: item[selector] is not a function
    at fm-editor.component.ts:422
    at Array.map (<anonymous>)
    at FmRecordEditorComponent.flattenLinkedValues (fm-editor.component.ts:421)
    at fm-editor.component.ts:560
    at ZoneDelegate.invoke (zone-evergreen.js:365)
    at Object.onInvoke (core.js:39698)
    at ZoneDelegate.invoke (zone-evergreen.js:364)
    at Zone.run (zone-evergreen.js:124)
    at zone-evergreen.js:851
    at ZoneDelegate.invokeTask (zone-evergreen.js:400)
    at resolvePromise (zone-evergreen.js:793)
    at resolvePromise (zone-evergreen.js:752)
    at zone-evergreen.js:854
    at ZoneDelegate.invokeTask (zone-evergreen.js:400)
    at Object.onInvokeTask (core.js:39679)
    at ZoneDelegate.invokeTask (zone-evergreen.js:399)
    at Zone.runTask (zone-evergreen.js:168)
    at drainMicroTaskQueue (zone-evergreen.js:570)
    at ZoneTask.invokeTask [as invoke] (zone-evergreen.js:485)
    at invokeTask (zone-evergreen.js:1596)

Example 2: Server Admin > Authority Control Sets > Controlling Authority Fields > New Authority Control Set Authority Field fails with a slightly different console error:

core.js:6014 ERROR TypeError: Cannot read property 'pkey' of undefined
    at PcrudContext.retrieveAll (pcrud.service.ts:157)
    at PcrudService.retrieveAll (pcrud.service.ts:343)
    at FmRecordEditorComponent.wireUpCombobox (fm-editor.component.ts:557)
    at FmRecordEditorComponent.constructOneField (fm-editor.component.ts:518)
    at fm-editor.component.ts:433
    at Array.map (<anonymous>)
    at FmRecordEditorComponent.getFieldList (fm-editor.component.ts:433)
    at FmRecordEditorComponent.initRecord (fm-editor.component.ts:374)
    at fm-editor.component.ts:260
    at SafeSubscriber.schedulerFn [as _next] (core.js:35378)

There are also a couple of minor usability issues:

- Pages should indicate when gridFilters are applied, so that it's clear to the user that you're looking at a specific subset of entries. For example, the old hard due date UI had a header which read "Showing only hard due date values related to hard due date object X".

- When creating a new entry from a page where gridFilters are applied, it would be nice if fm-editor pre-selected values based on those filters. For example, if you go to Server Admin > Z39.50 Servers, click the Attrs link for oclc, and then click "New Z39.50 Attribute", the fm-editor dialog should automatically select "oclc" as the Z39.50 Source.

I intend to keep poking at this, but if anyone else wants to take a look in the meantime, please feel free.

Thanks, Jeff. I'm looking at some these now...

New branch pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1847800-secondary-admin-pages-2

This addresses all of the issues noted in Jeff's previous comment.

In addition to indicating filters are applied, I added a "Clear Filters" link to remove the filters. As for filter display, I did not make it quite as friendly as the example, it's just showing the filter values. Staff will see something like this:

Filters Applied: { "source": "oclc" } Clear Filters

Less friendly, but I think still conveys the information needed (and offers a way to clear it).

A small nit, and not critical to the feature per se, but do we want to update the stylesheet used to verify the structure of the IDL?

Thanks, Mike. Jeff added the config_field attribute to the XSD in one his early commits:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=fc325883040c55d54fc69cb98781d7568e766ffc;hp=d338486c851339b65ebe42c6ecc245774098d2b7#patch2

Works for me! Pushed to master and rel_3_5. Can probably be backported to 3.4 on a site-by-site basis, but decided not to push it to rel_3_4 since there were code conflicts. (Happy to sign off on a 3.4 fix if someone wants to work one up)

3.4 branch pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1847800-secondary-admin-pages-3.4

It's a combo of signed off commits from master w/ minor merge conflict repairs and an extra commit that back-ports the "defaultNewRecord" functionality for 3.4.

Pushed to rel_3_4. Thanks, Bill!