With object access it is possible to restrict access to a specific object in Lime CRM. This is different from type level permissions which are handled through policies and ACLs, where permissions are valid for all objects of the same type.

For example, with security policies, we can define that only a certain group have access to any object of a certain type:

“Only members of the sales group can access deals in Lime CRM.”

With object access, we can allow for only a certain group of users to have access to specific objects:

“Only members of the Swedish sales group have access to the Swedish deals in Lime CRM and only members of the Norwegian sales group have access to the Norwegian deals in Lime CRM.”

With object access, it is also possible to define who has the right to update and delete a certain object, for example:

“Only the owner of a deal can update the deal. Other users can only read the information.”

Object access needs to co-exist with record access (“postbehörighet”) if you are using the desktop client. In order to achieve the same behavior in the desktop client as the web client, a migration is needed from record access to object access – read more here.

One important difference between record access and object access is that object access works in Lime CRM web client, which the old record access does not.

You can find the technical documentation about Object Access here.

Every object in lime, independent of type, is assigned an owner, a group and a set of permissions. The permissions are separated into three different contexts:

1. What operations are allowed when the logged in user is the owner?
2. What operations are allowed when the logged in user is a member of the assigned group?
3. What operations are allowed when none of the above apply?

The permissions are the following three:

1. Who can read the object?
2. Who can update the object?
3. Who can delete the object?

The permissions are additive, so that if the user, i.e. are allowed to read as a result of being the owner in context #1 but does not qualify for context #2, then permission is still granted.

Consider the following settings for a object:

• Owner: Kalle
• Group: Sales

Permissions:

• The owner: READ, UPDATE, DELETE
• The group: READ, UPDATE
• All other (those who are not the owner or member of the group): READ

This would then translate to:

• Kalle may READ, UPDATE and DELETE
• Anyone in the group “Sales” may READ and UPDATE
• Everyone may READ

Object Access applies directly to the Web Client but not as default for the Desktop Client. To make the Desktop Client obey the Object Access rules limefu must be used to enable it. Limefu will create a Record Access rule, to obey the Object Access configuration. In our cloud environment the self service portal can be used to enable Object Access for the Desktop Client

Object Access is availability both on-premise and in the Lime CRM Cloud. Currently the Lime CRM Cloud doesn't support customizations and thus only the configurable part of Object Access can be used

The configuration of object access is done through Lime Admin in the “CRM configuration” category under “Object access”. Here you can set the default permissions for each limetype as well as set the default group for each user. When you apply changes to an already existing setup the web client will update directly, but the desktop client needs to be restarted for the changes to be applied.

For each limetype you can set the permissions per context that applies when creating a new object.

For example, to achieve the behavior previously described:

“Only members of the Swedish sales group have access to the Swedish deals in Lime CRM and only members of the Norwegian sales group have access to the Norwegian deals in Lime CRM.”

We would have to have the following set-up for the limetype “Deals” in Lime Admin.

This setup means that only the owner plus the members of the group that the object is tagged with will have access to the object.

When a new object is created, the object is tagged with a default group. What group the object is tagged with depends on what default group the user has set and is administrated through Lime Admin (see image).

It is only possible to set a default group for the user to a group that the user belongs to. This is administrated in LISA/MAGGIE (read more here).

According to the example that the image shows, all objects created by the user “admin” will be tagged with the group Administrators. This default group setting in combination with the default permission would imply that only the users that are a member of the group Administrators will have access to the deals that admin creates in Lime CRM.

All groups and their members are administrated in LISA/MAGGIE.

In the example below, we have different groups for the different sales persons depending on in which country they belong. We also have a group for managers. The “Managers” group is a member of all the different sales group. This means that the members in the group “Managers” also are member of the different sales groups automatically.

In the web client, it is possible to change the group and owner (if you are an administrator). This is done through the information-modal on each object:

The group can only be set to a group for which the owner is member of.

In order for object access to work properly for customers also having record access, the feature switch for blacklisting tables in the web client needs to be switched off:

If you are using config.ini:

1. Add the following line to config.ini (usually found here C:\ProgramData\Lundalogik\LIME Pro Server\Web Server\configs):

    [security]
    types_with_record_access_are_accessible = True

2. Restart Lime CRM Web Server

If you are using config.yaml:

1. Add the following line to config.yaml (usually found here C:\ProgramData\Lundalogik\LIME Pro Server\Web Server\configs):

   security:
   	types_with_record_access_are_accessible: true

2. Restart Lime CRM Web Server

• More advanced set-ups
• FAQ