Browser client server-side column configuration

[Bill Erickson]

Evergreen circa 2.12

The browser client should support server-side default grid column settings, including column position and relative width, similar to the XUL client's "column_setting" feature. This allows admins to globally override the default settings applied in the TT2 files.

While it's possible to configure column position and width by creating local overrides of affected TT2 files, this is difficult to maintain.

I propose something along the lines of the XUL client, a well-known directory in the browser client code (e.g. /js/ui/default/staff/column_settings) that contains a JSON file per server-configured grid.

1. The file name will be based on the grid's persistKey attribute (e.g. "cat.bucket.record.view.json").

2. The JSON file structure will be the same as the column configuration JSON stored by the browser when the "Save Column Configuration" command is used. It's an array of objects with keys "name" and "flex".

3. An addition to the XUL version is supporting 2 types of default column settings, "defaults" and "required" settings. "Defaults" would override the settings in the TT2 files. "Required" settings would override both the TT2 files and any settings stored in the browser. (Presumably when a grid has a "required" configuration, the "Save Column Configuration" command would be disabled in the interface).

[Galen Charlton (gmc)]

While this approach would work, and I have no strong objection to it, I'd like to propose a variation that doesn't require that the EG admin mess around with files on the server: store them in the database as JSON blobs, possibly with an OU for scoping which ones to use, and either fetch the desired one when rendering a grid or fetching them en masse during app startup. To create or modify the templates, I further propose that a new column configuration action be added to specify saving the current config to the server.

[Galen Charlton (gmc)]

One advantage of doing it this way is that if the column configuration format were to change in an incompatible way, having them in the database would make them more accessible to an upgrade script.

[Bill Erickson (berick)]

I like it, Galen. You had me at "save to server". And +1 to org-scoped.

One benefit of the old-school way was we could leverage browser caching to avoid re-fetching the settings with each grid render. A comparable caching mechanism, like an expire-duration value or similar, would be nice to have. The grid "reset columns" action could force a re-fetch.

[Bill Erickson (berick)]

Note this might be affected by the pending work to store workstation settings on the server.

[Michele Morgan (mmorgan)]

Just want to add another +1 to have these settings org-scoped.

[Bill Erickson (berick)]

This bug may ultimately be absorbed by bug #1750894.

[Bill Erickson (berick)]

The data storage for this bug is now covered by the code in bug #1750894. This bug is now primarily focused on creating a grid option for storing values as org unit settings. Something along the lines of...

1. If an org unit setting type exists for the current grid
2. Check to see if the current user has permission to apply values to the org setting.
3. Display an additional "Save Columns as Org Unit Settings" option in the grid config menu for propagating values to the org unit setting.
4. When clicked, the user selects the org unit where the value should be applied.