Redesign of the Navigation panel and left-side menu bar.
Navigation panel underwent a major overhaul. The immediately visible changes relate to visual appearance of the menu: The menu panel got a new look, and most control elements, such as organization name, Search, and Shortcuts controls went to the top (Pintab) panel.
The redesign, however, changed not just the visual appearance; It is now possible to configure whether the menu panel should appear on top, or on the left. This can be done under System Configuration > Display Settings > Navigation bar with Position selector. Left-side menu has the same structure, but its top-level items are displayed as icons instead of words. Please note: this means that from now on an icon should be designed for every new top-level menu item along with the name.
Website event tracking.
In order to start track events, you have to create a website first—this can be done under Marketing > Tracking Websites. After a site is created, you will get a template of tracking code that you can edit to suit your tracking demands and then embed it on desired pages of your website. By default the code contains only tracking of page views, but the template also contains a placeholder for event tracking code (hidden with comments).
By default all information is passed to OroCRM directly in the real time; note that it may cause performance issues if the traffic on the website is intensive. To avoid this, you may disable dynamic tracking and choose longer log rotation interval in the tracking configuration (System Configuration > General Setup > Tracking). You can also choose to store data not only in OroCRM, but on the Piwik host as well; to do so, specify Piwik credentials in the tracking configuration. Note that if this option is executed, website identifiers in OroCRM must be exactly the same as in Piwik.
Processes are meant to be a core feature of both BAP and OroCRM, and one of the most widespread ones. The formal definition of the process is following: The process encapsulates a user-defined set of actions that is performed after some triggering event if some additional conditions are met. In plain language this means that the user will define a process if he feels the need to automate some routine actions that have a clear set of rules; the most obvious example of such actions is automated processing of imported data.
Processes consist of four major parts:
- The trigger, or triggering event—an event the process listener is set to, and which launches the process. There are two principal triggers: A creation of a new entity record, and an update of an existing record. In the latter case, the update may be restricted to a certain attribute, or a set of attributes of an entity.
- Conditions that are checked after the launch.
- Actions that are performed by the process if the conditions are met.
- Conditions and actions available for use in processes are the same that are used for workflows.
In scope of this release we introduce only the basic functionality of processes. For now, the only way to create and manage them is by editing the process configuration code in the .yml file; the UI management tool will come in future releases.
New custom field types for entities: File and Image.
It is now possible to create custom entity fields of the File or Image type. Files or images are uploaded to the field via the standard dialog, and then available for preview (in case of image), or download (in case of file) from the view page of an entity record.
The use case for such fields is obvious from their nature: They allow to add pictures or files that might provide important context for an entity—think of the user avatar, or the contact photo, or the PDF file that contains the statement of work related to the closed opportunity
New control for record lookup (relations).
We introduce a new record lookup control to be used on Edit pages for relation attributes. This control is configurable and contains three parts that can be turned on and off depending on the context:
- Lookup control where the user can start typing in the desired value, and where he will get a simple list of matches, or, if he typed nothing, a full list of available records.
- Grid button. After clicking this button, the user will see a popup with a grid of entities that are available via the control. The grid provides more detailed view of available records, and the user can filter it and sort it, too. The user can select one or many records depending on the nature of the underlying relation.
- New record button. With this button the user can create a new record on the fly, without having to navigate away from the form.
As a general rule, relations to entities such as Contact and Account should always contain the New record button in the control, as these entities are the most likely to be created in the context of some other entity. Think of a new Lead that comes from a new customer—to properly handle this situation the user has to create all three entities, and with the new control he is able do it all in the scope of the New Lead form. On the other hand, entities like User or Business Unit are not likely to be created often, and from context of other entities, so for them the New record button is redundant.
Data import in CSV format.
The existing feature of CSV import and export of Contacts was expanded and generalized. It is now possible to configure templates for import & export of every entity, including custom ones. Ready-to-use import & export actions are available by default on the following entity grids: Account, Contact, Lead, and Opportunity. Export is also available for Users.