This section describes functional modules which group functions. More about functional modules in a technical manner and how do they are work can be found in the core-modularity section.
This section is NOT about logical modules which group entities, more about those can be found in the entities section
Modules are the key part of the system which provide almost all functionality to it. We can distinguish two main types of modules:
Entity specific modules - when a entity has more specific requirements than aggregating the functionality of existing general modules and the configurable core functionalities of the system, then we can implement a indepented module that provides the specific functionality for that entity.
This type of modules is described in the entities section along with the description of the entities itself.
The status module adds to an entity one field - the status field. But not only that, as fields can be easily added by pure configuration. The status field has special properties which is:
So each entity which has the status entity assigned and configured (or using a already defined status configuration) has above mentioned functionalities.
The status module allows a record of a entity that uses this module to be versioned. Making a new version of a record copies the record and (if configured) the related objects of that record.
The earlier versions of the record are hidden in the list, and are accessible through the "version history" box. Additionally it's possible to define major and minor version for a more granular control over the versioning.
Another type of versioning supported by this module are branches, when a record is branched, it's copied as well, but all branches are visible in the record list, until a new major version isn't created, then all branches of the earlier versions are hidden and visible in the version historybox.
That are the configurable functionalities of the module:
1 -> 2 -> 3 -> 4 -> 5 -> ....each new major version hide the earlier versions, making them available through the version history box
2.1 -> 2.2 -> 2.3 -> 2.4 -> 2.5 -> ....just as major versions, the minor versions hide the earlier versions, making them available through the version history box.
Branch versioning can be optionally enabled as well for defined entities which use the version module. The version description for version 2.1 of a record is following:
The branch versioning is different from major and minor versioning, because a new branch of record doesn't hide the earlier branch, thus all branches of a record are visible in the record list, until a new major version isn't created in which case all earlier major versions are hidden.
Because until a new major version isn't created, all branches are accessible, it's possible to create new branch from any existing branch, not like in major and minor versions, where each new version is created from it direct predecessor. So following versioning is possible:
2.1(a) -> 2.1(b) -> 2.2(b) \-> 2.1(c) -> 2.1(d) -> 2.2(d) -> 3.0(a) \-> 2.2(a) -> 2.3(a)
So each branch can be versioned seperately by minor versions, and creating a new major version basically means that we decide which branch is becoming the only one. For example on above versioning tree we decide that the version 2.2(d) became the new major version branch 3.0(a)
Above tree can be displayed by the version tree available through the version module, and visible on the screenshot below.
Associations and relations are an important part in configuration of the version module, because for different relations we can expect different behaviors.
Behaviors are configurable for each relation (e.g. folder->document) and for each versioning type seperately (e.g. different for major and minor versioning)
Following behaviors are available:
The record template module is a small module which is adding two functionalities to the entities which use it:
The files modules is responsible for supporting, yes, files. It has an "native" entity, the file entity. By creating a relationship with a file entity, a record can be related to many files, and it's possible to attach files to the record.
However, we don't have to use the "native" file entity which contains only basic file information needed for handling files in context of record. Any entity can use the file module, which will allow to upload a single file to a record of that entity.
Files after they are downloaded to the local computer are linked with the file stored on the server. It's possible to synchronize the file, upload changes or download the latest version.
The files are stored on a dedicated server with a dedicated service for making the files available in a secure maner for the client applicaton, so that the back-end server doesn't get load with the heavy traffic.
There are many scenarios which this file modules covers, so feel free to download the full technical documentation of that module HERE
That's how it looks like when a user wan't to download a document file, but has it already locally and made some changes:
The file templates module is tightly coupled with the file module. It allows to configure template files, so that it's easy to create new files based on existing templates.
After a configured template is selected, the template file is copied on the file server, and the new copy is associated with the selected record.
This module, when coupled with the MS Office integration, is much more powerfull. It allows to map fields or keywords in the file template, with values in the record. The values are then set in the file, which can be a word document, an excel spreadsheet or a powerpoint presentations. The values mapping can be performed on the server or on the client machine.
Such functionality allows e.g. to fill a invoice template with invoice data from the system, a letter with with contact data from the system, etc.
The notes module is a simple one, any entity using the notes module gets due to the configuration of the module an association with the notes entity, making it possible to creates notes for every record of that entity.
Mostly this module is UI related, as the notes entity has a custom workspace displaying the notes with a look'n'feel of notes.
Notes can be used to write personal data about a record.
The comments module is very similar to the notes module from a technical point of view. It adds the association with the comments entity, making it possible to comment any record of the entity using this module.
The main difference is in the UI and the default security setting. The comments are by default displayed inside the data form of that record. And whereas in the default security settings notes are private for the user who creates them, until he doesn't make them public. Comments are public by default for anyone who has access to the record containing the comments.
The favourites module is pretty selfexplaining, a record of an entity which uses this module can be added to the favourites box. which allows a faster access to that record from that box, and from datapickers used to search a record of that entity.
A entity which uses the following module, gains the functionality to follow a record.
Based on the configuration of the module for every entity followin functionalities are made possible with this module:
Entities which use the usage module have all actions performed on the records of that entity logged.
There are three main use cases for that module:
The conversion module allows to add through configuration the functionality to convert a record of one entity to another entity.
It can be useful in standard workflow patterns like:
Received email -> Request -> Task
The configuration of this module allows to be configured in following ways:
The reminders module is self-explaining, we can set a reminder for any record of a entity which uses this module.
The MS Office integration module is self-explaining, it integrates the a7 Platform with MS Office in following ways: