Changed Behavior

Some existing behavior changes in this release.

App Builder UI Changes

Changes to the application builder user interface for this release include:

Export Wizard Changes

The Supporting Objects option in Advanced Options region of the Export Application Wizard is no longer available. If supporting objects exist in an application, they are part of the export.

To export an application without the supporting objects, use the APEX_EXPORT.GET_APPLICATION API or the SQLcl apex export command.

Translation Repository Data in the APEXlang Export

In APEX 26.1, applications that use the Application-Based translation method cannot be exported in APEXLang format. This limitation is removed in APEX 26.2.

When an application uses Application-Based translation, during the APEXLang export, the translation repository data is exported to a translations.sql file in the generated-artifacts folder. Files in this folder should not be modified manually.

When importing the APEXLang application, APEX automatically reads and installs the translation repository data from this file.

Interactive Report Search Bar Changes

The Interactive Report search bar behavior is changed with this release:

An automatic Interactive Report Reset button now displays when a user changes the report. This behavior can be toggled in the Component Settings for Interactive Report. The automatic reset button defaults to YES for new applications developed in APEX 26.2, and NO for existing applications.

When upgrading existing applications, the Application Upgrade utility disables developer-defined reset buttons with the following criteria:

Keyboard shortcuts for the Interactive Report search bar are also changed:

Substitutions in Report Settings

APEX supports substitution in the following report settings:

For both interactive report and interactive grid default reports:

For only interactive report default reports:

For only interactive grid default reports:

Raw JSON Support for Report Queries

Report Queries in APEX now support complex JSON structures, including hierarchical JSON and JSON columns, as raw JSON. This JSON is now passed directly to Document Generator, simplifying advanced document generation and reducing the need for PL/SQL workarounds.

Static ID Changes

As of APEX 26.2, you cannot save a value for the Static ID property if the value contains a Tab character.

Existing Static ID values that already contain a Tab character are not automatically modified. However, when you edit a component that contains a Tab character in its Static ID, APEX validates the value. You can’t save the component until you remove the Tab character.

This change applies to the following components:

“Enable RESTful Services” Instance Setting

The Enable RESTful Services instance setting and workspace REST setting now control APEX-managed schema REST enablement and schema-alias management for SQL Developer Web access.

Increased Security When Using Scopes and Tokens for OAuth Authentication of REST Web Service Calls

APEX 26.2 now enforces proper token re-use between calls and abides by the scope matching rules. If you use non-standard code to handle OAuth authentication of your calls to REST endpoints, those calls may fail.

For example, consider the following:

If the scope of the manually-requested token does not match the scope of the actual REST request, the APEX engine does not use it.

Custom PL/SQL code must be fixed so that OAuth scopes of manually requested tokens match scopes defined in the Web Credential and scopes used for making the REST request.

Use declarative OAuth authentication instead of custom code whenever possible.

Compatibility Mode

The application attribute Compatibility Mode controls the compatibility mode of the APEX runtime engine. Certain runtime behaviors change from release to release. You can use the Compatibility Mode attribute to obtain specific application behavior. This section lists Compatibility Mode changes by release. Note that all mode changes are inclusive in that all changes in older releases are included in newer releases.

Compatibility Mode Changes in Mode 4.1

In Oracle Application Express release 4.1, Automatic DML forms raised an error when rendering the page if the column name of the source of an item was invalid. Prior to Oracle Application Express release 4.1, an invalid column name of the source of an item would not raise an error when rendering the page but it would also not set session state of the item.

Also, in Oracle Application Express release 4.1, there are two new application Security Attributes to control Browser Security: Cache and Embed in Frames. Enabling the Cache attribute enables the browser to save the contents of your application’s pages in its cache, both in memory and on disk. The Embed in Frames attribute controls if the browser displays your application’s pages within a frame. Applications running in a Pre-4.1 Compatibility Mode function as if the Cache is enabled and as if Embed in Frames is set to allowed. Applications running in Compatibility Mode 4.1 or later respect the specific Browser Security attributes.

Also, in Oracle Application Express release 4.1, because of bug 12990445, the following changes were implemented for Automatic Row Processing (DML) process types. The code which performs the INSERT was changed to determine if the columns should be included in the INSERT statement. Note that these are the same checks which occur before an UPDATE. These new checks include:

To enable these behaviors, set the Compatibility Mode to 4.1 or later. For behavior that matches earlier releases, set the Compatibility Mode to Pre-4.1.

Compatibility Mode Changes in Mode 4.2

