Calculated Fields: Do the Right Thing!!!
In order to give users a better user experience, and to continue to tighten security for our customers, there will be some changes to calculated fields. In a future release, the application will strictly adhere to the data type setting on the calculated field. Currently, if you had a field defined as one data type but were using it as another data type, we needed to do special processing with legacy reporting in order to make the field render correctly. For example, a calculated field that uses FormatNumber should be defined as a string field, not a number field. This resulted in inconsistent behavior between fields in the UI and fields in reports. See Functions for a list of functions and their correct data type. Some common misconfigurations are:
Examples of expected changes:
With regard to security, when HTML was used in the formula, but the calculated field was defined as a string (instead of using the HTML display type), we were not able to guarantee against cross-site scripting, even with Strict XSS Protection enabled. There will be no impact on fields that are configured correctly. |