Angular staff catalog continued (cira 3.2)

[Bill Erickson]

Evergreen 3.2

As part of the initial AngularJS => Angular development cycle, I ported a large chunk of catalog functionality from the TPAC to Angular, with the goal (apart from learning Angular) of eventually replacing the TPAC iframe in the browser client with a native Angular interface.

The existing UI can be found on 3.2+ servers at: https://HOSTNAME/eg2/staff/catalog

I'm opening this card so we can discuss future plans and to track some additional development I have done on the Angular staff catalog in the meantime.

My working branch (unsquashed) is here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/ang-staff-catalog-continued

(Will rename branch once I have a bug number).

Additional work done so far includes:

* Record detail "Holds" and "MARC Edit" tabs redirect to AngJS UI.
* Record detail monograph part tab ported to Angular
* Basket selectors, basket page, and basket actions
* Place holds UI (see TODO's below)

Known TODO items (there are certainly more):

* Redirect to AngJS for "Holdings View" and "Conjoined Items"
* Copy location search filter
* Place holds advanced hold options
* Place holds UI patron search
* Group formats and editions

For now, I'm focused mainly on port functionality over as-is (with some usability improvements) so that the Angular catalog can be usable by staff sooner than later. My hope is we can accomplish enough in the 3.3 development cycle that we can provide an entry point to the Angular catalog for sites that want to start beta testing the new UI in production.

I plan to address the first 2 TODO items above soon, and possibly #3. The others are considerably more involved, so their future is unclear at the moment.

[Blake GH (bmagic)]

We are excited to see this new catalog look and feel. We are interested in seeing more on this! Do I remember that this method would remove the current tt2 override paradigm? Thanks Bill.

[Bill Erickson (berick)]

That's right, Blake. It's a pure Angular UI, so there are no TT templates or any concept of Template Toolkit overrides.

Given that this is a staff-only interface -- it's not a TPAC replacement -- can you give some examples of org-specific overrides you might want to implement?

My assumption so far has been they are not critical for a staff-only UI. As we consider priority and alternatives, we should also consider whether we need to place a higher value on consistency (over customization) for staff-only interfaces.

Thoughts appreciated.

[Bill Erickson (berick)]

New branch pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1806087-ang-staff-cat-phase2

Includes redirects for Holdings View and Conjoined Items, support for setting the default record detail tab, and copy location search filter.

[Bill Erickson (berick)]

Other TODO items:

pub date search filter
basket entry sorting
MARC search
browse UI

[Bill Erickson (berick)]

More TODO:

Search Highlighting

[Jane Sandberg (sandbergja)]

One quick note: it's important for catalogers to check how a record displays in the OPAC. I don't think that that an OPAC view needs to be embedded into the record view, but there should be at least a big obvious link to view the record in the OPAC from the Angular record view.

[Bill Erickson (berick)]

Thanks, Jane. Totally agree. I've added a View in Catalog button to the working branch.

[Bill Erickson (berick)]

As promised, here's a wiki page that summarizes the current state of the project:

https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angular_staff_catalog

[Bill Erickson (berick)]

Cleaned up branch pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1806087-ang-staff-cat-phase2-squash-1

Includes:

1. Catalog changes consistent with the above-noted wiki page.
2. Org setting to enable the catalog for review and testing
3. Release notes detailing code changes since 3.2.

Highlights:

* Record detail tabs redirect to AngJS catalog where needed.
* Initial holds placement UI.
* Record baskets, actions, and UI.
* Ported MonographParts tab to Angular
* Set default catalog tab
* Browse
* MARC search
* Identifier search
* pub date filter
* Record detail 'View in Catalog' button
* Group formats and editions

Adding pullrequest for additional eyes, testing, and hopefully 3.3 merge.

[Bill Erickson (berick)]

Branch rebased to master post-Ang7, Ang7 patches applied, plus a pile of ng-lint updates I missed before.

[Kyle Huckins (khuckins)]

I've pushed a collab branch based on the above squashed branch with some improvements to the Place Holds UI: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/khuckins/lp1806087-and-staff-cat-phase2

* SMS Carriers dropdown is now disabled if Notify by SMS is unchecked
* The Search button by the user barcode input has been moved up to the h3 tag's level, and expanded to "Search for Patron" to better differentiate the two existing search buttons on the screen. An icon has also been added.
* A Submit button has been appended to the barcode input to better work around user expectations of functionality.

In testing this, I haven't noticed any other issues with the new Catalog UI so far

[Bill Erickson (berick)]

Testing Kyle's patch and rebasing to master...

[Bill Erickson (berick)]

Force-pushed back to:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1806087-ang-staff-cat-phase2-squash-1

1. Sign-off for Kyle's patch (thanks, Kyle)
2. Rebased to master including merge conflict repair in bucket dialog (queue vs. bib ids)

[Dan Wells (dbw2)]

Gave this some testing time, and overall, it looks and works very well. Given that it is "experimental", I have pushed it to master to make feature cutoff, but I think it needs at least a couple fix-ups. To avoid possible coordination issues at this stage, I am leaving the bug open to possibly handle things here, at least through 3.3.0. Here are a few issues:

1) If the user has a "default" tab which is not implemented in the new interface, e.g. "Holdings View", the back button is broken due to the auto-forward. A simple solution would be to perhaps land on the tab with a "This interface is not yet implemented" note plus a manual link for jumping to the old interface. Thoughts?

2) Similar issue for the "edit" link on copies. You land on an Item Details page, then immediately bounce to a volume editor. This again breaks the back button. One solution might be to open this in a new tab similar to other interfaces, but avoiding the "bounce" would be even better.

3) The browse code has been duplicated for expediency, but we should look for ways to reduce or eliminate this duplication before letting this sit too long (and potentially drifting apart). There is hope for driving some of the EGCatloader code through this new Search service code as a shared back end.

All these issues aside, this seems like a great step forward. Thanks, Bill and Kyle!

Finally, I know there are concerns about how this might add an extra burden for supporting both the TPAC and this new interface. Overall, I feel like the benefits of a proper Angular catalog for the staff client are undeniable, so in some ways the real question is not whether we should add an Angular catalog, but whether the needs for a mostly-JS-free OPAC are still strong enough to keep TPAC as our primary public face.

Sincerely,
Dan

[Bill Erickson (berick)]

Thanks, Dan!

1) I think that's a swell idea.

2) The bounce here happens within the AngularJS app, so it's not easy to avoid, however opening in a new tab for now would certainly help.

3) Agreed.

Looking at these 3 issues now.

[Bill Erickson (berick)]

Patches for 1, 2, and 3 above pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1806087-post-merge-additions

[Dan Wells (dbw2)]

Thanks for taking care of this so fast, Bill. Changes look good and work fine for me. Sorry for not seeing this sooner!

I've pushed this to master, but not in time for beta1. I am going to mark as fixed committed for beta1, though, since that is were *most* of it is, and will also try not to make bad plans about keeping bugs open when commits might span milestones.