Attention Scripters and Report Writers

Internal work on the xTuple ERP 3.8.0 release is winding down — the first release candidate was published a few weeks ago and a second RC and final release are coming soon. Now is the time to start planning for 3.9.

I don't know yet what features will be added in 3.9. There will be some internal changes, though, that you need to prepare for if you write scripts, MetaSQL statements, or reports.

The script toolbox will be simplified

Many methods in the script toolbox were marked as deprecated several releases ago. There are more direct ways to do the same things, and more, which are documented on both the deprecation listing and the Script Toolbox description. Please start updating your application extensions now so you don't have to scramble later.

Time permitting, we would like to expose more of the xTuple application and Qt to scripting (see issue 16459, for example). Whether we get to that or not depends on the priority of other features.

Backward-compatibility views will be removed

Way back in 2.x we created a dozen or so database views to ease migration to new features, like the then-new CRM module and the ability to write checks to Customers and Tax Authorities. These have long outlived their usefulness. Now they just cause confusion and performance problems.

The following views will probably be removed from the 3.9 xTuple databases and any remaining xTuple code that uses them will be updated. Please check your reports, MetaSQL statements, and application scripts to make sure they don't use these views:

Note that all of these were created for backward compatibility purposes. These are not the API views used for importing and exporting data.

Package schema support improvements

xTuple application extensions often need to refer to stored procedures, views, and tables in other extensions. For example, several bugs have been logged because xTuple Connect's Batch Manager is unaware of Project Accounting tables or Manufacturing Edition stored procedures. There are several steps required to alleviate this problem.

We'll take at least one step for 3.9: The database administrator will be able to set the database search path for all xTuple application users through the System Setup window.

If you are a package developer, this means that you will no longer need to set the search path yourself when the application starts (typically in an initMenu script) and you should not have to name the schema every time you refer to a table, view, or stored procedure. The benefits of this are that it will be easier to write extension packages and it will become possible to override more core functionality. On the other hand you will also have to be more careful about naming things - if your package has a view or table or procedure with the same name as an object in the core or another package, the one that will be used depends on the DBA's setting of the search path.

All stand-alone applications, like xTuple Connect's Batch Manager, will need to call the database function login() to see the revised search path.

You can start this work now:

The 3.7.x version of the xTuple ERP desktop client already has the scripting support necessary to replace the deprecated toolbox methods.

All of the 3.x databases have the underlying tables to replace the old backward compatibility views.

The login() function is in all of the 3.x databases, just waiting for your stand-alone application to call.

The changes should be pretty simple to make. You may not even need to do anything at all. We just wanted to give you plenty of time to fit whatever you need to do into your schedule.