In Oracle Application Express release 4.2 due to changes for the new grid layout, when a page is rendered, all regions in a certain display point are evaluated before rendering that display point, to find out if they should be displayed or not (so that the grid layout knows how many columns to render). The regions where the evaluation returned true will be executed and displayed. However, this will not work if a PL/SQL based region sets session state which is then used in a subsequent region condition to determine if the region should be displayed. In that scenario, the condition has already been checked before the display point is rendered. Use computations or PL/SQL processes to set session state before any region is displayed. In previous versions, the condition was evaluated right before each region was displayed.

In Oracle Application Express release 4.2, computations and processes with a processing point Before Region(s) do now fire before any region gets rendered. Computations and processes with a processing point After Region(s) fire after all regions have been rendered. In previous versions, the computations and processes fired just before and after the region display point Page Template Body (1-3).

Oracle Application Express Patch Set 4.2.2 added two new Compatibility Mode changes for Compatibility Mode 4.2:

Prior to Oracle Application Express release 4.2.1, to protect against possible cross-site scripting vulnerabilities, you would have had to explicitly escape any column values in the report source, so that they could safely be used in JavaScript links. When running in Compatibility Mode 4.2, Oracle Application Express automatically JavaScript escapes column name substitutions referenced in JavaScript links if the column is defined to escape special characters.

To fix this, Oracle recommends that you remove the manual JavaScript escaping from your report source and use of the native escaping.

Compatibility Mode Changes in Mode 5.0

In Oracle Application Express release 5.0, referencing a Static Application File with #WORKSPACE_IMAGES# no longer returns the application file. Instead, use #APP_IMAGES#.

The API calls to wwv_flow_custom_auth_std.logout, wwv_flow_custom_auth_std.logout_then_go_to_page, wwv_flow_custom_auth_std.logout_then_go_to_url, and apex_custom_auth.logout are desupported and will raise a runtime error instead of logging out from the Oracle Application Express session. Instead, use the apex_authentication.logout entry point.

Prior to release 5.0, developers using data upload did not have the option to choose a date format. Instead, a parser checked for the best format to match the user’s entry or an end user could enter their own format. Oracle Application Express release 5.0 includes a new item that enables the user to choose an application date format or user entered format. Because applications created before release 5.0 do not have an item, a Compatibility Mode of 5.0 checks if the user has entered some data. If no data has been entered, it picks the application date format.

When a session timeout occurs and no timeout URL is specified, Oracle Application Express raises an error instead of redirecting to the application’s home page. If the session setup for an Ajax requests fails, Oracle Application Express also raises an error. For Ajax requests that expect JSON, the response is a JSON string with members that describe the error. For other requests, the error appears on an error page.

Page items based on a database column where the attribute Source Used is set to Only when current value in session state is null will raise an error when the page item gets rendered. Using this setting for a database column is very dangerous and can result in accidentally overwriting data when viewing and saving multiple records. Always set the Source Used attribute to Always, replacing any existing value in session state.

Compatibility Mode Changes in Mode 5.1 / 18.1 / 18.2

In Oracle Application Express 18.1, buttons where the Execute Validations attribute is set to Yes also perform some client-side validations (such as item required checks) and will not submit the page until all issues are fixed. In previous versions this flag was just used to determine if server-side validations should be executed.

Tip: Please pay attention when changing the Compatibility Mode to 5.1/18.1/18.2. Buttons, such as Cancel or Previous, where the Execute Validation flag has incorrectly been set to Yes and which use an After Submit branch, never execute validations when the user clicks the button. You can address this issue by using the new client-side validations, or by setting Execute Validations to No.

In release 5.1, any Ajax-based Dynamic Actions where the “Wait for Result” attribute is set to Yes perform an asynchronous Ajax call. Prior to 5.1, such calls would be made synchronously.

Compatibility Mode Changes in Mode 19.1

In Oracle Application Express 19.1, the Rich Text editor now enforces validation of the Max Length item attribute. When the length of the HTML markup exceeds the Max Length value, the system produces an error message.

Compatibility Mode Changes in Mode 19.2 / 20.1 / 20.2 / 21.1

In Oracle Application Express 19.2, Classic Reports render empty column values as an empty cell instead of using a “non-breaking white-space” ( ).

Compatibility Mode Changes in Mode 21.2 through 24.1

Prior to Oracle Application Express 21.2, all processes of the current processing point have been executed regardless of the added errors.

In Oracle Application Express 21.2, calling APEX_ERROR.ADD_ERROR in a process stops further processes from executing and immediately displays the inline errors.

Compatibility Mode Changes in Mode 24.2 / 26.1 / 26.2

Starting with release 24.2, APEX supports an extended substitution syntax for text messages: &{TEXT.MESSAGE}.

Enabling Network Services in Oracle Database

Database administrators must enable network services in Oracle Database to send outbound mail, invoke web services, or use template-based PDF report printing with external print servers in Oracle APEX.

