Contents
New
Additional control over app security settings
Realm admins now have an additional layer of control over sensitive permissions. From the Policies page in the Admin Console, realm admins can allow or disallow app admins to modify app security options found on the App properties page. See the related help article for more information.
This feature will be available to customers on an Enterprise plan.
RESTful APIs: Un-deny users endpoint
As announced in January’s release notes, we continue to add to our user management RESTful APIs. When a user is assigned a “denied” status, they cannot access apps until the denied status is revoked. Now, you can programmatically restore users’ access individually or in bulk using this new endpoint
To learn how to use the new endpoint, refer to the Users section of our RESTful API guide.
Platform analytics: Integration reads details
You can now view your integration reads in platform analytics. This includes information such as Connection owner, Owner ID (User), Action, etc. Learn how we measure integration reads in our help center.
Enhancements
Local time zone in Pipelines
All Pipeline pages display the time zone local to users viewing the page. To make time readable for users around the globe, it appears in this format:
4:00 PM (UTC-05:00)
We determine the local time zone based on the browser in use, so in some cases this might not work correctly, such as if the user is using a VPN.
PATCH endpoint support for SCIM APIs
To improve our customers’ experience with automated user provisioning, we will begin supporting the PATCH endpoint for our SCIM APIs with this release. For example, you can use the new PATCH endpoint to deny users and edit other user attributes. To learn more and see examples of how to use the PATCH endpoint, see our HTTP API Reference.
New RESTful API properties
We’ve made the following improvements to our existing RESTful APIS:
- Deny users – There is an optional query parameter to specify the account id. This is used in cases where there is one realm with multiple accounts.
- Get an app – A response message will return the state of all app security settings. These are the settings found in App settings > App properties > Advanced settings.
- Update an app – There are optional query parameters to update app security settings, found in App settings > App properties > Advanced settings.
Revised help center
Soon we’ll debut a completely revised help center at help.quickbase.com. This will enable you to find the help you need when you need it. Improvements include a completely new look-and-feel, enhanced navigation, improved search, and revised help content, including new visuals and use cases. All links to existing help content will continue to work.
New apps created from spreadsheet default to new dashboard
Note: This feature encountered an issue in the release process. As of March 13, 2022, it is unavailable and will be enabled in the coming weeks.
When users create an app by importing a spreadsheet, Quickbase will automatically create a New Dashboard for that app. Previously, a legacy homepage was created.
Increased subscription recipient limit for Enterprise Accounts
For customers on our Enterprise, usage-based plans we have increased the recipient limit a single subscription email can send to from 4K to 10K.
Note: This does not affect the limit on the total number of subscriptions and reminder emails each account can send each day. See the Quickbase limits page for more information.
Terms of Service and Privacy Policy reacceptance for all existing users
After April 4, every Quickbase user will be asked to reaccept our existing Terms of Service and Privacy Policy. This will happen upon all users’ next authentication.
Important: We are not changing anything in our existing Terms of Service and Privacy Policy. We are doing this to ensure compliance with legal requirements and to provide a path for all end-users, using different types of login flows, to acknowledge our policies.
Open beta
New chart styles
After the March release, all users will be able to toggle on the New chart styles in their apps.
Updated charts use screen space more efficiently, so you can view and understand your data more easily and focus on details. After you enable the new style, you can hover over a chart segment and see details about the underlying data.
Beta opportunities
| FEATURE | DESCRIPTION | STATUS | HOW TO PARTICIPATE |
|---|---|---|---|
| Report settings panel – Kanban | Update report settings more quickly for your Kanban reports using our new report settings panel. | Beta | Sign up in our early access app. Select Building Apps under Program Area. |
| Pipelines permissions | Grant more precise permissions for building pipelines. | Beta | Sign up in our early access app. Select Platform Administration under Program Area. **This beta will open end of March.** |
| Procore Channel in Pipelines | Builders can now connect to Procore, the leading construction project management software. Mutual customers can now trigger, create, update, query, and delete data within Companies, Projects, RFIs, Users, Roles, Vendors, Budgets, and more. | Beta | Reach out to your Customer Success Manager, or ask to get included by messaging us in our Quickbase Community slack workspace in the #pipelines channel. |
What’s fixed in Quickbase
We continue to focus on quality. Below are the issues we fixed this month.
Note: Platform security, billing changes, back-end tooling, and performance are all ongoing commitments. Each release may include changes in these areas.
| ISSUE | AREA AFFECTED | DESCRIPTION |
|---|---|---|
| QBE016165 | UTF-8 | If UTF-8 was enabled at an app or realm level, and you used special characters in an app’s name, the characters would display correctly in a tab, but not in the Apps list on the Admin Console. |
| QBE016167 | UTF-8 | Using an accented character in a group name would result in an error. |
| QBE016192 | UTF-8 | When you added accented characters to a data classification, they would display incorrectly in the data classification and its description. |
| QBE016707 | Pipelines | Customers could not create a pipeline if they had reached their maximum of 30 tags (even if they provide no tags along with the creation flow). |
| QBE016749 | Audit logs | When users tried to view audit logs, they saw an "Error fetching audit data" message. This message no longer appears. |
| QBE016775 | Audit logs | User could not move the date picker. |
| QBE016779 | UTF-8 | We didn’t support non-ascii characters in group names. |
| QBE016780 | Pipelines |
Time zones were not displayed consistently in Pipelines. |
| QBE016070 | Reports | On the new dashboard a widget error did not display when a user went to add a chart that had a summary or report formula with a percentage symbol in the field name. |
| QBE016776 | Audit logs | Non-western characters were mangled on the Audit Logs page. |
| QBE016786 | Audit logs | Add/delete users/groups in Sandbox were added to the audit logs incorrectly. |
| QBE016788 | Security | When customers used SSO, end-users did not have a section to accept our terms of service before accessing the platform. |
| QBE016791 | Reports | When UTF-8 was enabled at an app or realm level, and a user used a non-English word as a record name, table reports would display any UTF-8 characters incorrectly, and incorrectly pluralize the record name by appending an “s.” Now, the record name appears correctly and uses a singular word followed by “records.” For instance, an error statement might read “there aren’t any niño records in your app yet.” |
| QBE016793 | Forms & Records | When UTF-8 was enabled at an app or realm level, and a user used a non-English word as a record name, forms and records would display any UTF-8 characters incorrectly. Now, when you’re saving a record, the characters appear correctly. For instance: “Niño saved”. |
| QBE016794 | Table settings | When UTF-8 was enabled at an app or realm level, and a user used a non-English word as a record name, the table settings page would display any UTF-8 characters incorrectly, and incorrectly pluralize the record name by appending an “s.” Now, the record name appears correctly and uses a singular word followed by “records.” For instance, an error statement might read “there aren’t any niño records in your app yet.” |
| QBE016795 | Chart reports | When UTF-8 was enabled at an app or realm level, and a user used a non-English word as a record name, chart reports would display any UTF-8 characters incorrectly, and incorrectly pluralize the record name by appending an “s.” Now, the record name appears correctly and uses a singular word followed by “records.” For instance, an error statement might read “there aren’t any niño records in your app yet.” |
| QBE016796 | Import/Export | When UTF-8 was enabled at an app or realm level, a user used a non-English word as a record name, and navigated to the import/export dialog through the More menu in the actions bar, any UTF-8 characters in the record name would display incorrectly. Now, the record appears correctly. |
| QBE016321 | Import/Export | When UTF-8 was enabled at an app or realm level, a user used a non-English word as a record name, and tried to import data from a file, any UTF-8 characters in the record name would display incorrectly. Now, the record name appears correctly. |
| QBE016798 | Email notifications | When UTF-8 was enabled at an app or realm level, a user used a non-English word as a record name, and tried to set email notification conditions, UTF-8 characters in the record name would display incorrectly and incorrectly pluralize the record name by appending an “s” in a variety of places in the menu. Now, the record name appears correctly and uses the singular record name followed by “records.” For instance, an error statement might read “there aren’t any niño records in your app yet.” |
| QBE016799 | Webhooks | When UTF-8 was enabled at an app or realm level, a user used a non-English word as a record name, and tried to set up webhooks, UTF-8 characters in the record name would display incorrectly. Now, the record name appears correctly. |
| QBE016264 | UTF-8 | If UTF-8 was enabled at an app or realm level, and you added a field value that contains an accented character to a custom rule (for view or modify), the value would be either mangled or missing after you saved the custom rule and reopened it later, although it displayed correctly in the picker. This also meant the custom rule didn’t work. |
| QBE016189 | UTF-8 | If UTF-8 was enabled on an app or realm level, non-western characters that appeared in audit log rows displayed as mangled. |
| QBE016517 | UTF-8 | If UTF-8 was enabled on a realm level, and you created an email reminder that used non-ASCII characters in its subject and message, then saved and reopened the reminder in preview, the non-ASCII characters display incorrectly in the app name, subject, and message. |
| QBE016804 | New style table report |
This fix continues work from QBE016637 and addresses glitches around saved reports and filters. Now, when users apply filters and add a new record, records appear correctly on the filtered report. This fix also resolves:
|
| QBE011449 | Relationships | Conditional dropdowns based on a derived field did not evaluate or filter until after you saved or applied the changes. A fix for this issue will be rolling out the days following our release |
International Mobile Fixes
As part of our ongoing commitment to serving an international audience, we identified and fixed a number of issues related to how Quickbase mobile apps handle UTF-8, or non-ASCII, characters.
| ISSUE | DESCRIPTION |
|---|---|
| QBE016527 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for an app’s name, then accessed the app from the “My apps” screen, the characters were mangled at the top of the default Mobile App dashboard for your role. |
| QBE016539 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for a dashboard name, when you accessed the dashboard, the name would appear mangled. |
| QBE016540 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for the widget titles on a dashboard, the characters would look mangled for all the widget tiles when you accessed the dashboard. |
| QBE016541 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for some of the button labels on a dashboard, when you accessed the dashboard, the characters would be mangled on the button labels. |
| QBE016542 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters in a report name, they would appear mangled when you viewed them on a dashboard. |
| QBE016543 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for a rich text widget on a dashboard in an app, the characters in the rich text widget are mangled whenever you view the dashboard. |
| QBE016544 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for a link bar widget on a dashboard in an app, the characters in the link bar widget’s link labels appear mangled when you view the dashboard. |
| QBE016545 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for a dashboard’s search widget label and the help text inside the search box, I have UTF-8 turned on at the realm level, the characters appear mangled for both the search widget label and help text when you access via iOS. When accessing via android, only the help text appears mangled. |
| QBE016547 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for a table name, then access the table from the app’s table list, all table names that use non-ASCII characters are mangled. |
| QBE016548 | If UTF-8 was turned on at a realm level, and you used non-ASCII characters for a table name, then access the table list and tap the search, all table names with non-ASCII characters are mangled on the search list. |
| QBE016549 | If UTF-8 was turned on at a realm level, and you used non-ASCII characters for a table name, then access the table list and tap the search icon and search for a table, any tables that non-ASCII characters in their name and appear in search results are mangled. |
| QBE016550 | If UTF-8 was turned on at a realm level, and you used non-ASCII characters for a table name, then locate and open the table from the table list, the table’s name displays incorrectly on the table home page. |
| QBE016551 | If UTF-8 was turned on at a realm level, and you used non-ASCII characters for a table name, then locate the table in the table list, and click the Reports icon for that table to access that table’s reports and charts view, the table name displays as mangled on that page. |
| QBE016552 | If UTF-8 was turned on at a realm level, and you used non-ASCII characters for a table name, then locate the table in the table list, and click the Reports icon and open the dropdown table selector to see other table’s reports and charts pages, the other tables will appear mangled if they include non-ASCII characters. |
| QBE016553 | If UTF-8 was turned on at a realm level, and you used non-ASCII characters for the names of some reports, then open the table list and click the Reports icon and open a table’s Reports and Charts screen, the screen displays any report names with non-ASCII characters as mangled. |
| QBE016556 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for a few different data types that you created in desktop, then used those fields in a table report, those characters would appear mangled in the field data when you viewed the table report via the mobile app. |
| QBE016557 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for a few different field names that you created in desktop, then used those fields in a table report, the field names would appear mangled when you viewed the table report via the mobile app. |
| QBE016559 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for a few different field names that you created in desktop, if you viewed, added, or edited an existing record through the mobile app, the non-ASCII characters would appear mangled in any field names in which they were included. |
| QBE016560 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for field data in several different fields that you created in desktop, if you viewed or edited an existing record in the mobile app, all non-ASCII characters are mangled in the field data. |
| QBE016561 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for a few different field names that you created in desktop, then access the Recently viewed records screen on the mobile app, non-ASCII field names that appear on this screen were mangled. |
| QBE016562 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for the data in a few different fields that you created in desktop, then access the Recently viewed records screen on the mobile app, non-ASCII characters in field data were mangled on this screen. |
| QBE016563 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for an app’s name, then access the app from the app list in the Quickbase Mobile app, all app names that use non-ASCII characters are mangled. |
| QBE016564 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for a report name, if you viewed the report with the Quickbase mobile app, the report name was mangled where it appears above the report. This issue affected all Quickbase report types. |
| QBE016565 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for the X and Y axis labels and goal label in a chart report, the values would appear mangled when you viewed the report in a mobile app. |
| QBE016566 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters in a chart report’s data values, these data values are mangled when you viewed chart reports through the mobile app. |
| QBE016568 | If UTF-8 was turned on at the realm level, and you used the mobile app to enter non-ASCII characters into fields on a form and save the record, the data appears mangled. This problem affected text field types, address fields, and URL fields. Rich text field types were unaffected. |
| QBE016569 | If UTF-8 was turned on at the realm level, and you added users with non-ASCII characters in their first and last names to an app, then used a user or list-user field to select these users for a form, the non-ASCII characters in their names are mangled in the user picker. |
| QBE016570 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for a table name in an app, then searched that table in mobile and got no results for your search, the table name would appear below the search box and display as mangled. |
| QBE016571 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for data in a table’s records, then searched for those records in mobile and got no results for your search, a mangled string would appear next to the search box. |
| QBE016577 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters for the app and table names, and a report name on that table, then located and tapped the email icon at the top of the report to generate an email message. If you were using iOS, the app, table, and report name in the message were mangled for Outlook and Gmail. In Android, the message would look fine in Outlook, and would be occasionally mangled in Gmail. |
| QBE016578 | If UTF-8 was turned on at the realm level, and you used non-ASCII characters in a report link or for the link text in a formula URL field, the non-ASCII characters would appear mangled when you added the field or link to a form. |
| QBE016579 | If UTF-8 was turned on at the realm level, and you enabled sort and group on a table report for a field that had non-ASCII characters in one of its data values, then view the table report in the mobile app, the Group by header values with non-ASCII characters are mangled. This issue did not appear when you accessed Quickbase through Desktop. |
| QBE016580 | If UTF-8 was turned on at the realm level, and you used the mobile app to enter non-ASCII characters into fields on a form and save the record, the data appears mangled when you view it on desktop mode. This problem affected all text fields, address fields, and URL fields. |
| QBE016585 | If UTF-8 was turned on at the realm level and you tried to enter data in a form on a table while in offline mode by clicking Add for a table, then entered non-ASCII data to some fields and saved the record, then viewed the queue of data, all fields that included non-ASCII data were blank. This issue only affected the iOS app. |
| QBE016587 | If UTF-8 was turned on at the realm level and you used non-ASCII characters in several different field types on desktop, then switched to viewing records in mobile and tapped the Copy record icon, the non-ASCII data is mangled in the copied record. This problem only affected iOS. In some iOS instances, the non-ASCII data would also be mangled in the original record. |
| QBE016588 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for the "A Single record is called a" name, and tried to delete a record, the non-ASCII characters for the single record name would be mangled in the delete confirmation popup. |
| QBE016590 | If UTF-8 was turned on at the realm level and you created a form rule that hides another field on a form after you enter a specific string of non-ASCII characters into a text field, the form rule did not trigger and the other field was not hidden in iOS and Android, though the form rule behaves as expected when you use desktop. |
| QBE016591 | If UTF-8 was turned on at the realm level and you pointed a search widget on a dashboard to a table that includes non-ASCII strings in searchable fields, when you used the search widget to search a non-ASCII string, no results were returned. |
| QBE016594 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for the "A Single record is called a" name, then hovered over a chart report in the mobile app, the "A Single record is called a" would be garbled in the hover text. |
| QBE016596 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for values in multiple choice fields, when you selected the multiple choice field when adding or editing a record, the values with non-ASCII characters were mangled. |
| QBE016597 | If UTF-8 was turned on at the realm level and you used non-ASCII characters for values in multi-select choice fields, when you selected the multi-select choice field when adding or editing a record, the values with non-ASCII characters were mangled. |