After months of feature development and a short beta phase, REI3.12 is finally ready for release. Lots of new things to cover, let´s start with...
Visual PDF editor
With REI3.12 you can now design complex PDF files from inside the Builder.
While we had the option to generate PDFs for a long time, this required data & HTML processing and was not very approachable. It also only allowed PDF generation in the browser, which was quite limited.
The new visual PDF editor works by generating PDF files via the REI3 service; the application author creates templates in the Builder and REI3 generates PDF files when requested.
The PDF editor offers direct access to data via REI3 relations, similar to how forms work. You define what to access, join related relations and load additional data via list fields. Based on the selection, fields can be placed on the PDF to display data.
To support various use cases, we offer two layouting systems: Flows & grids. A flow serves large or conditional content - things like texts with multiple paragraphs or a range of fields, which are partly visible based on conditions. Flow layouts grow with their content, dynamically moving content on the page. In contrast, grids offer a fixed size grid to place content on directly; useful for fixed size elements like letter heads or footers. By combining flows & grids, most use cases should be addressable.
With support for mixed page layouts, recurring or separate headers & footers as well as conditional display states, the PDF editor can fulfill many complex requirements. In addition to that, many display/style options can be overwritten by data in relations. This allows for generic templates to be adjusted based on user choice - such as using different fonts/sizes, overwriting row coloring in lists and much more.
Native REI3 field content, such as uploaded image files, drawings for things like signatures as well as barcodes, can be used on the PDF directly or inside list fields. This allows for scannable inventory lists or placing the appropriate signature under a work order report.
While the new PDF editor should be the go-to for most PDF needs from this point on, the old PDF generation via HTML will continue to work. The old PDF generator also receives support for UTF8 fonts in this release, making it possible to generate PDFs in languages such as Japanese or Thai.
We are happy to finally release this feature, which was cooking for a long time. We are looking forward to seeing what you build with it.
New change log viewer
REI3 always had change logs - it´s a core feature for any application dealing with business data. While capabilities of the REI3 platform were growing, the change log viewer did not keep pace however. This changes now; REI3.12 includes a completely redesigned change log viewer.
The new viewer not only is better suited for large change sets, it can show changes from different records at the same time. Example: A form shows an invoice document with many invoice positions. The old viewer would only cover changes to the record, directly loaded in the current form - ie. the invoice document itself. We would see a changed document date or invoice number, but nothing more. The new viewer checks if there are other related records loaded on the current form, such as the invoice positions. Now, everything shown in the invoice position list on the same form will also be covered:
That is not all however. In addition to related records (such as invoice positions or sub tasks), the new viewer can load changes of many similar records simultaneously. Any list, showing records with enabled change logs, now provides access to change logs of all currently loaded records. By filtering the list field, changes can be limited to relevant records.
Important: To show changes for multiple records in the same view, these records must be identifiable; ie. seeing changes is not very helpful, if we do not know what record these changes belong to. For this, we have another feature, called 'Record titles'. Record titles are defined on a relation and consist of one or many attributes. If no record title is defined, change logs will only show changes from records directly loaded onto a form - just as before REI3.12.
Integrated version history
With REI3 applications growing in complexity, it becomes more important to track, what changed between versions. So far, people used notes, text files or other REI3 apps to keep track of changes. Now in REI3.12, we offer an integrated solution: The application version history.
The version history is stored as part of the application and therefore exported with it. If updated regularly, changes can be found in any REI3 system that installed this application version. The new version history is also used in the next feature, which is...
A redesigned application transfer
The user interface for exporting REI3 applications was not updated much since REI3 1.0 was released many years ago. It was servicable but not very helpful to inexperienced application authors. In REI3.12, we reworked the transfer user interface to make it clearer what the system expects and easier to avoid mistakes.
It also includes new functions, like uploading new application versions directly to a REI3 repository. In this case, the new version history is processed to find changes that the REI3 repository does not know about; the delta change log is then generated and uploaded, together with the application, as change log to the repository. If test or staging repositories receive additional versions between larger releases, their change logs will be more granular as smaller deltas are recognized between versions.
Private keys for application signing, as well as credentials for upload to a REI3 repository, can be stored via end-to-end-encryption for the currently logged in user. This reduces the amount of effort necessary to deploy a new version. Please be aware that end-to-end-encryption is only as strong as the authentication used to log in - do not store private keys or credentials if you use simple or even the default REI3 admin credentials.
Multi repository support
REI3.12 now supports accessing multiple REI3 repositories simultaneously. Useful when receiving updates from staging & production or when access to public and private repositories at the same time is desired. While it was always possible to import new versions from multiple repositories into a central one, allowing multiple repositories negates the need for this entirely in some cases.
When the same application is hosted in multiple repositories, REI3 will offer the latest available version. If access to older versions is desired, repositories can be temporarily disabled in the admin panel.
File exchange via API
While not a regular request, some use cases called for automatically sending files via REST from REI3 or uploading files to a REI3 instance through API calls. Both these can now be handled with REI3.12:
First, APIs offered by REI3, can now receive files. This occurs in a two-step process. Files are uploaded via form data request to a generic upload handler - just like browsers do when uploading files in the user interface. This returns a file ID, which is then attached to a record via its files attribute through a regular API POST call. We have included a template in REI3 to show how this is done.
Second, REI3 can now include existing files, uploaded to files attributes, in outgoing REST calls. By calling an instance function, you can tell REI3 to add a file to a REST body you are preparing. This can be a form data call for simple file uploads or encoded as Base64 - often used in JSON or XML POST calls.
These new features allow for file exchange between REI3 instances as well, supporting more use cases still.
A new numeric input & CSV number formatting options
For some irrelevant, for others essential: REI3.12 now includes a numeric input that formats numbers.
While lists and other views already displayed numeric values in accordance to user settings, inputs were the exception. This new input addresses this and is automatically enabled for all relevant fields.
CSV exports now also offer options for defining number formats. These, together with other settings like the date format or delimiter character, are now persistently stored with the list field for the current user.
More smaller features and improvements
- Authors can now submit comments to record change logs via the new instance function 'data_log_comment_create()'. This is useful in cases where changes are not done by people, but by the system in scheduled or event based operations - or indirectly by triggers. The new change log viewer (s. above) then displays these comments.
- Authors can now clear change logs for records. This can be useful in cases where records need to keep existing because of their relationships, but their content (incl. change logs) should be anonymized for data protection reasons. This is done via the new instance function 'data_log_delete()'.
- Record titles can now be defined on relations, first to show changes to individual records in the new change log viewer (s. above), but also to show the currently opened record in the form title. A new option 'Show record title' has been added to form properties.
- S/MIME signing support has been added for SMTP mail accounts. Certificate & key files must be placed in the path defined in the REI3 configuration file 'config.json' under 'paths->certificates'.
- Options for plain connection & no-authentication have been added to SMTP mail accounts. This has been implemented for internal mail services, where authentication is not possible - if at all possible, these should not be used.
- A new version of the instance function for reading text files has been added: 'file_text_read_cb()'. This version includes the option to send a callback value.
- OAuth2 clients for OpenID authentication can now define an admin claim. If used, and the claim is set correctly, users logging into REI3 will become instance admins.
- A new option, to disable certain modifier keys for global hotkeys, has been added to the admin panel. This can help users avoid hotkeys that may interfere with other tools on their machines.
- The 'Open form' input in the Builder has been redesigned, reducing the amount of dropdowns and making it easier to select from all joined relations.
- Many Builder UIs, such as the form or function editors, were updated to only reload when the currently open record has been changed. This means that creating functions or assigning triggers will no longer reset changes in the current editor.
- Form actions can now also directly open forms without the need for frontend functions.
- The form editor in the Builder can now reference new entities, like fields, in places like form states, without needing to save changes to the form first.
- Change log retrieval has been optimized to reduce the number of DB round trips extensively.
- Checks for data access permissions have been optimized to reduce server load.
- The calendar week selector in week views, now shows the week date range on mouseover.
Important note for application authors
Because the new change log viewer (s. above) needs to be able to show changes for related records, it cannot rely on fields on the current form to decide how to display changes to relationship inputs (like the old change log did). This means record titles must be configured to show changes in relationship inputs. Changes of relationship inputs will be visible again, once these are set on the relevant relations.
Upgrade notes
As always, these are the general upgrade steps:
- On Windows: Run the installer.
- On Linux systems: Stop the service, extract the latest release, replace the
r3 binary, start the service.
Thank you all for your continued support and feedback. For the full list of changes, take a look at the technical change log.
