Angularize the patron editor

[Kathy Lussier]

There are many Dojo interfaces in the staff client that will need to be redone in AngularJS. In our opinion, the patron registration form/editor is the most critical since it is a high-use interface that staff often use while working with patrons.

MassLNC has contracted with Bill Erickson to move the patron editor the Angular. We've identified the current functionality that will be moved to the Angular interface at http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:patron_editor_reqs.

[Mike Rylander (mrylander)]

Regarding point 4, should it be also added that surveys marked Required should block saving new and existing patron records until those surveys are completed? IIRC, that was the original behavior, though I'm not certain that the dojo incarnation of the patron reg/edit screen forces that.

[Chris Sharp (chrissharp123)]

The dojo incarnation does force it for required surveys, but the resulting behavior is that the survey must be answered again each time the patron is edited. This caused a problem for our voter registration survey. It would be best if the angularized version "remembers" that the survey has been answered rather than requiring a new answer every time the account is saved.

Just my 2 cents.

[Bill Erickson (berick)]

I have a work-in-progress branch at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1452950-web-client-patron-reg-wip

In its current form it's a semi-functional wire frame, with the semi-functional part being the display of various selectors and in some cases displaying the correct values. Before I go any farther, though, I wanted to bring some attention to it.

Will post a more in-depth break down after I clean some stuff up.

[Bill Erickson (berick)]

Squashed and rebased branch pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1452950-web-client-patron-reg-phase1

The goal of this branch is to get the basic structure in place and to demonstrate the layout of the form (style, inputs, buttons, etc.). As noted above, most of the inputs behave up to a point (selectors draw options, text fields show values), but no other behavior is supported yet.

I anticipate the template(s) will evolve a good bit over time, so there may still be some rough edges there.

Most if not all of the data required to run the UI (org settings, user settings, field docs, etc.) are loading at this time, so page render time of this branch should be pretty close to the final form.

Comments welcome.

[Terran McCanna (tmccanna)]

First, I want to say how happy I am about this! This form has been a thorn in my side for years. Our front-line library staff will be so happy when they are able to make the switch.

The basic structure looks great to me so far, and it loads nice and quick on our test server. I only have a few minor UI suggestions:

- I think the vertical spacing could be tightened up a bit. There's an awful lot of scrolling for this page already.
- I love the fact that the Save box floats on the page, but when editing an existing patron at 1024x768 screen resolution (which is pretty common at the libraries), the box overlaps some of the other screen elements.
- If phone example format isn't specified in the library settings editor, it would be nice if the "Example" text didn't appear on this screen next to the phone fields.
- Alert box would be better if it was larger / wrapped around / or was expandable.
- The default hold notification options wrap oddly if the browser is too narrow.

I'll be happy to assist with testing the functionality when it is ready!

[Bill Erickson (berick)]

Thanks for the excellent feedback, Terran. I've pushed a patch to address most of these. Of note is that the save / save-clone floating box now renders more vertically to save horizontal space. It helps, but I'm not 100% if it will suffice for 1024x768 display. Let me know what you think.

For the hold notification options, perhaps those should display vertically (one option per line) to avoid wrapping. The trade-off, of course, is that the form gets longer.

[Terran McCanna (tmccanna)]

Great, I'll take a look!

I would prefer having the hold notification options one per line - although it does make it a little longer, I think it's more usable because it's natural for the hand & eye to go down a list rather than go sideways on a list.

[Bill Erickson (berick)]

Consistent w/ bug #1068646, I pushed a change to re-label "billing" address to "physical" in the address type selector.

[Kathy Lussier (klussier)]

Thanks for the work you've done so far Bill! I've heard a couple more suggestions from our people:

I know you've already done some tightening in response to Terran's early feedback, but we think the vertical flow could be tightened up a bit more. Could the whitespace between elements be reduced a bit? Also, could the size of the input boxes be reduced? They seem large compared to the default font size of the labels and contribute to the amount of scrolling happening on that page.

In the current client, text entered into the input boxes is bold when entering data, and the box labels are all normal weight. In the web interface, the labels are bold and the input text is all normal weight. Having the input data in bold and the labels normal weight is preferable, since it's the data in the input boxes that should draw the user's attention rather than the labels.

It appears as if some of the labels are not lining up properly with the rest of the labels, specifically Date of Birth, Primary Identification Type, Home Library, Main (Profile) Permission Group, Privilege Expiration Date, Internet Access Level.

I also would like to give some further thought to the display of the floating "Save" and "Save & Clone" region, but I'll post my questions to the general list where they can get more attention.

Thanks again!
Kathy

