The time picker component has been enhanced to resolve an issue that occurred when loading (default) values at runtime. Previously, the input would display a runtime validation error if the component configuration used the “hh:mm a” (12-hour AM/PM) rendering format in combination with the “Use 24-hour time picker” component option set to false. This issue has now been fully addressed, ensuring (default) values load correctly when using the 12-hour (AM/PM) format.

The 'Wrapper' component has been renamed to 'Empty Widget' to provide more clarity about its functionality, emphasizing that it can be used to create widgets. Additionally, the 'Empty Widget' is now part of the default component set, eliminating the need to install it separately from the blockstore, making it more accessible and quicker to use.

Within UW’s private cloud, we’d like to have a monthly report of: The database usage per application The asset usage per application Overall sum for both database and asset usage for UW’s tenant

In a DetailChildView any date field is automatically ouput in ISO format now with the ability to modify the formatting and works with relational data

This enhancement allows builders to configure date pickers that restrict end-users to selecting dates within a specified range. The minimum and maximum dates can be set as either static values or dynamic ones, providing greater flexibility and control in date selection.

All an org admin to rollback production without making themself an app builder on an app via this permission

We are seeing cases, particularly long email addresses where the allocated space in the column or box does not allow for the size of the text and it adds scroll bars to the containing div. This is very unpleasant to the end user experience. A Page builder option on the text and title components that  implemented the CSS attribute “word-break:break-word;” fixed the issue. 

Unify this so that all all components can be styled the same way. Betty Blocks introduced CSS (style sheets) that can be used instead of default styling.

To successfully on-board and manage wider campus adoption of the platform and eventually citizen development, we need the ability to manage who has access and what roles they are assigned per organization utilizing UW's SSO. Note: This is separate from End-User SSO and management which is completed and verified working.

The release notes need to be more comprehensive, published regularly and provide insight into what is going to be released prior to the release of the functionality

A builder was not able to copy logs and view logs that had for example 600 lines of JSON. Now, the builder is able to copy the logs when needed and the log is now shown in its entirety.

Right now, the ability to see applications within an organization is tied to the default Admin role. We’d like the Org Admins to be able to 1) see the applications that are in their assigned orgs, 2) manage users in those applications and 3) be able to do a pre-launch checklist and flip those apps to Live when ready for production. The inability to do 1) makes 2) and 3) not feasible.

The ability to create an application permission has been created within the organization. However,  the ability to delete an application is tied to the default Admin role, we need that to be a separate permission

The filters used to search for blocks in the Block Store are now stored to improve the ease of use when finding blocks to install.

The request is to add Blocks to the company overview - who the owner/builder is, the organization location and sharing level (developer, orgs and developers, BB store).

Content Security Policy (CSP) and iFrame settings can now be configured for the Page Builder via the new security tab in the applications settings. However, this applies to the entire application and not single pages within the app to be iFrame compatible while others secured.

Certain form components needed to be changed to meet accessibility standards. Reassessment done by UW's accessibility team and a kb indicates the outcome and those items to avoid.

Currently, the user would need the Administrator role in both the originating organization and the destination organization to move an application from one org to another. A custom role would not have this capability. The request is to make this functionality a separate permission and not part of the Administrator role.

Currently, all of the capabilities under a single application>Settings>Options are functionality within the default Admin role, including the ability to change the application name. The request is to have separate permissions for each functionality.

Currently, all of the capabilities under a single application>Settings>Options are functionality within the default Admin role, including the ability to change the application identifier. The request is to have separate permissions for each functionality.

Currently, the permission to set/change the URL Hostname for an application is funcitionality within the default Admin role. The request is to have separate permissions for each functionality.

Add the ability to track which Application templates were used when creating an application such that if BB upgrades cause the need for a change or UW wants to change the standard templates/components, the service team can inform those to update if desired.

Currently, only the administrator role can make an application a template that is automatically available within the organization it is built

Proper governance

Currently, the user must have the default administrator role to add users to an application (e.g. an application is built and someone wants to add another developer or even tester at IDE level to that application.)

Currently, the ability to change user role at the application level (e.g. switch a user from Low-code dev to Bus Tech) is part of the default administrator role. The request is to separate this functionality into a permission.

Awareness for the service team of every user - Indication of the role(s) in each org and role(s) in each application for every user at that snapshot point in time

Currently, any Admin has the ability to create a custom role and specify permissions under User Management **at the application level**. Right now there are 3 default roles **at the application level**: Citizen Dev, Business Tech, Low coder. As Betty Blocks expands the permissions at the application level, we need a separate permission be able to create new custom roles and set permissions therein, instead of all of this functionality being tied to the Admin role.

Configuration values like passwords and API tokens can be exposed to user that should not know the credentials via output in an Action.

Currently, any Admin in an organization has the ability to create a custom role and specify permissions under User Management. This functionality is tied to the Admin role, but there isn’t a separate permission. Request: Make a separate permission at the customer and organization level allowing for the creation of custom roles (and assigning permissions to those roles).

Currently, the UW orgs have a hierarchy via name/process. The request is to have a way to flag orgs as Overarching, Parent, Child, etc.

Company Overview functionality and releasing blocks to company level fulfill need