This is the most common case: you have a single agency with several employees, which can manage properties and customers without any limitation.

Moreover we will have an "Agency owner" that will be able to do everything, without any restrictions.

First of all we have to create the user groups and we will adopt this structure:

Example 4.4. ACL Scenario #1: Group settings

Now it's time to set all the permissions.

We could omit creating the Domus Organizer group, since all the permissions are set to Inherited which means that it won't add any new action to the group, but we did that for clarity.

The Employees group will hold, of course all the employees and it will have these permissions:

Example 4.5. ACL Scenario #1: Employees permissions

They can do everything but they aren't administrators of the whole component, so some actions are precluded to them.

Users that are inside the Agency owners group are the truly "Super users" of the component:

Example 4.6. ACL Scenario #1: Agency owners permissions

As you can see in the Calculated Setting column, they can do everything, since they have the permission Component administrator.

One last thing: you have to set the default access levels for your customer and properties. You can do that inside the agency profile, for the moment set them to Public, we will talk about those fields later.

Summary

So, what we achieved so far?

First of all, our control panel access is accessible only to employees of the agency. Each of them can see all the customers and all the properties, but they can't edit agency details; we want to double check contact info, so only the Agency owners can those info.

Well, it was easy, isn't it? So, now let's move to a more complicated scenario.

In the previous example we had different employees, but each of them could do everything: add or delete a customer, edit a property or change its publication status.

What if we want different people do different actions?

For example we want junior agents to deal with properties only, while senior ones can edit customer, too; moreover juniors should not edit property publishing options, since they could mess around...

Well, that's very easy!

First of all let's create a group structure like the following one:

Example 4.7. ACL Scenario #2: Group settings

Again, we have a group for Agency owners that have the Component administrator permission (you can take at the previous screenshot), but now we have to more groups, Junior agents and Senior agents.

These are the permissions for those two groups:

Example 4.8. ACL Scenario #2: Senior agents permissions

Example 4.9. ACL Scenario #2: Junior agents permissions

As you can see, Junior agents have fewer permissions, so they won't be able to edit any customer nor change property publication.

Figure 4.18. Scenario #2: Property form with publishing fields disabled

Figure 4.19. Scenario #2: Customers view without any edit permissions

Summary

What we did this time?

Now our permissions are a little more complex, we still have only one agency, but we have two different kind of agents: Juniors and Seniors.

Seniors can do pretty much everything: they can manage the property (edit/add/delete/publish/unpublish) and they can edit customers, too. On the other hand, since Juniors are the newcomers, so they don't have the same permissions. They can edit/add/delete a property, but they can't publish nor unpublish it, moreover they can't edit customers, they can only "see" them.

In the previous sections we added or restricted permissions other customers or properties, however every agent could be able to see every record.

Sometimes you don't want something like that: for example you are dealing with some very important property or customer and you want to display them only to authorized agents.

You can achieve this goal using Access Levels.

If you remember, at the beginning of this chapter we said that the ACL is divided into two parts: actions or permissions (what an user can do) and access levels (what an user can see).

We will continue with the previous example: we want some properties and customers to be visible to Senior agents only.

First of all we have to create a new Access Level: we can do that from the backend:

Example 4.10. Scenario #3: Access level for Senior agents

As you can see we added the Senior agents group, plus the Agency Owners and the Super Users ones, too; in this way users that have admin permissions will be able to see those records.

In the following examples, you can see it in action: we set the access of a property to Senior agents and only the users that are allowed (in other words: the users that belong to one of the groups we specified for that access level) will see the record in the property list.

If a Junior agents tries to perform a search or to browse the properties, he simply won't see the record: it's completely hidden to him.

Figure 4.20. Scenario #3: Property access level

Figure 4.21. Scenario #3: Senior agent property list

Figure 4.22. Scenario #3: Junior agent property list

However, who decides the access of a record and who can change it?

As you can imagine, this is a very reserved operation: you are going to display or hide records to different sets of user, therefore only users with the Component administrator (domus.admin) permission are allowed to do that.

Figure 4.23. Scenario #3: Edit access level

Summary

What we achieved so far?

We still have to kind of agents, Junior and Senior ones, and both of them can perform the same actions. However, only the most experienced ones (Senior Agents) can see and edit "special" customers or properties, since we created a new Access Level and assigned it to those records.

As last thing to say, only Agency owners can change the access level, since the Component administrator permission is requested to do that.