web client: Set default widths for some grid columns

[Kathy Lussier]

Related to bug 1645861.

I would like to be able to set the default width for some display columns in the web client grid. Although different users are likely to resize columns just the way they like, I think there are certain places where we can make assumptions for the users. For example, a barcode column should be wide enough to display the entire barcode and columns that display a title should be larger, by default, than a column that displays an ID.

You can't just click and drag to resize the columns in the web client and instead need to use a few clicks. If we can use some reasonable default values for these widths, it will ultimately save time and frustration for the user.

[Terran McCanna (tmccanna)]

Yes, I absolutely agree.

[Bill Erickson (berick)]

Bug #1702929 will address this by allowing column configurations to be stored as org unit settings, allowing for org-scoped defaults.

However, it's also possible today to apply default column widths directly in the template by applying a value for the "flex" attribute. The default flex value is "2".

To make a column twice as wide as the default, for example:

<eg-grid-field flex="4" ....></eg-grid-column>

[Kyle Huckins (khuckins)]

Based on what Bill mentioned, I've pushed a commit here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1645862-grid-default-width-ou-settings

This branch creates Org Unit Setting types based on the existing eg.grid-prefixed Workstation settings, and adds an option to save your grid configuration to the Org. At the moment, the Org Unit Setting types don't have a dedicated update permission, and so will default to UPDATE_ORG_UNIT_SETTING_ALL. A more granular look at permissions is ideal, but will likely be an undertaking in itself, so I'll add the needsdiscussion tag, though I think what is present is also worth the pullrequest.

The Grid will prefer Workstation settings to Org settings, and I've noticed that removing the settings from a Workstation setting or an OU Setting will require logging out and back in to see them apply - this appears to be an unrelated bug worth investigating, so I've opened a ticket here: https://bugs.launchpad.net/evergreen/+bug/1965835

This branch will require any future branch introducing new grid persistKeys to provide an eg.grid-prefixed OUS, as without the setting, the functionality will fail on those grids.

[Terran McCanna (tmccanna)]

I applied this to a test server and I can see and edit the new settings in the Library Settings Editor. However, they don't have descriptions and it's unclear what type of value should be entered. I tried various things (200, 200px, 200em...) and they all break the interface and don't show any columns at all. They give the "TypeError: conf.columns is undefined" message in the browser console. (I did log out and log back in after each change to make sure that wasn't the issue.)

Since I cannot see this working, I can't be sure, but it doesn't appear that this approach actually solves the problem. It appears as if this patch changes the default width of *all* of the columns in the selected grid, which is not what is being asked for. The desired behavior is to be able to set a default width for particular types of columns regardless of their grid. For example, I would like to be able to set all item barcode columns to a default width of 14 characters regardless of what grid they are displayed in.

[Kyle Huckins (khuckins)]

I can definitely see how it may be confusing on how values should be entered - essentially, it copies the functionality of the workstation setting, so the anticipation is that the user will be able to save their adjustments via the grid itself. Manually, you're creating/editing an object that should look somewhat like this: https://gist.github.com/khuckins/a919d04e856ca177683b4a00dfa3bc7e

The widths themselves are flex values associated per column, and are whole numbers starting at 1. Most column widths begin at 2 by default. A release notes might help out here

[Terran McCanna (tmccanna)]

Hmm. I could see that being functionally usable to non-programmers *if* there was an option from the grid itself to say "Save these settings as a Library Setting" and then have it pop up a box to select the appropriate org unit.

[Kyle Huckins (khuckins)]

The patch does provide a new option, "Save Grid Settings to Org," which does exactly that

[Terran McCanna (tmccanna)]

Ah, I see it now - even though there are org unit settings listed for the AngularJS grids, the new option to "Save Grid Settings to Org" is only available on the Angular pages.

[Terran McCanna (tmccanna)]

Okay, now that I understand how it's supposed to work, I like the way it is going. A few comments:

- It definitely needs release notes.
- The Save Grid Settings to Org option only appears on Angular grids (even though there are org unit settings available for the AngularJS grids). I think that can just be clarified in the release notes.
- I think having a new perm just for this functionality might be safer than using the UPDATE_ORG_UNIT_SETTING_ALL perm.
- It would be nice if the the Save Grid Settings to Org option only appeared to users who actually have the perm.
- The org unit selector that pops up when clicking on the Save Grid Settings to Org option allows the selection of any org unit regardless of whether or not the user has perms to save at that level. If the user saves at a level they do not have access to, the failure is silent - a failure message would improve the usability here.
- The Library Settings interface makes it look as if you should be able to edit the saved settings from there, but you cannot, it just gives you: [object Object]

[Jennifer Pringle (jpringle-u)]

I agree with Terran that there should be a new permission specifically for this functionality and that the option should only appear to users with the permission.

The org unit selector in the pop up should only display the org unit(s) the user can save at.

In addition to failing silently, saving also succeeds silently. It would be nice to get the green toast to indicate your save has worked though the current Save Grid Settings doesn't do this either.

I don't think it's useful to have these in the library settings editor, especially since you can't do anything with the settings. If the settings are going to be in the library settings editor they should have their own group. I know they do fall under GUI but adding 150+ settings to that group will make it harder to find other GUI settings if you're needing to browse the list.

[Jennifer Weston (jweston)]

+1 to comments and suggestions from Terran and Jennifer P.
> Release notes needed to explain how this works & where it will display
> New permission needed & only display option when permission is present
> Selected org unit display
> Failure/Success toasts

Notes from my few testing results:
(1) When I save a setting from the grid using the "Save Grid Settings to Org" and then check the Lib Setting, it just shows "[object Object]" as the value.

(2) When entering a value directly into the Lib Setting for Grid Config: user.bucket.view, it does break the interface and no columns or values are visible on that screen. I then realized this is not an Angular interface and that was the problem. So, should we have options for org unit settings available for the AngularJS grids when they cannot be successfully applied? Even with release notes, that could be confusing.

(3) To enter a value directly into a Lib Setting, will we need to know the column names and enter a flex value for each column? or will we not be able to enter/edit values in the Lib Setting at all?

Overall, I agree with the last note in comment #11 questioning the usefulness of having these in the library settings editor. It adds tons of new settings which most likely would be edited rarely (once defaults are established) and makes browsing more difficult. If they are going to live here, a new group would be beneficial.

[Terran McCanna (tmccanna)]

Upon reflecting about the Library Settings Editor, I do like the fact that it allows you to review the history and either clear the setting or revert to an earlier setting. I can see that being very useful to be able to fix something that got messed up.

Adding a description directing people to update the setting by going to the grid and saving it there would be helpful. Is it feasible to make the library setting field not directly editable? Or to display it as the full editable text rather than the object?

[Terran McCanna (tmccanna)]

Removing pullrequest due to comments 10-13.