Skip to main content

Version 2.3.0+

These are the release notes for the v2.3.0 release of Witboost.

Please refer to the official documentation for a more in-depth overview of the released features.

Features​

Witty​

Witty is a new way to interact with the Witboost platform using natural language. It allows the user to ask questions and get answers in a conversational manner, making it easier to find information and perform actions in the platform. Witty is a personal assistant designed to enhance user productivity by leveraging Large Language Models (LLMs) and Generative AI (GenAI). It operates as a multi-agent system, dynamically selecting the most suitable AI agent based on the user's request.

Witty works as a supervisor that independently chooses the best AI agents it needs to achieve the user's goal. By default, Witty includes a specialized agent with in-depth knowledge of Witboost documentation, enabling users to quickly access accurate and context-aware information. Other specialized agents can be added at any time by platform team.

LLM Engine​

The LLM Engine is a new feature that allows the user to create and manage LLM policies in the Witboost platform. LLM policies are regular CGP policies that leverage an underlying LLM to check the compliance of the entities in the Witboost platform. The LLM policies are defined using a natural language input, where the governance team can define the constraints and requirements for the entities in the Witboost platform (e.g. you can ask the LLM to check if the entity is compliant with a specific regulation, or if it contains sensitive data).

These policies are extremely powerful, as they allow the user to define complex checks using natural language, without having to write any code. Anyway, given the non-deterministic nature of the LLM, the user should be careful when defining the policies, as they can lead to false positives or false negatives: always try to be as specific as possible when defining the policies, and test them thoroughly before deploying them in production.

Since the underlying LLM must be configured at platform level, be sure that the LLM engine is properly configured in the Witboost platform before starting to create the LLM policies.

RBAC Administration Panel​

In the Administration Panel, we introduced a new RBAC management page, which allows the user to manage the RBAC roles and permissions in the Witboost platform. In this page, an administrator can create, edit, and delete roles and permissions for the users and groups in the Witboost platform.

The platform provides a set of pre-defined roles, which can be used as a starting point for the administrators. The administrator can also create custom roles, which can be assigned to the users and groups in the Witboost platform.

Please remember that the RBAC roles are not automatically assigned to the users and groups in the Witboost platform. The administrator must manually assign the roles** to the users and groups. When assigning the roles, the administrator can also specify the scope of the role, which can be either global or limited to a specific domain/system.

Please remember that removing the role that allows the administrator to manage the RBAC roles will cut the administrator out of the RBAC management page. The administrator can still manage the RBAC roles using the Witboost database, but this is not recommended, as it can lead to inconsistencies and errors in the RBAC management. To prevent this, the UI tries to warn the administrator when removing the role that allows the administrator to manage the RBAC roles.

With this new page, the Witboost platform provides a more flexible and powerful way to manage the RBAC roles and permissions, allowing the administrator to create custom roles and assign them to the users and groups in the Witboost platform. Please review the existing roles and assignments to the users and groups in the Witboost platform, as this new view could highlight some inconsistencies in the existing roles and permissions.

Custom View Administration Panel​

In the Administration Panel, we introduced a new Custom View management page, which allows the user to create custom views for the entities in the Witboost platform. In this page, an administrator can create, edit, and delete custom views for the entities in the Witboost platform. The custom views are defined using a YAML file, which is stored in the Witboost database. The YAML file defines the layout of the custom view, including the fields to be displayed, the order of the fields, and the type of each field.

Using the management page, the administrator can easily check which pages will be affected by the custom view, and can also see the list of all the custom views already defined in the Witboost platform.

We also introduced the possibility for the administrator to enable or disable the custom views, allowing for testing different configurations without having to delete the custom view. Remember that only one custom view can be enabled at a time for each entity and template type: an administrator can easily switch between different configurations now, without having to delete and recreate the custom views.

In addition to this, the Custom Views now support the following features:

  • custom icons can be added to the fields. They can be added as standalone icons, or as icons with a label. The icons can be defined using existing Material UI icons, referencing an external URL, or using a custom icon from the Witboost pre-defined list.
  • links can now be opened in a new tab, and we added the support for the mailto: protocol

Policy test with custom descriptor​

In the Governance Registry page, after creating a policy, there was already a way to test the newly created policy against all the entities deployed in the Witboost platform (this is accessible from the Test button in the policy page). Since the number of deployed entities can be quite large, this feature was not very useful for the user, as it was difficult to find the entities that were affected by the policy.

To improve the user experience, the feature has been improved to allow the user to test the policy against a custom descriptor, which can be useful for testing the policy against a specific entity or for debugging purposes. The descriptor can be copied from the Builder entity page, and can be manually edited to test the policy against different corner cases.

This feature is especially useful when trying to implement some complex policies using the Cue engine, as it allows the user to test the policy against a specific entity without having to deploy it in the Witboost platform. Since the introduction of the LLM engine, the testing of the policies has become even more important, as the user could require more testing before releasing the policy, given the non-deterministic nature of the LLM engine.

Skeleton Builder entities​

In this release, we introduced the concept of Skeleton Entities. This is a new way to define entities in Witboost, which allows for more flexibility . A Skeleton Entity is an entity whose definition is provided by a Nunjucks-templated file. This file is stored within the entity's repository alongside a set of parameters required to render the final YAML definition, which is then supplied to the Witboost Catalog.

This approach allows for a more dynamic and flexible way to define entities, as the definition can be generated at runtime based on the parameters provided. This solves a common problem with static YAML files, where by editing manually teh files using Git, the user should remember to edit the final rendered value as well as the parameter values. This can lead to inconsistencies and errors, especially when the user changes only a single value in the YAML file, usually forgetting to update the corresponding parameter value.

