In this topic I would like to contribute to the discussion about desirable improvement of ACL permissions in Joomla 1.6. At first I have to say I’m not a programmer I only want to point out my requirements, expectations and possibility I have about new version of Joomla.
Sorry of my English, I don´t come from an English-speaking country. I´m a Slovak.
Many features are proposed:
- to determine what can the user see and use,
- to determine who, what, where + how and for whom can manage items,
- ACL permissions and ruled should be based on users
- horizontal improvement, extension of groups (I’ve named it TEAMS),
- content (articles, categories, sections) and items in other component or modules address only to specific teams,
- the present Groups (Author – Super Administrator) substitute for Roles, Functions,
- new components to administer teams (groups), users and their information,
- improvement of the component User Manager,
- changes of the users management should be in Joomla-core to cooperate with other components.
Joomla 1.0 and 1.5 have limited possibility to assign items (articles, items in Calendar, photos in Gallery) to specific group of users. Some components or plugins in extension´s category Group Access (http://extensions.joomla.org/index.php? ... &Itemid=35) were created to improve access permissions, but there were problems with them:
- Many of them were commercial,
- Some of them were core hacks (JACL +), and therefore was problem with upgrade Joomla to newer versions,
- Their co-operation with 3rd parties component were limited,
- They controlled only some parts of web-content (menu, section, category, article items...).
http://forum.joomla.org/viewtopic.php?f=500&t=266173 (especially contributions from VanCrey)
Why is it so needful?
I give two very common examples:
1. Example - Very good structured school website...
The Webmaster of this school can publish public items (articles, items in Calendar, photos in gallery...) for all users (headmaster, teachers, students, student’s parents...). But some items he wants to address only to teachers, or some classes. Or teachers would address items only to their students in some classes... For this reason I could use JACL+ for example, although it isn’t the best solution.
But in some classes there are some very creative students that want to publish their own items (common class newspaper). Of course Webmaster doesn’t allow them to publish their items for all users at school; they can publish items only for their class or classes in the same year, for example.
For this reason they can’t have roles of contributor as: Author, Editor or Publisher for everything, because nobody and nothing (except their conscience) can stop them to publish their items for all users.
2. Example – Very large web site
In a very large web site is very common to divide responsibility for the web content. E.g. first author (editor or publisher) is responsible for the section Sport, another for Culture... It means that the first author can manage items only in his section Sport and doesn’t have the access to manage items in other sections.
From these two examples follow partial conclusions:
- It doesn´t suffice to control who can or should SEE items, USE components or modules in front-end environment. It is very necessary to control Who? What? Where + How? and For whom? (these interrogatives I will explain later) can PUBLISH items, although only for his group.
- A user can belong to more groups, in the first group he can be only the user, but in the second group he can publish items only for his group for example.
- It would be complicated to create so many groups with their access levels I have users, even more groups with specific access levels for one user.
Why for some users only? Because many users remain in the biggest group: Registered without any permission to add, edit... anything and anywhere...
What to do?
1. Step – What can the user SEE + USE?
There are some user-groups in current versions of Joomla 1.0.x and 1.5x, but it is necessary to assign some items to specific groups of users. I’ve named these specific groups TEAMs to understand the difference between the group and the team (specific group). By the way I think the present expression GROUP (Pic1) isn’t right I would use the expression FUNCTION or ROLE, because “groups” as author, editor, publisher, manager or administrator are rather functions or roles than authentic groups.
The Team should be a “group” of users which has although primary the permissions as group Registered, but Team should associate users that should SEE the same content items and USE components or modules that are invisible for unregistered users, users in Group Registered or in other Teams. Basically it is the horizontal extension of groups (roles) I’ve mentioned in the introduction.
To administer teams it is very necessary a new component: TEAM MANAGER in the back-end. In this component you can create many TEAMs and assign them to specific access level. For example: When you create TEAM A, automatically is created access level_teamA.
Another useful component both in the back-end and in the front-end is a USER LIST. Thanks to this component a user could see other users in the same team(s), their information (address, mail, phone number...), send PM, or see if they are log on... Maybe the Community Builder is usable for this solution.
Very necessary is to improve the USER MANAGER component. I would put under the field Group a new multi-selective field named Team. In this field the administrator could assign a user to one or more teams. When a user belongs to none team, this field keeps free and the user sees only items for common access levels as public or registered. Thanks to these new steps Administrator could bring under control what users can SEE or USE.
In my opinion these changes are suitable for these sites too, where users have to pay to be a member of Team: Bronze Member, Silver Member, Gold Member... because you can easy determine the content for each Team.
When you assign users to teams and each team has its own access level, you can easy create content suitable for one, two or more teams. I give a very common example with the com_content:
You could set access level in the multi-selective box for the section, for the category or for the article item. Of course, the category inherits the access permissions and rules from the section; the article item inherits it from the category... So, let´s say, we have 4 access levels A, B, C, D. When you set the access permissions in the section only for access level A, B, C, then when you create a new category, you can use only these 3 access levels and the fourth access level D is invisible in this box.
It would be great when these desirable changes in Joomla-core cooperate with other components, e.g.: Pools, Calendars, Galleries, Forums, Chats, Comments, Blogs, Download Managers (DOCMan) or E-markets (VirtueMart) or modules (Menu).
2. Step – Who, what, where + how and for whom can MANAGE items?
Another very common problem is to determine WHO, WHAT, WERE+HOW and FOR WHOM can manage (add, edit, delete, move...) items. These five interrogatives hide conditions for adding, editing, deleting... an item. I will explain it:
- WHO? – a user from all users,
- WHAT? – means in which component or module can user add an item, e.g. com_content, mod_menu,
- WHERE? – it is needful in large sites with many sections and categories in com_content for example, to determine in which section or category can the user (author, editor or publisher) add an item.
- HOW? – user who contributes to the web content can be in section sport AUTHOR, but in another section culture PUBLISHER for example. Therefore I would use four possibilities to determine permissions of contribution: NONE – no access to contribute, AUTHOR – contributes as common Author, EDITOR – as Editor and PUBLISHER – as Publisher. For this reason I would maybe take away the Author, Editor and Publisher from the Groups and use them as role or function in this structured table.
Evidently the back-end users (MANAGER, ADMINISTRATOR) doesn´t need these rules, they can contribute, manage items everywhere without any limit.
- FOR WHOM? – some items should be address only to some access_levels. Here you can define, for whom this contributor can write items. For example there are set 4 access levels (to see) in a section then you can choose only among these 4 access levels when you want to add an article to this section. Of course the contributor can add an item only for these access levels (relevant to user groups: Public, Registered or Teams) whose member he is!
Let’s see how it can work... I remind once again I’m not a programmer, for that reason I only show what it can look like, how it can work, but I don’t know how it must be programmed! To answer and explain these five interrogatives I would use a well-structured table, which can be an organic part of user component to manage rules and permissions of all components and modules or a stand-alone component or small part of each component....
It is very necessary the improvements of the ACL permissions and rights. I don’t think the ACL permissions and rights are necessary only for groups, I think the ACL permissions and rights are mostly very necessary for (some) users. To determine what can the user see and use you can manage it with many teams (groups) however when you have to set who, what, where + how and for whom can manage items you have to give rights to the users.
In my opinion the present groups, except Public and Registered, are rather functions or roles than authentic groups. There are very needed some new components to administer teams (groups), users and their information.
These desirable improvements have to change the Joomla-core to allow cooperation with other components.