Webstaff grid could be smarter in IDL mode

[Mike Rylander]

The grid we've built for general use in the web staff client has a mode where it auto-configures columns based on a named IDL class. This is great!

However, if you need to add specialized columns (such as for linking barcodes or formatting timestamps) then you get extra "raw" versions of those columns in the column picker. It would be a kindness if the grid would notice that a path has been used explicitly and skip the column addition.

The wildcard syntax for column addition knows how to do this, so hopefully that code can be cribbed.

[Kathy Lussier (klussier)]

As I look at bug 1669866, bug 1722387 and bug 1705133, it might be a good idea to consider whether it is indeed a good thing to configure columns based on a named IDL class. Is this the reasons why we are getting very long column pickers in some interfaces that include data that will rarely be used? Would it be better to explicitly add all columns rather than adding an entire class at one time?

[Tiffany Little (tslittle)]

I'd like to revive discussion on this bug because I'm interested in what others think, and based on Kathy's comment maybe this is the best place. Explicitly adding columns is what I've done here: https://bugs.launchpad.net/evergreen/+bug/1724965 but I don't know if that's the best path forward.

Having the columns info autogenerated is nice and clean coding-wise, but it just dumps in all the fields in that class, some of which aren't useful for that particular screen. And if you need more than one class (like in the Checkout screen, I think?) then you get uber-long column picker options which again, some of them aren't pertinent. It also doesn't let you do things like having a user barcode/username vs. the user's ID, which is friendlier.

I'm interested in others' thoughts if there's a better way to resolve all that.

[Bill Erickson (berick)]

Original issue confirmed.

I also note that grid column configurations do not apply correctly to columns with auto-fields since the auto fields are generated after the column configuration is applied.

As to the auto-fields vs. manual fields debate, I say any time manual fields are better, use them. In some cases (especially admin UI's) auto fields save us a lot of typing and generally work well, so retaining and improving the functionality would be best.

Note these issues are resolved in the Angular grid.

Grabbing bug to address the duplication issue.

[Bill Erickson (berick)]

Fix pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1683385-grid-auto-dupe-fields

[Galen Charlton (gmc)]

Signoff pushed to:

user/gmcharlt/lp1683385_angjs-grid-dedupe-fields-signoff
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1683385_angjs-grid-dedupe-fields-signoff

I also specifically verified that saved column settings involving a duplicated column do not blow up after the change.

[Galen Charlton (gmc)]

Given the time that has passed, I've gone ahead and pushed this to master, rel_3_3, and rel_3_2. Thanks, Bill!