Full ACL support


This feature is available only inside the professional version of Domus Organizer

ACL acronym stands for Access Control List, and it's a fancy word to explain permissions: some users can create, others can create and edit, others can only edit their own records etc etc. For more details and a more formal definition you can take a look on Wikipedia page.

Before continuing you should be very familiar with ACL and how it works, here you can find some resources on the topic:

However, this is a very short sum up of Joomla! ACL.

It is divided in two section: Actions and Access Levels. Each User Group can have different actions and they define what the user can do; Access Levels group several User Groups together and they define what the user can see.

For example, you can see properties belonging to an agency, but you can't edit it nor adding a new one to that agency.

We could provide a long, full of details explanation of Actions and Access Levels, but we preferred to create a set of examples, from the easiest ones to the most difficult ones, where we will play with Joomla! ACL.

Basic ACL setup

In this section we will cover the basics of setting up the ACL system, we will start from a very easy scenario and we will and up with a more complex one.

We will set component-wide permissions to our users, this means that if an user can see and edit a record, he will be able to do that on every record of the same type. Speaking of permissions, let's take a look at them.

The permissions inside Domus Organizer

Domus Organizer has several actions defined, if you go inside the component options you will find them:

Component administrator (domus.admin)

This permission is required to perform some highly risky or to touch very sensible informations:

  • Add a new agency

  • Delete an agency

  • Change access level to a customer/property

Administrative access (core.manage)

Users that have this permission set could access to the administrative area of Domus Organizer

Create property (core.prop.create)

This action allows the user to create a new property

Delete property (core.prop.delete)

This action allows the user to delete a property

Edit property (core.prop.edit)

This action allows the user to edit any property

Edit own properties (core.prop.edit.own)

This action allows the user to edit properties he created

Change property status (core.prop.edit.state)

This action allows the user to change the publication state of properties. More specifically, this permission is required to:

  • Change the internal publishing of a property

  • Publish/Unpublish a property from the site

  • Flag/unflag a property as "hot"

Create customer (core.cust.create)

This action allows the user to create a new customer

Delete customer (core.cust.delete)

This action allows the user to delete a customer

Edit customer (core.cust.edit)

This action allows the user to edit a customer

Edit own customers (core.cust.edit.own)

This action allows the user to edit customers he created

After this brief explanation let's take a look at different scenarios.

Single agency

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.


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.

Single agency with different permissions

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

Scenario #2: Property form with publishing fields disabled

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

Scenario #2: Customers view without any edit permissions
Scenario #2: Customers view without any edit permissions


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.

Single agency with different permissions and access levels

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

Scenario #3: Property access level

Figure 4.21. Scenario #3: Senior agent property list

Scenario #3: Senior agent property list

Figure 4.22. Scenario #3: Junior agent property list

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

Scenario #3: Edit access level


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.