2024.6 Release Highlights

As the team works hard to wrap up our Q2 roadmap items that will be delivered in the July and August releases, the June 2024 release was focused primarily on internal system and tooling improvements. We’ll talk about a few of those below, but I wanted to devote part of this month’s release notes to preview a set of changes coming in July that will have a significant impact on how user access is managed in Fuuz.

There’s a lot of text ahead, but whenever we make significant changes to the way a core feature works in Fuuz I want to make sure we explain why we’re making those changes and how they’ll improve the lives of our users - and as you’ll see, these changes are very significant!

Preview: User Access Management Changes

The following sections describe changes which will be deployed in the July 2024 (2024.7.0) release.

User access management is one of the points of friction that has developed over the past year as we’ve invested in our app platform. The existing approach was developed early on in the life of the platform, and as the system as grown and evolved over the years, it’s become clear that a number of aspects of user management don’t nicely align with how customers are using the platform now. To address that, we’re rolling out a range of changes in the July release which will collectively have a significant impact on how user access is managed in Fuuz.

Access Control Policy Changes

First up, we’re making some changes to how access control policies are managed and applied. Historically, policies were created and applied at the enterprise level, which meant they applied to every app a user had access to. This approach just doesn’t align with how users are granted access to apps, and on top of that, it created friction when applying policies to users or creating policies for use in apps.

With the July release, access control policies and policy groups will now be managed at the app level, with a separate set of policies in each app or tenant. Additionally, policies will now be applied by default using roles, which can themselves be linked to one or more policy groups. This approach simplifies permission management, allows administrators to grant different permission levels to the same user for different facilities, and allows apps to bundle default policies, groups, and roles with the app. We’ll be releasing updated documentation leading up to the July release explaining the difference between policies, policy groups, and roles - but going forward, once the permissions are configured, administrators will only need to worry about applying roles to a user to manage their level of access.

This change does mean that enterprise administrators will need to perform an initial configuration of the roles in their system; to support that transition period, the existing system of attaching policy groups to users directly will continue to function, but will be deprecated in favor of using roles.

User Access Types

Another area of confusion has been the base level of access granted to a user. Historically, we haven’t made a strong distinction between administrator users, normal users, and API access users; instead, we’ve relied on a built-in set of policies to determine what base permissions a user should have. This complicates user administration, since it’s not clear what the intended use for a user account is, and makes it difficult for us to add basic platform features that should be available to only one type of user.

Starting with the July release, users will now have an “Access Type” defined on their enterprise account, defining what type of user they are and what basic permissions they should have assigned. There will be four access types initially: Administrator, which will replace the “Enterprise Administrator” checkbox; Web Access, for normal users who are permitted to sign in to the Fuuz web app; Gateway Access, for users created specifically for use with the Device Gateway; and API Access, for users created for direct API access using API keys.

This separation will allow us to enforce a set of security best practices: for example, in a future release, we’ll remove the ability to create API keys for web access and administrator users. It also allows us to ensure users always have a basic level of permissions granted to support their access type - web access users will always be able to sign in to Fuuz; gateway access users will always be able to manage gateways and devices; administrators will always be able to manage other users; and so on.

Since we don’t know what type existing users are, all non-administrator users will be set to the Web Access type upon release of this feature in July; administrators will need to change the user access type for API and Gateway users so those users have the correct access type.

User Invitation

Finally, the process of granting a user access to an app has been growing increasingly complicated as we’ve added new features to the platform. In an effort to streamline and simplify that process, we’ve added a new “Invite User” feature to the App Users screen in Fuuz. App admins can simply type in a user’s email address and select a role - just two fields to add a user. If there’s already a user in Fuuz with the provided email address, this feature will just add app access and the selected role to the user; if they don’t have an account yet, they will have an enterprise account created, with the fields normally available during enterprise user creation populated by default values.

This new feature should significantly streamline the process of granting access to apps for either new or existing users, and it will be the recommended approach for adding users going forward. The current approach, requiring administrators to switch to the administration tenant and add users on the Enterprise Users screen, will still be available, but that process won’t permit selection of a role to assign to to the user in their home tenant. That’s something we’re looking at adding in a future release, but for now, the best option is to switch to the app or tenant you want to add a user to and use the “Invite User” feature on the App Users screen.

More Highlights

User Metadata Caching

The 2024.6.0 release includes an optimization to the Fuuz platform to improve the load performance of our site. Every time a user signs in to Fuuz, refreshes a Fuuz page, or changes tenants, the system loads the metadata about that user that drives the look and feel of the system - things like settings, roles, and modules. This metadata doesn’t change very often, which makes it an excellent candidate for caching - which is exactly what we’ve done. Fuuz now automatically caches that metadata and refreshes it internally when needed.

As a result, we’ve shaved up to a second off the load time for Fuuz when signing in, changing tenants, or refreshing a page. That may not sound like much, but it adds up over the course of a day, and the result is definitely noticeable in the system with less time spent waiting on loading spinners.

This change involved building out a new framework for caching and cache invalidation which we plan on leveraging in the months to come to improve the performance of other commonly-referenced system queries - a reflection of our commitment to making Fuuz as streamlined as possible to use!

Expanded Automated Tests

The June release also includes a round of expanded automated unit and integration tests for the Fuuz platform. These are changes that end users will never see directly - they help us ensure our code changes are satisfying their requirements and that they continue to work correctly into the future as we add further features and enhancements. This release includes tests for query predicates, the notification platform, and the subscription service, but we’ll always be adding more tests to improve our code coverage and ability to deliver quality software quickly.

Full Release Notes: 2024.6.0

Data Team

GraphQL APIs

• Standardized core mutation resolver logic in preparation for future refactoring

• Added automated integration tests for filter predicates with custom scalar types such as Rich Text and DateTime

• Updated API services to cache currentUser query results to reduce initial page load and sign-in times

Security

• Updated Active field on the Application User table to show false if either the enterprise-level user account or their access to the tenant is inactive

Integration Team

Device Gateway

• Improved internal gateway bundle deployment tooling

• Updated bundle packaging to reduce bundle size and standardize names

• Updated store and forward to better handle very rapid value changes

Notification Platform

• Added additional automated unit and integration tests

Subscription Service

• Implemented additional automated unit tests

• Added handling for a race condition that could cause dead-ended consumers to be added to queues

Orchestration Team

Data Flow Designer

• Added an improved expanded code editor for data flow script fields

Package System

• Updated task logs to clarify log level for expected error cases

User Interface Team

Framework

• Updated sidebar drawer menu to not display when it doesn’t provide any useful user interface (e.g. when a user’s role does not specify a role menu)

• Updated form dialog to support multiple form sections

Screen Designer

• Updated screen templates to use Select inputs rather than older Combobox inputs

• Added configuration option to Table elements to only allow one active master detail section at a time

• Corrected a bug that would occur in “run screen” mode with screens that link back to themselves

Application Designer

• Fixed a bug causing state crossover between screen designer and application designer