Article Type: Release Notes Audience: All Users Module: Platform Releases
Note: QA Release Date: September 5, 2023. Production Release Date: September 19, 2023.
Fall is kicking off with a release full of new features and enhancements - read on to find out more!
The September 2023 Fuuz release includes a new set of features for site administrators to more tightly manage permissions for users based on the IP addresses from which they're accessing Fuuz. These features add new rule types to the policy system which, combined with allow and deny effects, allow flexible whitelisting and blacklisting of IP addresses or CIDR ranges for specific or broad permissions in Fuuz. For more information on policies, check out our knowledge base article Getting Started With Visual Policy Editor.
The following policy explicitly denies access to query employee names or date of birth when the request IP is not in the provided CIDR range. This would be paired with a separate policy which grants access to those resources for administrative users, ensuring they're only allowed to access them when the request originates from your static IP range. This approach allows administrators to write policies which generally allow access, but selectively deny access to sensitive resources based on IP address.
{
"statements": [
{
"effect": "deny",
"actions": [
"graphql:*"
],
"resources": [
"graphql:humanCapitalManagement:employees:employee:firstName",
"graphql:humanCapitalManagement:employees:employee:lastName",
"graphql:humanCapitalManagement:employees:employee:dateOfBirth"
],
"rules": [
{
"ipNotInCidrList": [
"192.168.0.0/24"
],
"message": "Employee information must be accessed from the internal network."
}
]
}
]
}As another example, the following policy only allows access to query procurement resources when the request originates from the listed IP addresses. This approach is a standalone policy which allows administrators to bake IP address restrictions into broader policies directly, setting IP restricted access as the default rather than the exception. Note that if this policy is attached to a user with other policies which grant access without an IP rule applied, access will be granted regardless of the request IP.
{
"statements": [
{
"effect": "allow",
"actions": [
"graphql:query"
],
"resources": [
"graphql:supplyChainManagement:procurement:*"
],
"rules": [
{
"ipInCidrList": [
"192.168.0.4",
"192.168.0.5"
]
}
]
}
]
}The 2023.9 release includes a significant new feature for calendars - support for resources and a resource view! Calendar resources provide a way to allocate things - rooms, people, machinery, etc. - to a calendar event, and then view the utilization of those resources in a new resource view. Calendar resources help support a wide range of Fuuz-built or custom scheduling applications. To read more about the Calendar system in Fuuz, check out our Knowledge Base articles on Calendars and Calendar Resources.

The release also includes a wide variety of smaller changes to calendar event bindings and UI inputs to better handle issues like time zones, all-day events, and repeating events.
This month, we're also rolling out support for multi-factor authentication (MFA) using tokens generated from authenticator apps. This method provides a more convenient option than the existing emailed token method for many MFA users. Fuuz users can configure multi-factor authentication for their accounts, either email or token-based, on the My Profile page; administrators can configure MFA settings for other users via the Identity Provider or Enterprise User screens. For more information on configuring multi-factor authentication, see the Fuuz Knowledge Base article on how to Configure Single Sign-On.


We have several more improvements to the MFA system in Fuuz on the way, including options for administrators to enforce MFA for their users; keep an eye out for those in future releases!
The September release includes an exciting new transform binding which brings our GraphQL API predicate syntax into scripts with support for filtering arbitrary JSON objects. This allows app designers to use a familiar syntax for filtering complex objects, and to use the same predicate objects for data retrieved from external APIs as are already used with the Fuuz API. You can see a few examples of how to use this new binding below, and you can read more about this new binding in the Fuuz Knowledge Base article Fuuz Bindings: $predicateFilter.
An equality comparison. Matches when the field value equals the provided input value.
$predicateFilter(
[
{ "id": 1, "label": "One" },
{ "id": 2, "label": "Two" },
{ "id": 3, "label": "Three" },
{ "id": 4, "label": "Four" }
],
{
"id": { "_eq": 1 }
}
)
Result:
Performs an object contains comparison. The predicate matches when the JSON field contains the provided JSON path/value entries.
$predicateFilter(
[
{ "data": { "id": 1, "code": "A", "active": true } },
{ "data": { "id": 2, "code": "B", "active": true } },
{ "data": { "id": 3, "code": "A", "active": false } },
{ "data": { "id": 4, "code": "B", "active": false } },
{ "data": { "id": 5, "code": "A", "active": true } }
],
{
"data": {
"_containsObject": {
"path": [],
"value": { "code": "A", "active": true }
}
}
}
)
Result:
[
{ "data": { "id": 1, "code": "A", "active": true } },
{ "data": { "id": 5, "code": "A", "active": true } }
]Object payloads are filtered in a similar way as with the $sift function. Each property of the object is included in the result only if its value satisfies the provided predicate.
$predicateFilter(
{
"foo": { "id": 1, "code": "A" },
"bar": { "id": 2, "code": "B" },
"baz": { "id": 3, "code": "a" }
},
{ "code": { "_eq": "A" } }
)
Result:
In coming releases, we'll add a data flow node for this new predicate binding to simplify using it in data flows, and we're already working on a visual designer for these predicates to allow users to build complex filter predicates with a few mouse clicks. Look out for those features!
updateUserPassword mutation to work with any provider of the "internal" type rather than just the default$predicateFilter binding to allow filtering any JSON data using GraphQL-style predicates