Article Type: Release Notes Audience: All Users Module: Platform Releases
This month's release is full of treats that are sure to delight - but hopefully no tricks… read on to learn more!
The October 2024 release features a significant set of changes to how roles work in Fuuz. In previous versions, roles were used to apply configuration to a user, such as drawer menus, home screens, and settings. This was completely separate from the permission system in Fuuz, which was based on policy groups attached directly to a user. This separation was the source of some confusion among users and administrators, especially since the terminology commonly used in other business applications uses roles for both permissions and configuration. With that in mind, we've decided to significantly rework the role system in Fuuz to align more closely with what our users expect.
These changes start during role configuration. The Role form has a new tab for Attached Policy Groups, which allows administrators to define the permissions to grant to users who have the role assigned and active.
Note: The policy groups attached to roles are the same groups that were previously attached directly to users. This allows for a quick and easy migration to the new role system.
Once a role has been configured, assigning that role to users operates the same was as before, with the addition of a "Default" flag that lets administrators specify which role should be active by default when a user signs in to Fuuz.
Users can see what role is active in the footer (e.g. Production Supervisor), where it previously displayed the user's name.
If a user has more than one role assigned, they can click the role section in the footer or use the "Switch Role" action in the Avatar menu to access the switch role UI, which displays the roles and their descriptions that are assigned to the user and thus are available to switch to.
When a user has a role active - either because it's their default role, or because they've selected one - the configuration configured for that role will be applied to the user. This includes the same configuration available previously - drawer menu, home screen, and settings - as well as the assigned policy groups.
Important: Policy groups attached to roles will only be granted to the user while they have the role active. If the user switches to a different role, the policy group will no longer be applied.
These changes together allow roles to be the central location for configuring the Fuuz user experience based on the work users need to do, making it simpler to apply changes to all users with the same role or to add or remove roles when employees hire on or change positions.
This month's release features some optimizations to our GraphQL query system which significantly improves the performance of certain types of queries. Specifically, we've optimized the way we look up related data to handle filtering and grouping on node and connection relations.
To illustrate the significance of this improvement, here are some comparisons for queries run against a Production History collection:
| Query | <= 2024.9 | >= 2024.10 |
|---|---|---|
Filtering by workcenterId |
70 ms | 70 ms |
Filtering by workcenter.id |
400 ms | 100 ms |
Filtering by dataChanges.changedAt |
260 ms | 170 ms |
Count grouping by workcenterId |
100 ms | 100 ms |
Count grouping by workcenter.id |
430 ms | 130 ms |
In previous versions, the performance hit when performing grouping or aggregation against a field on a relation instead of a field directly on the model itself was significant. In 2024.10, those queries generally run 2x - 4x faster - they're still not as fast as filtering or grouping by fields directly on a model, but this optimization has significantly closed the gap.
In addition to relation queries, the 2024.10 release also includes optimizations to the $executeTransform binding, used to execute saved scripts inside other scripts. We've been able to significantly reduce the overhead of this binding. This means a single usage of $executeTransform will now run faster - but more importantly, it's now feasible to use $executeTransform inside a loop, filter, or map without incurring a significant performance hit. The table below displays some metrics from our testing running a simple saved script in a JSONata map statement:
$executeTransform Calls |
<= 2024.9 | >= 2024.10 | % Change |
|---|---|---|---|
| 100 | 0.1 s | 0.07 s | 30% |
| 1,000 | 5.7 s | 0.7 s | 87% |
| 10,000 | 41 s | 4.8 s | 88% |
Scripts that use $executeTransform in a loop now run a whopping 8x faster - a huge improvement! This change makes it viable to use saved scripts more generously, allowing app builders to reuse smaller snippets of scripts without incurring a significant performance penalty.
modelDefinitions query to provide a more performant alternative to the existing modelMap query$query and $mutate bindings$executeTransform binding$.appConfigNote: Patch Release Date: October 22, 2024