Home Documentation Download License Contact

Create Application Model Example

In this chapter we will have a look at an example Application Model. The tables are similar to the ones in the previous examples, with some minor changes.
The focus of this chapter is to create roles and assign permissions to these roles, in a still simplified, but somehow realistic scenario.

Load Application Model Example File

To load the example Application Model, please go through the following steps.
If you don't want to download and load the provided model, you can also create it on your own, but be aware, that not all settings are discussed to avoid too many details.

  • Download ApplicationModelExample.xml.
  • Start "M4 Creator" and select "Edit Application Model" from the start screen.
  • Choose "Import from file...".
  • Select the file ApplicationModelExample.xml.
  • Choose "Open".
  • Right click the "Data Model" node and select "Create Table(s) and Columns...".

Create Table(s) and Columns


In this example we will assume that sales persons and clients belong to different branches of the company.
To do this we have a field called "Branch" in the clients table. Furthermore we got a simple selection table to select the different branches from.



In our example we use the following roles and permissions:

  • Salesperson (Branch A and B) permissions:
    Read/add permission for "Clients".
    Write permission for "Clients" of their branch.
    Read/add permission for "Sales", if client is new or of their branch.
    Write permission for new "Sales" and "Sales" last edited by the current user.
    Read permission for "Salespersons".
    Read permission for "Products".
  • Manager permissions:
    Read/write/delete/export permission for "Clients".
    Read/write/delete/export permission for "Sales".
    Read/export permission for "Salespersons".
    Read/write/add/delete/export permission for "Products".
  • HR Manager permissions:
    Read/write/add/delete/export permission for "Salespersons".


Access Model

As we have many access restrictions, we will start without permissions in most cases. Only the history permission is granted by default for all.
Read, search and export permissions are only granted for "Manager", so this group, by default, can read, search and export everything. Nevertheless, it is possible the revoke this rights for selected tables or columns.

Access Model default rights

Access To Clients

As we want different access types for different branches of the company, we need a permit for each branch ("Permit Branch A" and "Permit Branch B").
NOTE: In this example we assume, that your company has two branches only. These branches are "City A" and "City B" with the keys "A" and "B". If your company has numerous branches, this approach would lead to a very complex Application Model, difficult to maintain. This can be avoided, using a CustomCondition. Find more information in the chapter Custom Condition.

We also have a permit, that is always applied ("Permit all records"). Finally there is another permit, that applies to new records only ("Permit new records").

So we have 4 permits:

  • Permit all records
  • Permit new records
    "ExcludeExistingRecords" option is checked
  • Permit Branch A
    Condition with ParameterDataField set to "Clients.Branch" with ParameterValue = "A"
  • Permit Branch B
    Condition with ParameterDataField set to "Clients.Branch" with ParameterValue = "B"

>Access to Clients - Permits

Permissions In "Permit all records"

"Permit all records" gives the following permissions:

  • Read and search permission to salespersons.
    NOTE: As managers got read and search permission on access model scope, this role needs not to be checked here, if PermissionTypeOnNoRoleMatch is None.
  • Write and delete permission to managers.
  • Add permission to managers and salespersons.

Permissions In Permit All Records

Other Permissions

Only the write permissions for salespersons need to be addressed separately. As mentioned above, salespersons have write permission to clients if the record is new or the client belongs to the same branch.

So we have the following permissions:

  • Write permission for "Salespersons A" and "Salespersons B" in permit "Permit new records".
  • Write permission for "Salespersons A" in permit "Permit Branch A".
  • Write permission for "Salespersons B" in permit "Permit Branch B".

Access To Sales

"Sales" is a sub-node of "Clients". While the permissions, statued in the section Roles, are rather complex, it is quite easy to be set for "Sales". As "Sales" inherits its permission from "Clients", a good part of the job is already done.

To adjust the permissions in clients, the following settings are added:

  • In the "Sales" access node the option InheritAddFromWritePermission is checked.
    Doing this, everyone who has write permission to clients, can add sales by default.
  • One exception from the InheritAddFromWritePermission rule are managers. While they can write to clients, they must not be able to add sales.
    To achieve this, we have a "Permit all records" for the sales node too. In this node the "Add" permission is set to roles, with only the "Manager" role checked. To revoke the permission from the selected role, instead of granting it, the PermissionTypeOnRoleMatch property is set to "No" and the PermissionTypeOnNoRoleMatch property is set to None.

    Permissions with PermissionTypeOnNoRoleMatch

  • The "Permit new/current user records" is added with the ExcludeOtherUserEditedRecords option checked. With this option, the permit is only taken into account for new records and for records, last edited by the current user. In this permit write permission is given to salespersons.

Access To Salespersons, Products And Branches

Permissions to "Salespersons", "Products" and "Branches" can simply be added using a single permit for each node.

>Access To Salespersons, Products And Branches

Assigning The Roles

To use M4 Back Office with specific roles, you need to define a group reader, create users and assign roles.
We already have seen how to do this in the chapter User Roles.
For this example we used the Application Model Groups Reader. You need to create at least 4 users to assign the 4 roles we have defined. Of course you can try to assign more than one role to a user.

Assigning The Roles

Permissions For Components

Above we've been setting permissions in the access model. Another way to limit access is on component level. To do this, each component has got a permission property, which works like the access model permissions.
For our example we assign the following permission settings to the components:

  • Clients: Salesperson A/B, Manager
  • Products: Manager
  • Salespersons: Manager, HR Manager
  • Branches: Manager

Creating Branches Component