Entities such as Systems and Components can (and should) be defined using these skeleton (templated) definitions for better flexibility and maintainability. Skeleton entities seamlessly integrate with tools like the Editor Wizard and the Reverse Provisioning Wizard, allowing for easier entity management.

Summarizing, Skeleton Entities were introduced to:

  • Provide better integration with Witboost's graphical tools.
  • Simplify the workflow for non-technical users.
  • Offer greater flexibility and power for technical users who prefer working directly in repositories.

Please read the documentation for more information on how to use this feature, and how to migrate your existing entities to the new format.

Zoomed UI Improvements​

The Witboost UI has been improved to provide a more user-friendly experience, making it easier to navigate and interact with the platform, even when zoomed in. This includes a better disposition of the elements on the screen, improved font sizes, and some refactoring of the existing components.

We also introduced the possibility for the user to change the size of the table columns in the UI, to better read the content when it is filled with long strings. This is particularly useful for users with visual impairments or those who prefer to work with larger text sizes.

Guest Users​

The Witboost platform now supports the concept of Guest Users, which allows users to access the platform without having to create a full user account. This is particularly useful during the installation phase, when the platform is being set up and configured; this way, an installer can login to the platform without having to set up the integration with the identity provider.

We introduced a guest users startup action which registers the guest users on the license (or defined in the configuration) to the plugin database, enabling them if and only if no roles subjects exist yet on the platform. It also manages the RBAC roles subjects for the new users.

Split of Coordinator and Computational Governance Platform (CGP)​

The Coordinator and the CGP can now be started as separated deployments by setting the appropriate Helm chart values. This allows for more flexibility in deployment and scaling (also regarding the dedicated resources).

Support Service Principals in the Microsoft Graph Organization Provider​

The Microsoft Graph Organization Provider now supports an advanced mapping mode for converting Microsoft Graph users, groups, and organizations into Witboost users and groups in a flexible manner. The old mode is still supported and is the default.

The new advanced mapping mode specifies where to fetch the information in the Microsoft Graph user for each field of the Witboost user by providing a list of fields that are tried in sequence, where the first non-null value will be used. This can be used to support the import of users without an email address (e.g., machine/technical users).

Issues fixed and minor improvements​

  • Reduced the memory footprint of the execution plan status retrieval endpoint
  • Any null provisioning info in the tech adapters provisioning response body are now interpreted as empty values
  • Fixed some known dependencies vulnerabilities
  • Fixed some broken links in the documentation
  • Fixed a bug where a custom view was automatically disabled after updating in some cases
  • Added project type on the system list in the software catalog
  • Fixed a bug where role subject registration would fail if guest users are configured with lowercase characters
  • Fixed that when clicking outside a Confirm Dialog during an enable/delete operation from the customizations table, the page is changed to the customization detail
  • In the deployment panel, if partial provisioning is enabled, it is possible to select on which components to change the deployment status with checkboxes
  • Policy testing using a custom descriptor, require some fields as a string because they are used in the descriptor configuration; they are now validated before sending the request to the CGP. The "environment" and "kind" fields are validated before sending them to the CGP
  • Error messages for missing (or wrong type) fields in the custom descriptor while performing a policy test are easier to understand
  • In the Custom Views we improved the alignment of icons and displayed value
  • In the Custom Views the order of the automatic list is now honored
  • In the Custom Views we added custom label field to tags elements
  • In the Custom Views the icons are now supported for links and dates
  • Fixed a bug where the DomainType appeared as a root node in the search domain filter even when all the visible domains had the same DomainType
  • DomainType nodes are expanded by default in the search domain filter
  • Updated the global permissions scope to be valid for blueprints, templates, and resources
  • Changed the order by clause in the marketplace search to be resistant to SQL injection techniques
  • Fixed a bug that prevented the personal Data Access tab from being shown properly
  • Improved the way templated parameters are being parsed
  • Resolved an indexing problem that would happen when a lot of instances are indexed in the marketplace containing sub-components
  • Improved the query mechanism of the marketplace search to allow queries for names in camel case or kebab case
  • When generating the yaml from the jsx of a custom view, sometimes the items appear in an incorrect order compared to the order in which they were originally defined
  • The "create-policy-requested" event has been deleted because it was unnecessary due to the presence of the "policy-defined" event
  • The "create-metric-requested" event has been deleted because it was unnecessary due to the presence of the "metric-defined" event
  • Removed unused suffixes after system names in the labels from the Visual Discovery page
  • Restored the color of domains in the Visual Discovery page
  • Fixed the rendering bug of dates inside tables (which displayed the label)
  • Added the possibility to define a custom format string for dates shown in Custom Views
  • Changed font size
  • Fixed all breadcrumbs to be consistent with the Witboost workflow
  • Main page filters are stored in session now if we use breadcrumbs
  • Introduced Data Marketplace breadcrumbs filter for domain and taxonomy
  • Fixed a problem that didn't show the hexagon names even when zoomed a lot
  • Updated the font size to be dynamically calculated based on the zoom-to-scale ratio
  • In case of an invalid entity during the marketplace collation stage, log an error and continue instead of blocking the whole operation
  • Fixed a bug where refreshing Witboost would bring the user to the sign-in page, despite having an active and valid session
  • The editor wizard now correctly fetches and persists changes on the target branch selected in the Edit and Test page
  • By specifying the type array in the EntitySelectionPicker, the component stores now a mono-dimensional array
  • Added filters and search bar to the visual discovery page
  • Solved an error that occurred when the user clicked on Autocomplete; the form was still “editable” meaning that the user could modify field values while the autocomplete process was running
  • Fixed an error that would always display templates not belonging to any taxonomy
  • Fixes a bug where the Access Control grant/revoke notification message would wrongly state the ownership of the system. This is due to the body storing the requester userRef with a different format than the recipients