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:
ACL concepts overview (beginners)
Joomla! ACL: Access Levels (beginners; scroll all the way down for a very good video)
A case for role-based ACL (advanced)
Implementing role-based ACL (advanced)
ACL Manager is a third party commercial component which can help you effectively managing ACLs on complex sites.
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.
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.
Domus Organizer has several actions defined, if you go inside the component options you will find them:
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
Users that have this permission set could access to the administrative area of Domus Organizer
This action allows the user to create a new property
This action allows the user to delete a property
This action allows the user to edit any property
This action allows the user to edit properties he created
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"
This action allows the user to create a new customer
This action allows the user to delete a customer
This action allows the user to edit a customer
This action allows the user to edit customers he created
After this brief explanation let's take a look at different scenarios.
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:
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:
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:
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.
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:
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:
As you can see, Junior agents have fewer permissions, so they won't be able to edit any customer nor change property publication.
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:
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.
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.
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.