Note: Enabling network services does not apply to APEX instances running on Oracle Autonomous AI Database. APEX can communicate with external endpoints over the internet without additional configuration.

When and Why Network Services Must be Enabled

Enabling network services enables support for sending outbound mail in Oracle APEX, using REST Services, REST Enabled SQL, or other web services, and using a remote server for report printing.

By default, the ability to interact with network services is disabled in Oracle Database. Therefore, you must use the DBMS_NETWORK_ACL_ADMIN package to grant network connect privileges to the database user that owns the APEX schema (APEX_260200). Failing to grant these privileges results in issues with:

The granted network connect privileges apply to the entire APEX instance and enable all applications in all workspaces to perform outbound network calls. You do not need to grant network connect privileges to individual workspace schemas unless applications also use native database PL/SQL API such as UTL_HTTP and UTL_SMTP.

Note: To isolate outbound network access by workspace/schema, set the WEBSERVICE_USE_SCHEMA_ACL instance parameter to Y. Supported outbound network calls then use the network connect privileges of the application’s parsing schema or the calling schema instead of the shared APEX engine schema.

Note: When upgrading APEX, the upgrade automatically configures Network Services based on the configuration of the previous APEX version.

Tip: To run the examples described in this section, the compatible initialization parameter of the database must be set to at least 11.1.0.0.0. By default, the parameter is set properly, but a database upgraded from a version prior to 11g may require an update. For information about changing database initialization parameters, see Specifying the Database Compatibility Level in Oracle Multitenant Administrator’s Guide.

See Also: About Report Printing in Oracle APEX App Builder User’s Guide.

Granting Connect Privileges

The following example demonstrates how to grant connect privileges to any host for the database user that owns the APEX schema (APEX_260200). This example assumes you connected to the database where Oracle APEX is installed as SYS specifying the SYSDBA role.

BEGIN
    DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
        host => '*',
        ace => xs$ace_type(privilege_list => xs$name_list('connect'),
                           principal_name => APEX_APPLICATION.g_flow_schema_owner,
                           principal_type => xs_acl.ptype_db));
END;
/

The following example demonstrates how to provide less privileged access to local network resources. This example enables access only to servers running on the same database host (localhost), such as email and report printing servers.

BEGIN
    DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
        host => 'localhost',
        ace => xs$ace_type(privilege_list => xs$name_list('connect'),
                           principal_name => APEX_APPLICATION.g_flow_schema_owner,
                           principal_type => xs_acl.ptype_db));
END;
/

Troubleshooting an Invalid ACL Error

Learn how to identify any invalid ACL error by running the query.

If you receive an ORA-44416: Invalid ACL error after running the previous script, use the following query to identify the invalid ACL:

REM Show the dangling references to dropped users in the ACL that is assigned
REM to '*'.

SELECT ACL, PRINCIPAL
  FROM DBA_NETWORK_ACLS NACL, XDS_ACE ACE
 WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL AND
       NACL.ACLID = ACE.ACLID AND
       NOT EXISTS (SELECT NULL FROM ALL_USERS WHERE USERNAME = PRINCIPAL);

Next, run the following code to fix the ACL:

DECLARE
  ACL_ID   RAW(16);
  CNT      NUMBER;
BEGIN
  -- Look for the object ID of the ACL currently assigned to '*'
  SELECT ACLID INTO ACL_ID FROM DBA_NETWORK_ACLS
   WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;

  -- If just some users referenced in the ACL are invalid, remove just those
  -- users in the ACL. Otherwise, drop the ACL completely.
  SELECT COUNT(PRINCIPAL) INTO CNT FROM XDS_ACE
   WHERE ACLID = ACL_ID AND
         EXISTS (SELECT NULL FROM ALL_USERS WHERE USERNAME = PRINCIPAL);

  IF (CNT > 0) THEN

    FOR R IN (SELECT PRINCIPAL FROM XDS_ACE
               WHERE ACLID = ACL_ID AND
                     NOT EXISTS (SELECT NULL FROM ALL_USERS
                                  WHERE USERNAME = PRINCIPAL)) LOOP
      UPDATE XDB.XDB$ACL
         SET OBJECT_VALUE =
               DELETEXML(OBJECT_VALUE,
                         '/ACL/ACE[PRINCIPAL="'||R.PRINCIPAL||'"]')
       WHERE OBJECT_ID = ACL_ID;
    END LOOP;

  ELSE
    DELETE FROM XDB.XDB$ACL WHERE OBJECT_ID = ACL_ID;
  END IF;

END;
/

REM commit the changes.

COMMIT;

Once the ACL has been fixed, you must run the first script in this section to apply the ACL to the APEX_260200 user.