a7 EBusiness Platform - Standard Modules

Standard business entities have a lot of common functionalities, just configure the specific fields, select the modules you need and the system gains the functionality you need.

From the get-go the standard functionalities of a EBusiness system are here. But they can be easily configures and extended to meet the business needs of the organization.

Cases are usefull to classify each object in the system.

About modules

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:

General modules - modules which provides functionality independent of the entity which uses them. Some examples of general modules:
- Comments module - on entities which uses this module, each record can be commented by a user.
- Favourites module - records of entities which use this module, can be added to favourites
- Versioning module - records of entities which use this module can be versioned
- File module - to each record of a entity which uses this module, a file can be uploaded and attached
This modules are described in this module.
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.

Status

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:

The fields can't be freely edited, a newly created record has a preconfigured status which can be changed only by preconfigured users/groups/teams, to another status accordingly to the configured status transitions.
The status can based on configuration determine if a record is read only or not, and who has access to it based on security settings, e.g. some groups may see only approved documents.
Transitions can be configured for each entity, e.g. that it's possible to go frome the "new" status to the "in progress" status, but it's not possible to change the "new" status directly to "completed" for the task entity
All status changes are stored in the status history of that record with the information who and when changed statuses

So each entity which has the status entity assigned and configured (or using a already defined status configuration) has above mentioned functionalities.

Version

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:

By default, this module provides the functionality of major versions, which means that the record is versioned like
```
1 -> 2 -> 3 -> 4 -> 5 -> ....
```
each new major version hide the earlier versions, making them available through the version history box
It's possible to enable optionaly minor versions, minor versioning for major version 2 produces following version numbering
```
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.
Besides the descriptive numbering, the difference between major and minor versions is used by the branch versioning described below.
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:
- Leave relation - old version is still related to it's objects, new version doesn't have the relation. E.g. a new version of a folder isn't anymore related to the documents to which the old version was related.
- Replace relation - all relations are moved from the old version to the new version. E.g. all documents of a folder become related to a new version of the folder instead of the old one.
- Add relation - new version will be related to the same records that the old version was related to. E.g. We create a new version of a folder, now the documents of the old version are related to both, the old and the new version of the folder
- Create new version of related - only available if the related entity also uses the version module. New versions are created of all related records, and the new version of the main objects is related to the created new versions of the related objects.

Record templates

The record template module is a small module which is adding two functionalities to the entities which use it:

On a existing record, the "Add As Template" button, which saves the record as a template, making it easy later on to create similar records.
On the record list, the "Add From Template" button, which displays a list of available templates, from which a new record can be created, the newly displayed record will be a clone of the template.

Files

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:

File templates

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.

Notes

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.

Comments

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.

Favourites

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.

Following

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:

If enabled in configuration, a following button appears for each record of that entity. When the following button is checked by the user, he will be notified about every (configured) action performed on that record.
We can configure, that certain users, ale always notified about configured actions on a record. For example we can configure that an user set as a supervisor of a task will be notified about changes made on that task. Or that the members of a group which responsible for a folder gets notified about changes in documents which are associated with that folder.

Usage

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:

General log of usage of the system, we can check on which entities and records is the most work done etc.
Log about the actions of a user, because each usage log is associated with the user who performed the action, we can see the last activity of a user in the system.
History of a record - we can check what action where performed on a given record.

Conversion

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:

From which entity to which it's possible to convert.
Values from which fields in the source records should be set on which fields in the target record. Optionally with some convert function.
How to handle associations, for each relation it's possible to configure that:
- The association is ignored, the target record will not have the associated objects of the source record associated.
- Copy associations - the target record will have the associated objects of the source record associated with the configured relation.
- Copy associations and associated records - the target record will be associated either to copies, or to converted records of the source record associated objects.

Reminders

The reminders module is self-explaining, we can set a reminder for any record of a entity which uses this module.

MS Office integration

The MS Office integration module is self-explaining, it integrates the a7 Platform with MS Office in following ways:

Server functionality to generate MS Office files filled with data from the system based on configured mapping and template files.
Client add-on to MS Office applications which allow to use some of the functionality of the a7 Platform from within the MS Office applications, like dowloading, syncing and uploading files or filling the MS Office files with data from the a7 platform.