Angular Form Field Order

[Terran McCanna]

In 3.4:

The pop-up forms that are used by the new Angular interfaces list the form fields alphabetically rather than in any sort of logical order. We are currently testing for our January upgrade and have received numerous confused complaints from staff who need to use those forms.

Examples: Carousel Editor, Address Alerts, Hold Policies, Shelving Locations Editor, etc.

[Bill Erickson (berick)]

Note as of 3.4, the fm-editor component has a fieldOrder input. For these autogenerated UI's, we'll have to propagate the field order down to the fm-editor, likely via route data.

[Andrea Neiman (aneiman)]

Per bug 1866083, Bib Import Merge Profile Editor is another modal affected by this. I've marked that one duplicate, but feel free to unmark if we're tracking these separately.

[Terran McCanna (tmccanna)]

See also, comments in duplicate bug: https://bugs.launchpad.net/evergreen/+bug/1879514

[Jane Sandberg (sandbergja)]

I think I can spend some time working on this (likely taking the approach Bill mentioned in #2). However, it would be helpful for me to have the desired field order for the forms mentioned in this bug.

[Jane Sandberg (sandbergja)]

One more question: should the order of columns in the grid match the order of fields in the form? My initial thought is that an order that is illogical for the form would be likewise illogical for the columns; and that a carefully considered order for the form might be a better order for the grid columns than the default behavior (with the understanding that users can re-order the columns if they'd like).

But if matching the order of the grid to the order specified for the form wouldn't be helpful, I'm happy to leave the grid column ordering as is.

[Terran McCanna (tmccanna)]

In general, as long as the name (and org unit when relevant) are at the top, I don't have a strong preference for the rest of the fields. But, here are some suggestions:

Carousel Editor
1. Owner
2. Name
3. Carousel Type
4. Age Limit
5. Maximum Items
6. Item Libraries
7. Shelving Locations
8. Is Active
9. Carousel ID
10. Bucket
11. Last Refresh Time

Address Alerts
1. Owner
2. Alert Message
3. Street (1)
4. Street (2)
3. City
4. Postal Code
5. County
6. Country
7. Billing Address
8. Mailing Address
9. Match All Fields
10. Active
11. Address Alert ID

Holds Policies
This one has so many fields, I think it would be helpful to put the Description field first and then to break it up visually into natural groups of fields related to related to a) item, b) user, c) holds (or something along those lines).

Shelving Locations Editor
1. Owning Org Unit
2. Name
3. Is OPAC visible?
4. Can Circulate?
5. Is Holdable?
6. Hold Capture Requires Verification
7. Checkin Alert
8. Is Deleted?
9. Label Prefix
10. Label Suffix
11. URL
12. Location ID

For the question of having the column order match the fields, I think it's a good idea in general. There may be cases where some of the top fields on the form aren't particularly useful in the summary-type view of a grid so wouldn't default to visible - for instance, if a form has a name followed by a description, the name might be first in the grid but the description might not default to visible.

[Jennifer Pringle (jpringle-u)]

I agree with Terran that Name/Label and Owner/Org Unit fields should always be at the top of the form.

I also agree that having the default column order match the fields is a good idea. I think overall it will give users a more logical order to start with.

For other forms that need to be re-ordered does it make sense to simply add the desired order as a comment in this ticket or would something like a google doc that's updated as new forms are found be better?

[Jane Sandberg (sandbergja)]

A comment in this ticket would work well. I'm hoping to get a branch put together in the next few days.

[Tiffany Little (tslittle)]

Jane, I'd like to advocate for reordering the EDI Account setup screen. Here would be my preferred order:

EDI Account ID
Label
Provider
Owner
Account
Vendor Account Number
Vendor Assigned Code
Last Activity
Host
Username
Password
Path
Incoming Directory
Use EDI Attributes?
EDI Attribute Set

I'm open to some moving things around if other Acq people think there's a better order, but this would be my pass at it.

[Jane Sandberg (sandbergja)]

I created a branch that fixes the ordering that I've heard of so far. The branch is user/sandbergja/lp1857351_angular_admin_order

Here's a link: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1857351_angular_admin_order

The interfaces that should have changed:
* Admin > Acq > EDI Account
* Admin > Local > Shelving Locations Editor
* Admin > Local > Address Alerts
* Admin > Local > Carousel Editor
* Admin > Server Admin > Hard Due Date Changes
* Admin > Server Admin > Z39.50 Servers
* Booking > Manage Reservations (and several others; only the editor modal changed for these, not the grid column order)
* Cataloging > MARC Batch Import/Export > Merge/Overlay Profiles

Other interfaces should not have been changed. Looking forward to testing!

If this branch is accepted, it should be simple to create a custom field order for any of the autogenerated admin interfaces in the future: just adding 1-4 lines in a routing.module.ts file.

[Terran McCanna (tmccanna)]

Recurring fine rules is another that would benefit from this approach - see bug 1839874

[Jane Sandberg (sandbergja)]

Claiming this to add the recurring fine rules interface to my branch

[Jane Sandberg (sandbergja)]

I added another commit to re-order the fields in the Recurring Fine Rules interface.

[Ruth Frasur Davis (redavis)]

I have tested this code and consent to signing off on it with my name, rfrasur and my email address, <email address hidden>.

[Jane Sandberg (sandbergja)]

I'm grabbing this again to re-order another interface: the Terms editor in the course materials module.

[Jane Sandberg (sandbergja)]

Just pushed a new branch: user/sandbergja/lp1857351_angular_admin_order-2

It is rebased against today's master, and includes Ruth's signoffs (thanks, Ruth!) It also has a new commit which has not been signed off, which reorders the fields in the course terms interface.

[Michele Morgan (mmorgan)]

I've reviewed the reordered forms and they look good to me. Adding my signoff to Jane's latest commit for the Course Terms Interface, as well as the others:

user/mmorgan/lp1857351_form_field_order_signoff

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp1857351_form_field_order_signoff

The order of fields in the Hold Policies form was not addressed by these fixes, but I would advocate for opening a new bug for that form. Given the large number of "cause and effect" type fields, it would be helpful to put some thought into a sensible order.

[Jane Sandberg (sandbergja)]

Pushed to rel_3_6 and master. Thanks, Michele and Ruth!

This does not backport cleanly to rel_3_5, so I opted not to do it. Happy to be overruled, of course.