Skip to content

Object access

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.

Concept

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.

Example

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

Availability

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.

Object Access is availability both on-premise and in the Lime CRM Cloud.

Configuration

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.

Default permissions

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.

Default user group

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.

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.

Changing owner and group

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.

Disable blacklisting of tables in web client

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:

  1. Add the following lines to config.yaml:

    security:
    types_with_record_access_are_accessible: true

  2. Restart Lime CRM Web Server

Advanced set-ups

With the configuration of object access we solve the simple needs, where you can configure what group all objects created by a certain user is set to as well as the default permissions.

For more advanced needs, we need to set the owner, group and permission for objects through customization with the concept of custom limeobjects. The technical documentation you can find here.

Example 1 – Cascade permissions

The employees are divided into teams, and the employees should only be able to access projects belonging to their own team. The same rules should also apply for any history and documents connected to those projects. That is, you should only be able to see the history notes and documents for the projects that you have access to.

This case is more advanced since the permissions for history notes and documents depends on whether the notes and documents are connected to a project or not. In this case – all documents and history notes NOT connected to a project should be accessible to everyone.

To solve this more advanced case you need to:

  • As with the simpler case, set up groups for the teams and set them as the default group for users through Lime Admin
  • Set the default access for projects to “none” for others and full access for “group”, but leave history and documents at full access for everyone

Then we need to use a custom limeobject to apply the wanted behavior when creating history notes and documents. This means that:

  • Whenever a project is created, access will be restricted to the creating team
  • Whenever a history object is created, access will only be restricted if it is connected to a project

Through the custom limeobject, we also need to update the group and permissions for the history notes and documents if the:

  • Group is changed for the parent project
  • The history note or document is detached from the project

Example 2 – Dynamic groups

The employees are working in cross-functional teams for their projects in Lime CRM, where the teams are administrated per project through a tab “Project members”. Only the users connected to the project through the relation to “Project members” should have access to the project.

To solve this more advanced case you need to:

  • Set the default access for projects to “none” for others, but full access for “group”

Then we need to use a custom limeobject to apply the wanted behavior for creating the right group and members. This means that:

  • Whenever a project is created, a unique group is created
  • Whenever a project member is added or removed from the project, the corresponding user is added or removed as a member of the group that the project is connected to