Add/reorder columns on Datagrid2 without breaking preferences of all users?

0
I recently implemented an overview with lots of data and thus columns in a single datagrid. I also added the possibility to have multiple variations of the same datagrid, for whatever means a user can have (e.g. view A with columns ABC and View B with columns A D F G). This has received a lot of positive response. However I recently discovered that when I add a column or reorder columns it breaks the datagrid preferences of all users. We save them in a per-user owned entity/attribute. I find it crucial that the column and filter preferences of all users are preserved, even when updating the datagrid.Has anyone found a solution for this or can think of one?The only thing I can think of is frequently backing up the datagrid-preferences string and after deployment restoring those backups while appending edits. E.g. If we had columns 1-20 and add a 21st column, we append the existence and order of the 21st column to all of eachothers restored preferences-strings. This can of course very easily be forgotten to do, so it would be great if there was a more failsafe method.
asked
1 answers
1

Hi Sander,


Yes, this is a known side effect of persisting the Data Grid 2 personalization. The grid configuration is stored as a JSON string, including the user's column order/visibility/size, so changing the set of columns can make an existing configuration incompatible with the new grid definition. Mendix also documents that the personalization attribute stores the current column order, hidden columns, and sorting state.

I would not overwrite everyone's configuration after every deployment, because that defeats the purpose of user personalization.

What I normally do in this situation is introduce a small configuration version alongside the saved JSON.

For example:

  • GridConfiguration → String (Unlimited)
  • GridConfigurationVersion → Integer

When the grid definition changes, increase the application/grid configuration version, e.g. 1 → 2.

On loading the user's configuration:

  1. Check the stored configuration version.
  2. If it is the current version, use it as-is.
  3. If it is an older version, migrate the configuration.
  4. Preserve the user's existing column order, visibility and widths for columns that still exist.
  5. Add newly introduced columns using the new default configuration.
  6. Remove columns that no longer exist.
  7. Save the migrated configuration and update the version.

This way, a user who has spent time arranging 20 columns doesn't lose that setup just because you added column 21.

There is a good reason to do this rather than simply clearing the attribute. There are existing reports of Data Grid 2 returning:

Invalid columns state: invalid columns order

after adding a column or changing captions, because the persisted configuration no longer matches the grid definition. A commonly used workaround is to clear the saved configuration, but that obviously loses the user's personalization.

The Data Grid 2 also provides an On Change action for the personalization attribute, so you can keep the persistence logic in a microflow rather than letting the page logic become complicated.

One important point: I wouldn't rely on simply appending a string for the new column. The saved configuration is interpreted by the Data Grid 2 widget, so manually modifying the JSON should only be done if you have tested the exact configuration format for the Data Widgets version you're running.

For a large application, my preferred approach would therefore be:

User personalization JSON + configuration version + migration/reset fallback.

And I'd keep a fallback such as:

If configuration cannot be migrated
    → clear personalization
    → let Data Grid 2 use the current default configuration
    → save the new configuration

That gives you a safe recovery path instead of leaving a user with an Invalid columns state error.

So I wouldn't recommend backing up and blindly appending the new column to every user's JSON. Versioning the grid configuration and migrating only the affected users is much safer, especially when you have many different personalized layouts.

This also means you can distinguish between a normal deployment and a breaking grid change, rather than resetting everyone's preferences every time the application is deployed.

answered