Version 8.0 Platform Release Notes

See also:

Release Notes for all versions
Doc Notes for documentation changes.

1 Major Enhancements

1.1 For Users and Designers

More Intuitive GUI

The new Designer section in the navigation pane contains everything having to do with customizing things--objects, classes, and every other component of an application. The new Settings section contains traditional profile information for the individual and the company. That arrangement provides a more intuitive and useful experience both for application designers and application users, since:

a. Designers can find everything in one place.

b. Users are no longer distracted by customization features when adjusting their settings.

Inline Editing in Grid View: In a List View, double-clicking on a record opens that row for editing. Not all fields are editable in this version, but many are, and more are coming. (Press Enter to save your changes, Esc to abort.); Learn more: Inline Editing of a List View.

New Social Networking Feature, Relay

Relay is an API-enabled collaboration feature that allows users in a tenancy to collaborate by:

Following feeds by individuals
Setting up groups
Following group feeds
Following document feeds
Following record feeds

Multiple Unique Indexes: A Custom Object can now have multiple unique indexes. (Previously, there could only be one.)

Presentation Pages: Custom JSP pages can now be defined for Create, Read, Update, and Delete operations on object records. (Previously, only the platform's default layout was used. A user could control which fields were displayed, and their order, but could not fully customize the layout.)
Learn more: Presentation Pages

New Form Option: On (Field) Change, Reset (Lookup) Field(s); When defining a form layout, the wrench icon adjacent to a field can be used to select Lookup fields that should be reset whenever the current field changes. This operation is used when field values "cascade". For example, a choice of delivery method (online delivery or physical shipment) may change the choice of subsidiary options: For online delivery: email or download. For physical shipment: US Mail, Fedex, or UPS. So, when the user changes their choice of delivery methods, the list of subsidiary options needs to change, as well.; The choice is available for a variety of field types, including Button, Checkbox, Lookup, Multi Checkbox, Pick List, Multi Select Picklist, and Radio. When chosen, a list of available Lookup fields is displayed. You choose which ones to reset.; Learn more: Forms

Multi-Object Lookups: It is sometimes the case the first choice needs to select the target object for a lookup, after which a record can be chosen. For example, a distributor might take orders for products that come from different catalogs, where each catalog is provided by a different supplier. The Multi-object Lookup field type makes it possible to handle that situation by allowing the order taker to first choose the catalog the product is in, and then choose the product from that catalog.; Learn more: Multi Object Lookups

Multi-Value Lookups

Previously, a Lookup field could only be used to select a single value. That functionality was perfect for a many-to-one relationship like Orders to Customers (an order can have only one customer). But it was not ideal for a many to many relationship like Orders to Tags (an order can have multiple tags: say, "Rush" and "Linux"). Now, however, whenever there is a junction table between two objects (forming a many-to-many relationship), a multi-value lookup field automatically appears in the Form list (It does not appear in the Field list.) Once dragged into the form, the user can make multiple selections in the field.

Learn more:

View/Report Lookups for Dropdowns: In a Lookup field, it is now possible to let the user select the target record from a view or report for a Dropdown list, as well as for a Popup window. (As with the Popup selection, the View/Report option only appears when the target object is a Custom Object.); Learn more: Record Selection Information, View/Report

Hierarchical Lookup Views for Self-Referencing Objects: When an object has a Lookup field that references itself, it is possible to display the values in a hierarchy, so that users have an easier time making a selection. For example, if a Location object has the fields Type (city, state, country), Value (San Francisco, Dusseldorf, California, Germany, etc.) and Parent (self-referential Lookup), then the record with city=San Francisco can look up to state=California, by way of the Parent field. With those relationships established, a Hierarchical Lookup can be used to give the user a tree-structured list of states and countries, with the cities under them.; Learn more: Record Selection Information, Hierarchical View

Referential Formula Fields: In object Formula Fields, Validations, and Action-Based Data Policy criteria, a Lookup field defined in the object can now be used to reference a field in a related record. If an Orders object looks up to a Customer object, for an example, then a formula operating on a particular Orders record can use the lookup field customer access the credit_rating field in the associated Customer object, using dot-notation syntax: customer.credit_rating; Learn more: Referential Fields

LOOKUP Function in Formulas: In object Formula Fields, Validations, and Action-Based Data Policy criteria, a lookup can also be performed to an unrelated object, using the new LOOKUP function.; Learn more: LOOKUP function

GUI Enhancements

A Custom Page can now be designated as the start page for an application in the Application Settings.
A role-specific start page can be designated, as well, in the Default View Preferences.
It is now possible to view Report Data in a new tab.
In a record-list view, it is now possible to do an alphabetic search. Such a search will return records in alphabetic order--but only if the records being displayed are currently sorted on the field being searched. (To use it, first sort the view on the field you want to search, then choose the Alphabetic Search option.)
Custom JSP Pages work better in the dashboard:

Browser plugins that prevent iFrames from displaying no longer interfere with the dashboard display.
Links to other pages now load as expected, instead of loading into the iFrame that displays the custom page.
For the technically minded:
The pages are "inlined" by merging them into the DOM, rather than being displayed in iFrames.

1.2 For Developers

New and Improved Eclipse Plug-In: The Eclipse Plug-In has been enhanced. File synchronization capabilities have been improved and, when libraries are downloaded from the platform, a complete suite of API stubs ensure the programs can be made to compile successfully in Eclipse, before uploading them to the platform for testing.

Unit Test Framework for Java Code: It is now possible to set up Unit Tests for Java Code. Tests on all classes and on individual classes can then be run from the GUI.; Learn more: Unit Test Framework

Package Data: It is now possible for any developer to include Package Data when creating a package. Typically, object records are included, but the mechanism allows for arbitrary kinds of data.
To support that operation, a [New Package Data] button has been added to Settings > Administration > Global Resources > Developer Configuration.

Package Dependencies: When defining a package, dependencies on other packages can be specified. It will not be possible for a user to subscribe to that package until the dependent packages have been installed.

Bypass Data Policies when using APIs: When using an API to add, update, or retrieve a record, it is now possible to bypass data policies. (For example, if the program is incrementing a counter, and a data policy was doing that as well, bypassing the auto-increment in the data policy would prevent the counter from being incremented twice.); Note: This experimental feature was deprecated in version 8.1

Schedulable Jobs: A class that implements the Schedulable interface can be scheduled either in the GUI, or by using the appropriate REST APIs.; Learn More: Job Scheduler

2 Significant Changes

2.1 For Users and Designers

Data Policy Changes

Record-Retrieval Data Policies: Data policies can be applied when records are accessed, as well as when they are updated. Such data policies can be used to modify search criteria before doing the retrieval (for example, to limit the records returned) or to modify the data before it is returned (for example, to mask social security numbers or salary information).; Learn more: Data Policy example: Mask Outgoing Data

Data Policies Defined for Workflow State-Change (location change): As before, data policies can be triggered when a record's workflow-state is changed. It is no longer specified in the Workflow Designer, however. Instead, it is specified along with other possible activation triggers, as part of a Data Policy definition.

More Flexible Data Policies for Workflows: As a result of the reorganization, multiple data policies can be triggered by a workflow state change, using both PRE- and POST- triggers.

"Execute Java Code" replaced by "Invoke Java Method": In previous versions, it was possible to define a snippet of Java code to execute for a data policy, without defining a class or method for the code to live in. For backward compatibility, old code that was written in that manner can still be edited, but it is no longer possible to write new code of that kind. That restriction produces several significant benefits for serious development efforts:

Eclipse plug-in integration. Code snippets that live behind the scenes don't integrate well with the Eclipse Plug-In. Even if they were given names, the names would of necessity be unreadable hieroglyphics to prevent naming conflicts. The lack of meaningful names would then make it very difficult to find the code you're looking for. The solution is to let the developer provide meaningful names--in other words, to let the developer define classes and methods.

Unit test capability. The new test harness for Java code works with Java classes. So requiring data policies to invoke methods in Java classes both encourages and allows for significant improvements in provable code quality.

Learn more: Invoke a Java Method From a Data Policy

Sites error handling. As part of a Site definition, it is now possible to specify the File Not Found page and the general Error page, to further customize the user experience.

Learn more: Site Properties

GUI Changes

Under Settings > Administration the entry previously titled Views Management is now called Views and Reports, to reflect that fact that reports are also managed there.
The Locked Package Item Validation option is no longer present for:

Application update
Application Role Tab Preference update
Application Role View Preferences update

2.2 For Developers

Changes to Java Classes: Methods that live in Java classes can be tested, and they can be developed more easily using the Eclipse plug-in. But to get those benefits, some changes are needed in the way classes are coded. (These changes are required for any new classes you create, to encourage movement in that direction.)

Import platform APIs explicitly.

Add the following line to every class:

import com.platform.api.*;

For any class that uses the platform's Java Beans, add this:

import com.platform.beans.*;

Invoke methods in the Functions class explicitly

Code Functions.method() for any method() defined in the platform's Functions class. (For example: Functions.debug(), or Functions.getParametersInstance().)

(As an alternative, you can add a global import to make existing code work, without change:

import static com.platform.api.Functions.*;

That practice is not recommended, however. It's preferable to use the Functions. prefix, so anyone reading the code can see where the invoked API is defined. But for a fast conversion of many classes, the import static statement is a quick fix.

Changes to Platform Packages

All classes and interfaces used to access and interact with the platform are now in one of two packages:

com.platform.beans - All Java beans containers.
com.platform.api - All other classes and interfaces.

Considerations:

The Functions class is in com.platform.api.
An existing class or function that is running in the platform does not need to make any changes to code that invokes the debug() method, or any other method defined in the Functions class. Those references are automatically resolved.
But to work in Eclipse, as previously noted, the import statement needs to be added and explict references need to be made (to Functions.debug(), for example).
Code references to earlier version of platform classes need to be modified to use the new pacakges. For example:

com.es.common.MultipartData --> com.platform.beans.MultipartData
com.platform.packaging.PackageItemType --> com.platform.api.PackageItemType

For the available classes and interfaces, see the javadocs.

Other Changes to Java Code

Execute Java Code in Data Policies has been deprecated in favor of Invoke Java Method.: Existing Data Policies will work, but to create new data policies that run Java code, it will be necessary to invoke a method in a class. (For more, see the section above, Significant Changes for Users and Admins.)

Functions will be deprecated in 8.1.: Existing functions will continue to work after that, but it will not be possible to create new ones.

To prepare for the changes ahead, and to take full advantage of the Eclipse plugin and the platform's testing capabilities:

Convert your Functions to stubs that delegate to methods defined in a class.
Do the same thing with old data policies or, better, replace them with new data policies that use Invoke Java Method to access the methods directly.

Learn More: See the Eclipse_Plug-In page, with particular attention to the section on Migrating Classes for Use in the Plugin.

Package Roles and Object Permissions: When roles are included in a package, object permissions defined for those roles are now carried forward. (Previously, they weren't.) When a package contains no roles, the subscriber is given the ability to grant permissions to existing roles. In both cases, object permissions are no longer automatically granted to all users in the subscriber's tenancy. (Something which used to happen, with the result that completely unrelated users had unexpected new objects appearing in their object lists.); Learn more: Package Considerations

Sites Error Handling: Previously, errors sometimes produced a 404 file not found error, and sometimes a 500 error. Now, they consistently produce a 404 error, by default. In addition, developers can specify a custom JSP page for File Not Found errors, and one for General errors.

Retrieve Record Permissions: When retrieving a record or searching for records, it is now possible to retrieve the logged in user's permissions for that record. That capability is useful when building a user interface to determine which buttons to display. (For example, don't show the delete button if the user doesn't have delete permissions.); Learn more: Retrieving record permissions in REST and in Java.

Validation of Package Names in Java Classes: When Java classes are saved to the platform, their package statements are now fully validated to ensure that the package name starts with com.platform.{namespace}, where the namespace is defined in the tenancy's Developer Configuration settings.

Packaging Changes

Locked Packages are More Secure: Subscribers who install a locked Package can no longer view, edit, or delete any classes, components, data policies, functions, pages, or any other form of executable java code contained in the package.

Simplified Publishing: The Publish Package no longer collects publisher data or a screenshot.

Open Package Listings: To publish a package, it is no longer necessary for a tenant to have Designated Catalog Tenant status. Any package, published by any tenant (except an MSP or MSP Client) will be automatically submitted to the ISV for approval. Once approved, it shows up in the ISV's application catalog.

Javadocs and Constants for API users

Javadocs for platform APIs are available. In addition, a new CONSTANTS class makes it easier to use standard constants in your code.
Learn more:

New Reserved Words: These Reserved Words were new in the 7.1 version of the platform, but were not added to the documentation until after the release:

ACCESSIBLE
CONNECTION
GOTO

LABEL
LINEAR
MASTER_SSL_VERIFY_SERVER_CERT

RANGE
READ_ONLY
READ_WRITE

UPGRADE

3 Java API Changes

Global Picklist APIs: These new APIs let you programmatically manage global picklists.

Java_API:Record_Handling#deleteRecord

Use this new API to programmatically delete records, as well as add and update them.

importData: This new API makes it possible to programmatically import CSV data into an object. An import job is scheduled when it is invoked (typically for immediate execution), so that the actual import goes on in the background.

SearchContext Class: This new class makes it easier to formulate complex queries. Use its APIs to build a search query, one part at a time, and have the syntax of each part checked independently.

Schedule/Delete A Job: Use the job scheduling APIs to schedule or delete a job that runs in the background, at specified intervals. Execution can be scheduled for any class that implements the Schedulable interface.

4 REST API Changes

4.1 Global Changes to REST APIs

UTC Format for Dates

These changes bring the REST APIs into conformance with the W3C XML Schema for Datatypes.

All REST resources now return dates in UTC Format.
All dates specified in REST requests and search queries need to be specified in UTC Format, as well.

Learn more: Date/Time Search

4.2 Resource Changes

bulk Resource

Object names can now be specified in the REST URI, as well as object IDs.
The documentation has been improved to list the system objects that can be bulk-uploaded, and to specify the object name to use.
The sample code for bulk uploads now includes the login process.

customPage Resource

The include_header_files field has been added to determine whether or not to auto-include the platform's CSS files and jQuery javascript libraries in the page header.

execResource: When executing a Java method, it is now possible to execute a method that returns void, as well as a method that takes no arguments.

To make sure that the signature invoked is the signature that was intended, it is no longer the case that an empty Parameters object is constructed when the REST exec call has no arguments. (In the past, an empty object was sent to the method, which was required to have a Parameters argument in its signature, despite the fact that the argument was never used.) So if the request looks like this:

<execClass>
   <clazz>...</clazz>
   <method>myMethod</method>
</execClass>

Then the platform looks for a method that looks like this: myMethod().

With the new implementation, a signature that has a Parameters argument won't be found if the exec request contains no method arguments. It will look for a signature that has no arguments, and generate an error when the signature isn't found. So if the method signarure looks like this: myMethod(Parameters p), an error occurs.

To prevent that problem, do one of the following:

Remove the Parameters argument from the method signature. (Generally the ideal solution.)
Create a myMethod() delegator that invokes myMethod(null). (Sometimes necessary, if the existing signature needs to be preserved for other reasons.)
Add a "null" parameter to the argument list, so the existing signature is found. (Useful if the arguments are optional, and have default values if not found.) For example:

<execClass>
   <clazz>...</clazz>
   <method>...</method>
   <null></null>
</execClass>

globalPicklist Resource (new): Programmatically manage global picklists.

import Status Resource (new): Check the status of an import job.

package Resource

The package deploy resource has been added.
The package upload API has been deprecated, in favor of subscribe.

packageDeploy Status Resource

scheduledJob Resource (new)

Manage scheduled jobs that run in the background, at specified intervals.

tenant Resource: Tenant resource APIs now take a {tenant_id} parameter, for compatibility with other APIs (in particular, tenantCapabilities). For backward compatibility, {record_id} values are still supported, but their use is deprecated. (The platform assumes that an incoming argument is a tenant ID. If that lookup fails, the value is tried as a record ID.)

user Resource

The following fields have been added:
- team_id - User's primary team
- role_id - User's role in their primary team
- password - User's password (Not returned. Can be specified on create/update.)
- force_password_change_on_login - Typically used when pre-setting a default password.
- date_format - Specify the Date Format in which a GUI user enters and views dates and times.

Learn more: user Fields

5 Deprecated Functionality

5.1 AJAX APIs Deprecated

AJAX APIs are being phased out. For backward compatibility, previously existing APIs continue to work in this release, but they are not being extended or enhanced. In a future release, support may be discontinued entirely. To interact with the platform, use AJAX and REST, instead.

5.2 Standalone Functions Deprecated

Standalone Functions are being phased out. Existing functions continue to work in this release, but it is no longer possible to create new ones. In a future release, support may be discontinued entirely. For equivalent functionality, define methods in Java Classes.