Its that time again - a new major update for REI3 is out, so let´s see what we got.
Although REI3 could already offer APIs as a REST server, sending or pulling data from inside your REI3 apps was not supported. With REI3.4 we can now execute REST calls directly from backend functions. This enables regular data exchange based on schedules or event based updates via triggers or other function calls.
Because every REST API is different, you can freely define headers, request bodies and so on. A REST spooler attempts to execute your calls even when there is a temporary issue.
REI3 offers a lot of freedom when it comes to functions and data processing - having a lot of options however inevitably leads to complexity. Especially with the new REST calls, we´ve found that there are so many ways to do things that regular documentation just was not practical.
So we decided to build function templates for the most common use cases. When attempting to build complex functions, templates can help you get started. Besides templates for REST calls, we´ve also added one for processing incoming mails from the mail spooler. Depending on feedback and how future features will look, we will extend the number of templates.
Bulk update forms
Introducing: Easily update hundreds of records at once directly through a list with our new bulk update forms. With REI3.4 you can assign a bulk update form to any list.
By default every field on a bulk update form is optional and only values of changed fields are updated. This just makes sense as you might not want to change certain values at all. But you can however still use form states to dynamically change this behavior, to make certain inputs mandatory for example.
Bulk update forms can be assigned in addition to existing forms, so you can open a specific record on one form, while using a another, simpler form for mass updating specific values.
Up until now, you could open records either directly (as a new page) or as a floating window. Now we have a third option - the inline form:
Especially useful for records with few inputs, the inline form keeps everything visible while you can create or update your record. Bulk update forms can also be opened as inline form.
Besides lists, calendar & Gantt fields also support this feature:
Inline forms generally need more space to work, so they are automatically converted to floating windows when using a mobile device.
Direct app access
There are many reasons, why you might want to directly open a specific app instead of the start page of the REI3 instance. Maybe your users only use one app - or maybe you want to install multiple apps on your mobile devices individually. This is now possible via direct app access.
With access to customizing, you can now define individual apps, that can be accessed and installed individually. They are then shown as native apps on devices and can have their own title and icons. It does require sub domains and a wildcard certificate to work correctly however. But if your infrastructure supports it, this can make your apps feel even better than before.
Easier column batching
Batching columns together never was quite intuitive, with a batch number you had to assign and which had to match columns around it. With 3.4 we´ve redesigned the interface so that you can just drag and drop columns to create column batches.
More column options
In addition to easier column batching, you can now set some styles for your columns. When batching at least 2 columns, you can now also choose for your content to be vertically aligned - this means that lists like this are now possible:
Useful for integrating external resources, iframe fields are now available to access anything your browser can display.
Because iframe fields just show what value you assign to them, you can dynamically update a URL with getter parameters to show context specific resources. You can also simply use a default value on a readonly iframe field to provide access to an intranet login page.
Don´t like how REI3 looks? No problem - with new customizing options in REI3.4, you can provide your own custom CSS. Make buttons rounder, colors pop or change styles as you desire.
We knew for a while that our regular indexing did not support larger text values. This was causing us headaches with apps we designed, especially in regards to our knowledge base and ticket system.
The plan was to address text indexing a while back... but we found that it was a more complex issue than we had anticipated. Besides that, solving text indexing would also enable other powerful new features. So the scope increased and it took a while to get it done. But here we are.
REI3 now offers a simple to use text index option that can be selected when creating new indexes. It only supports text values (obviously) and works on a single attribute. But when its enabled, the system can now find records over hundreds of thousands of large texts within milliseconds. And that is not all.
Together with very fast lookups, REI3 now also offers full-text search (FTS) capabilities for values that have a text-index. This means that you can scan for words or phrases, like you would googling something online. And even better: If you can know the language of a text, the full-text search can use language-specific features to improve your search even more, like looking for results with the same word stem. For this you need the new 'dictionary attribute' to select and store the appropriate language value of a text.
Text indexing is not something you will need for every app - but if you need it, these features will make things much better.
Some more things
- When creating a new child record via a list or calendar field, n:m fields can now also be populated.
- PWA options such as app title and icons are now available for individual applications.
- The customizing UI in the admin panel has been redesigned, including more options & context help.
- Relationship inputs in the Builder for n:m now use unique icons to differentiate themselves from other types.
Duplicate primary key references
REI3.2 introduced a bug in which applications being newly imported into another instance would duplicate index references for primary keys. Luckily this caused no issues besides looking weird. This bug is now fixed. To remove duplicate entries, have all affected applications in a REI3 instance <3.4 and then upgrade to 3.4 - duplicate indexes will be removed and you can re-export your applications.
REI3.4 does not need any special 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.