[Kathy Lussier (klussier)]

Adding a comment regarding the hold notification options. I'm not seeing the odd wrapping that Terran noted in her comments.

I created a screencast where I resize my window to see how these fields wrap. As the screen gets smaller, the inputs move below the labels. If it gets even smaller, the three options for hold notification methods move from three-on-one-line to one-per-line.

https://drive.google.com/file/d/0B74gDMUDwDXqQXdfam1GRmpOM1E/edit?usp=drivesdk

Are you seeing different Terran or am I looking in the wrong place?

Thanks!
Kathy

[Kathy Lussier (klussier)]

I have one other style request to make on the new form. The "Patron Edit" text at the top of the screen should match the style of the text that serves as headers in other interfaces. There is some inconsistency in the style that is used, but, at this time, it looks like the blue centered text with the blue background is what is used the most.

I'll be filing a follow-up bug to see if we can get a little more consistency in other places.

[Bill Erickson (berick)]

Pushed a commit to address the style issues noted above, specifically:

    * Reduce vertical space by a few pixels
    * Make field labels non-bold
    * Make input fields bold
    * Remove duplicate padding to avoid label misalignment.
    * Use blue alert-info banner along the top of the screen.

Also merged in latest master code.

[Bill Erickson (berick)]

Pushed a commit to differentiate between Register Patron and Edit Patron headers along the top of the page. Register gets the standard blue banner, Edit gets a smaller header for consistency with the other tabbed patron UI's.

[Bill Erickson (berick)]

Based on the discussion from the lists, I've pushed a commit (same branch) that makes the patron tabs fixed and makes the edit actions in the patron edit/reg interface fixed.

http://libmail.georgialibraries.org/pipermail/open-ils-general/2015-July/011970.html

This change required a good bit of rearrangement of the circ/patron code to get everything to sit right and some of the changes are a bit finicky, specifically tweaking margins (and negative margins). It will need testing and eyes. Also, beware that this change does not make the patron summary (along the left) fixed. If the goal is to mimic the XUL interface, where only the main data pane moves, and the summary pane is fixed, a different approach will be needed (like just making the main content pane scrollable).

[Bill Erickson (berick)]

Rebased branch to current master. Pushed a commit to make the Show Required/Suggested/All links functional. It may still need some tuning, but initial tests look good.

[Bill Erickson (berick)]

And.. pushed another fix to repair the show/hide summary selector and to keep the patron name visible when the summary is collapsed.

[Bill Erickson (berick)]

Since the current work is moving out of the "phase 1" area, I've pushed a new branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1452950-web-client-patron-reg

Additions include:

* rebased to 2.9-era master.
* generate password
* update expire date
* phone / email invalidate buttons (display only)

[Bill Erickson (berick)]

Merged master code in and pushed a number of additions:

 * Add/Remove address support
 * Postal code auto-complete
 * Patron barcodes dialog (needs a little more work)
 * Replace barcode action
 * Initial support for saving modified patrons (needs a little more testing/work)

[Bill Erickson (berick)]

Pushed a variety of bug fixes for saving patrons, most notably fixing address handling and saving new patrons.

Saving changes works, but beware there is still no data validation, so it's easy to attempt saving an invalid form.

[Bill Erickson (berick)]

Pushed a pile of new bits:

* focus barcode on register; username on edit.
* support password from phone if lib setting is present.
* hide invalidate buttons and replace barcode in register mode
* address no longer defaults to in city limits
* display opt-in user settings
* fleshed out support for surveys
* got stat cats working
* merged in origin/master

[Bill Erickson (berick)]

A few more:

1. sort stat cats, stat cat entries, and surveys alphabetically.
2. only show currently active surveys

[Bill Erickson (berick)]

1. Get field documentation working with addresses. Unclear why the previous solution was not working, but the new one is.
2. Minor code cleanup.

[Bill Erickson (berick)]

more stuff pushed:

* secondary groups dialog
* field invalidation
* form loading dialog (prevents form editing until all fields are displayed)
* duplicate patron searching

[Bill Erickson (berick)]

* improved duplicate patron / idl doc display styling
* warn on page unload / tab navigation when data has changed.

[Bill Erickson (berick)]

Added support for patron cloning. Numerous bug fixes. Rebased to master.

Some features still pending, but code is merge-able. Adding pullrequest.

[Bill Erickson (berick)]

Pushed staged (pending) users support: Load staged users and remove staged accounts after successful save.

[Galen Charlton (gmc)]

Pushed to master along with release notes identifying this as a technology preview, since while the overall result is pretty solid, there are some issues for which I'll be opening separate bugs. Thanks, Bill!