[15]Access Management in Joomla! 1.6

[the_real_svempa]

By the way, anyone really interested in the subject of discussion should of course read this:

http://phpgacl.sourceforge.net/demo/php ... anual.html .

No doubt many of you already have...

[Hackwar]

Petoroth, why should I set the rights you are explaining for each individual user? The moment that I have two users working in the same area, setting up the one group and assigning those users to that group is already simpler. Especially if you have a site with 10.000 users where you have a hundred sections with different access rights, its easier to create 100 groups with access to only one section and then assign the users to the different groups.

[EDIT]
Maybe I should explain this a little bit better: There is no group "Author". There is also no group "Super Administrator". There is a group "foobar" that has the right to access the backend and to change the global configuration, etc., basically all the stuff a "Super Administrator" can do. And then there is a group "foobar2", which is allowed to publish to section A and a group "foobar3" which is allowed to publish to section B. Now I have 4 users, one is part of the group "foobar", two are sole members of one of the two groups "foobar2" and "foobar3" and then there is the fourth user that is member in both "foobar2" and "foobar3". No need to create 4 groups.

[Hackwar]

MOD NOTE: Merged topics about ACL/user permissions

[masterchief]

A couple of impacts I've noticed as I've been developing an ACL solution for a client.

In phpGACL you can't mix 2-dimensional and 3-dimensional permission checks when creating your ACL's. Let me explain. There are two type of checks you can do.

1. Can a user do something, eg, can a Manager install Components (2-dimensional)
2. Can a user do something to an object, eg, can an Author create articles in the Sports category (3-dimensional)

You can mix 2D with 2D and 3D with 3D but you can't mix 2D with 3D because the access check will favour the 3D rule and you'll be locked out. To get this to work I've added an extra field to the aco table: allow_axos (and I've also added a note field as well be I can foresee that some help text on ACO's would be useful). This allows me to create and maintain pure 2D and pure 3D ACL's. For a 2D ACL, the AXO's are not shown.

Another thing is to be able to standardise the terminology in a user-friendly way. I propose the following for discussion purposes (it might have already been mentioned, sorry if that's the case):

ACO - is a Permission
ARO - is a User
AXO - is an Item generally but at the component level you would rename it to suit the context
ACL - is a Rule when it's 2-dimensional, and a Role when it's 3-dimensional

I think Hannes proposed it somewhere, and I've found it to be that case that dealing just with User Groups simplifies the whole process. In other words we ignore the ability to assign particular users to permissions, but stop at the group level. It might mean you need to create a few more groups but the overall result is simpler to understand (remember, introducing ACL is increasing complexity).

[woodsy]

I have been trying to understand the whole ACL terminology since the first discussions about introducing it into Joomla.

The other day I heard an explaination that I thought was fantastic and wanted to share with everyone. I'm guessing this is what people have been talking about all along but here goes anyway.

Rules - Allow rights to do something (access component, write articles)
Roles - Contain 1 or more Rules.
Groups - Roles are assigned to groups.
Users - Are assoicated with 1 or more groups.

I think this from basic understand is how AD (Active Directory) works.

Rules -> Roles -> Groups <- Users

Rule 1 } - Role 1
Rule 2 }
Rule 3 }

Rule 1 } - Role 2
Rule 2 }

Role 1 } - Group 1
Role 2 }

Role 2 } - Group 2

User 1 } - Group 1
User 2 }

User 1 } - Group 2

Does anyone see problems in how this is setup? Am I totally off the planet?

Cheers

Woodsy

[masterchief]

woodsy, with phpGACL you don't need the Roles step. You can assign what you call rules (I call them permissions) directly to groups - and you could liken that to a role if you like. At any rate, the same end result is achievable for what you propose.

[woodsy]

So is this method (minus the roles) what is being suggested to be implemented?

Master Chief being the 20th of March (Aus) when will we start to see some of the white papers moved into Under Review, and Accepted forums? I believe today was proposed as the cut off date?

Woodsy

[masterchief]

Regarding the method - not sure yet. All I was saying was the the currently library we use has the capability of supporting the end result.

I pushed the date out to the 25th - see my post about the closing date:
http://forum.joomla.org/viewtopic.php?f=500&t=276473

But don't worry, ACL is *definitely* going in.

[woodsy]

B-E-A-U-tiful - definately something we have all been waiting a long time for (Mambo days)

Will this be the modified development life-cycle from now on? Allow a month or so after a release to fix bugs while in parallel white papaers are created?

I think its fantastic method to allow the dev's to concerntrate on bugs, and at the same time have a clearly defined scope of works the community are seeking to be completed.

Any chance of getting a discussion area about the white paper process, don't want to go off topic on ACL's

[masterchief]

Just start a new topic with your question about White Papers. Given this is new we'll probably change things as we go. For smaller tasks I'd say we'll just implement them. For something like ACL I'd say we'll look at all the suggestions, then develop a functional specification and then ask the community for comment again at critical points, or maybe have an on-going discussion in the forum ... not exactly sure yet.

[masterchief]

Another point to bring up is, for example, when editing content. Do we apply fine-grain access control like "Allow user X to create only in this category" to both backend and frontend - or do we make simplification and apply this only to the frontend.

I've been playing recently (actually building it now) with a separate frontend component that allows you to edit content frontend, and allows you to apply access control at the category level (note: this is just for editing, not for view access levels). The user gets a control panel that is populated by modules to see such things as recent articles, recent modified article, categories you can create articles in, and so on.

Breaking the edit features into it's own component has some significant advantages because you can apply different configuration to this component. This methodology seems to work well (separate view and edit roles in the frontend with different components) and allows the admin components to be kept much simpler. Locking down the backend would involve some serious query joins and additional UI logic which I really don't want to start thinking about

The use-case of course requires that your everyday content providers only access the frontend, leaving the admin for more senior managers of the site. This may not be universally applicable but a workaround could be another backend component that clones the frontend version, and you just lock com_content away from some backend users.

I'll post some screenies if anyone is interested.

[woodsy]

Ideally I think you'd like that granularity at both front-end and back-end as some 3rd party components only have a back-end.

Would love to see what you've done so far. Of course would love to help out in any ways.

[spike00]

Another point to bring up is, for example, when editing content. Do we apply fine-grain access control like "Allow user X to create only in this category" to both backend and frontend - or do we make simplification and apply this only to the frontend.

I've been playing recently (actually building it now) with a separate frontend component that allows you to edit content frontend, and allows you to apply access control at the category level (note: this is just for editing, not for view access levels). The user gets a control panel that is populated by modules to see such things as recent articles, recent modified article, categories you can create articles in, and so on.

Hmm this seems to be as a third 'layer' between frontend and backend.

I don't know, but maybe I'd prefer to have full backend granular permissions than frontend. Going over, if I must choose, I'd prefer backend and not (at all) frontend edit permissions, since from backend you may give an user / role /group all kind of permissions needed, but if you have some tasks 'manageable' only from frontend and some others only from backend, this would lead far from the management semplicity that, at the moment, makes Joomla the simpliest cms to manage. The control panel of Joomla 1.5 is something wonderful (ehm.. sorry for my obscure english )

[bidsro]

Hello

I use Joomla for our department intranet (over 1000 peoples) so appling fine-grain access control it's a mandatory task for me. I use JACL for the moment but for sure, i'm looking for a better way to improve access. What i would like to see it's a combination between existing permisions and other components for grup access. In my opinion, having options like view + read + write + edit + delete + disable for each user and applied for each section/component of site it's the best way. I think the new version of ACL should be focused on frontend permissions but with option almost similar with those from backend (creating nested categories (another "must" for Joomla), give and restrict access, see or not see information etc)

Sorry for my english

Thank you

[the_real_svempa]

Well, i did not really think I needed any individual module permissions for any of my sites. But maybe I have changed my mind.

Anyway, such a system is now implemented at http://www.nodingegolf.se . Each registered user (or above, of course) can have his/her individual module permissions. I am even thinking of making it possible for the individual user to influence his/her view of the site by deselecting modules from a list. Certain modules would be mandatory I guess, the rest could be deselected.

Also there is the possibility to have "private" modules that are owned by one or a few users. These two cases correspond to codes "D" and "A" in my system.

You can see how this works in practice by logging in as either testare / test1 or testare2 / test2 . For testare all modules in the right column have been deselected, for testare2 nothing is changed. The permissions per user kan be shown using the menu choice "Modulvisning" in the Extra Menu.

While you are at it you might also like to check the systems for menu items permissions and publishing permissions, since both systems are active for these users. They are both publishers, but are only permitted to publish within certain categories, check this by using the menu choice "Publiceringsbegränsningar" in the Extra Menus. They are also denied usage of certain menu Items, check this by using the menu choice "Menybehörigheter". On top of these limitations they are also denied access at "Golfklubben/Styrelsen/Protokoll... since this menu item is exclusively "owned" by user jeol, which makes it impossible for other users to access.

[skOre]

Sorry for being a few hours late to the deadline, I have another on coming up in a couple of minutes if you don't mind.

Synopsis
Besides the Authentication Plugins, which govern whether a user can log in and are complementary, we also need to have Authorization Plugins that are additive ("a user has to meet these requirements on login").

Proposal as .odt
Proposal as .pdf

[the_real_svempa]

Now for the final step, to implement the Team functionality. My next site will probably be for a basketball club, and I think they would like to have this. I feel, however, that it will not be practically possible at present to have 100% of all the nice things described in the excellent White Paper written by petoroth that started this discussion.

So this is the logic I think can be easily constructed, without increasing the number of Joomla! Hacks from the existing three (of which only two are important for the Team functionality). I propose the following rules:

1. A user can only be a member of ONE Team at a time (except by using separate user ID:s of course).
2. For each Team a Control User is defined. This could be a nonexisting user number.
3. The content viewing rules for a Team Member are inherited from the Control User.
4. A Team Member cannot have individual viewing rules.

Regarding rule 1, this is because it is difficult to reconcile two or more sets of viewing rules. Regarding rule 2, this user could be an existing user, in that case all individual viewing rules for this user are applied to the entire Team, but it could also be a ficticious user ID. Regarding rule 3, this means that we can use the existing hacks by simply substituting the Control User's user ID for the "real" user's user ID. Regarding rule 4, again it is difficult to reconcile two sets of viewing rules and it also seems more logical to me.

What is needed for implementation then? As said before, one new table to define the Teams and one new table to relate Teams to the member users. In the code a check to see what Team, if any, a logged in user belongs to, and then substituting the user ID of the Team Control User for the original user's ID before applying the already existing Joomla! Hacks.

We have a saying in Sweden: "The best is sometimes the enemy of the good". In this case it might be interpreted as "We do not want any kind of better ACL system now because we would rather wait for phpGACL". Of course phpGACL is far superior conceptually to any Hack I or anyone else can write on top of Joomla! 1.5. But what if it takes a long time before we have phpGACL fully implemented? Both my users and the people in charge of the organizations for whom I would like to make a well functioning Joomla! site are not very satisfied with the ACL we have today...

[bobtheslob]

A freelancer group?
I am really glad to see the issue of ACL getting so much attention! In my view, it is certainly the most important topic for future updates. I have the following suggestion, which I will explain in layman's terms (since I am a layman and very much "programatically inept"):

What?
I propose the implementation of a user group. Let's call it e.g. "Freelancers". A freelancer would be placed one level below an author in terms of permissions. The freelancer would be allowed to create new articles, but would not be allowed to publish the articles himself. Instead an editor or publisher would have to accept the submission (i.e. publish the article), perhaps after receiving an email notification about the new article. Furthermore, the freelancer would not be allowed to edit his own published articles (since he would then be able to circumvent the restrictions by simply editing his article after publication).

Perhaps freelancers could be restricted to publishing in certain categories (this could also be implemented on the editor level, as long as there is some kind of category level permission control).

Why?
A large, organized website needs to be in total control of all its content. This would require a way of restricting access - call it "damage control". One disgruntled journalist should not be able to put his own angry words on the front page of the website. Real world newspapers come to mind here. Very few - if any - newspapers allow their journalists to publish anything, before the story has been fact-checked, proof-read etc. For this purpose, newspapers employ editors and sub-editors. Their (sole?) purpose is to make sure that the spirit, image and standards of the site are upheld.

A "freelancer" group would be especially useful for news websites, or any website based on collaborative authoring and content, for that matter. In the digital age, you might not ever have met your content contributors face to face. In other words, you have no way of knowing whether you can entrust a contributor with publishing privileges. So why not copy the time-tested method used by newspapers. Sub-editors control categories and freelancers can't publish anything that isn't approved.

How?
Since I am not a programmer, I don't know how a feature like this could be implemented. But in my view, it would probably be easier to implement (and explain), than a "per user" ACL system. In other words, it would perhaps be the simplest way of accomplishing a very important task. It would be invaluable for news sites and any other site that relies on many different external sources such as freelancers. And it would basically just be an additonal user group with a few modifications.

I hope my suggestion makes sense. If I am repeating someone else's suggestion I apologize. I have skimmed the ACL threads and haven't noticed anything completely similar.

You guys have done a great job with Joomla 1.5! Keep up the good work!

[bidsro]

I search on internet and found this link about ACL, SACL, CACL etc: http://en.wikipedia.org/wiki/Access_control_list. Another good place to look it's Drupal. Also, SMF and Phpbb have good ACL. So, based on this information, I will try to detail about my idea of ACL. In my opinion, simple option to create groups will be enough to everyone, i am more concern about what those groups can do. For example, a registered uses can:

view - i can view only intro or see attachments (also should be applied for visitors if necesary)
read - i can read all information, including attachments
add - i can add information in categories where i can read based on my group access
edit - i can modify own information
delete - i can delete only my own information with notification to admin
move - i can move my information among other categories where i have access to add
publish/unpublish -i can do that with my own information
create - i can create new categories/folders
explore - i can explore my own and other folders
restrict - i can restrict access to my information for other users who have same access level

and of course, for superior levels, should be a combination betwen above option and group access. For example, an author can have default rights:

read, add in every categories, edit/delete/move/publish/unpublish all information from his group

a editor could have rights for multiple groups and publisher for all groups. Then in backend, an admin could add/edit all users/content and super admin it's GURU, can do everything he want


Thanks

[StarShaper]

Good article Hackwar!

[the_real_svempa]

My own Joomla! Hack Access Control System is now fully functional and implemented at a few sites, notably http://www.nodingegolf.se . IMHO it satisfies 100% of the criteria put forward by jmonarch, sbrawner and df23, and constitutes something like 90% of what signature petoroth defined in his great White Paper.

Advantages:
1. Can be used directly instead of waiting for an unknown ACL system sometime in the future.
2. Simple to implement, affects only three modules of Joomla! code and needs a minimum number of new and very small tables, five to be exact.
3. No existing code is changed or deleted, the Hacks consist entirely of new code that is inserted into three PHP modules.
3. Causes little or no overhead when used.
4. Easy to understand because of its simplicity.
5. Can be used in its different parts and with or without Teams.
6. Does not change or delete anything in the existing Joomla! functionality, only adds to it.

Disadvantages:
1. It is a Hack and not an integrated part of Joomla! core, and by its nature it cannot be converted into a Component or Plugin, so it needs to be re-implemented if any of the three changed modules are rewritten for a future Joomla! release.
2. There are a few maintenance programs for the five new tables to simplify the administration of the system. They could probably be converted to a backend Component, but are today operated from the frontend in wrappers with password control.
3. The existing version of the content viewing permissions Hack is not usable in combination with SEF.
4. When a menu item is denied to a user or Team it is still visible, and clicking on it will raise a 403 'Not Authorised' error. Using the 'backwards' button in the browser will however return the user to his/her original screen with no side effects. Hiding the denied menu items is of course possible, but would require another Hack.

OK, now to the functionality, that is 'How it Works'.
First: the Publishing Permissions Hack (previously described in an early post).
A user ID can be entered into a table that relates user ID:s to category ID:s. If this user is designated as an Editor or Publisher he/she will then only be able to edit or publish within the categories the user ID is related to.

Second: the Menu Item Access Hack.
A user ID can be entered into a table that relates user ID:s to menu items. A code of either "D" for Deny or "A" for "Access" must be given. A code of "D" means that the user is denied access to this menu item. A code of "A" implies that the user has access to the menu item, AND that no other user ,except those also related to the menu item with a code of "A", can access the menu item.

Third: the Module Viewing Hack.
A user ID can be entered into a table that relates user ID:s to modules. A code of either "D" for Deny or "A" for "Access" must be given. A code of "D" means that the user cannot view the module. A code of "A" implies that the user can view the module, AND that no other user ,except those also related to the module with a code of "A", can view the module.

Fourth: Teams
A Team can be defined by entering its ID and name into a team table. Each Team is "controlled" by a Control User whose ID is also entered into the table, this user ID must exist in the user table. Any user can belong to any Team, but only to one Team at a time. Members of a Team are given the same rights of access to menu items, and the same module viewing rights, as are defined for the Control User.

Anyone wanting to see how the Hacks actually work should log in at http://www.nodingegolf.se with user name 'Testare' and psw 'test1' or 'Testare2' psw 'test2', both have Publisher status. In the former case you will see an extra user menu appear where the maintenance programs can be accessed. Using 'Publiceringsbegränsningar' you can see if a user is affected by the Publishing Permissions Hack. Pls feel free to try to publish something outside of the categories defined! Any published item WITHIN the defined categories can be viewed using 'DPP testsida'.

Using 'Menybehörigheter' you can check on all user's menu item access rights. Pls note that user 'jeol' has "ownership" of a particular menu item, it can consequently not be accessed by any other user. it can also be seen that users 'Testare' and 'Testare2' have shifting access rights to the three last items on the 'Extrameny'. Try accessing a denied menu item!

Using 'Modulvisning' you can check on all user's module viewing rights. Pls note the differences betwen the viewing rights of users 'Testare' and 'Testare2'. Pls also note that the module 'Extra användarmeny' is "owned" by users 'Testare' and 'Sven' making it impossible for any other user to view it.

Using 'Teammedlemmar' you can see that three Teams of two members each are defined. Members have the user names of 'memberxx' and psw 'xx', members with even numbers are Authors while odd numbers are just Registered users. Teams are controlled by users 'Sven', 'Testare' and 'Testare2'. Pls log on as a member in a Team to check that all viewing rights and limitations given to the Control User are applied to the members.

This system is entirely satisfactory to myself (and possibly to some others), but of course it is not a genuine ACL system, much can be said about its limitations. Hopefully this practical example will be of help also in defining the native Joomla! ACL-to-be. For me it is purely a stopgap solution, but it is necessary to have since there is no other way I can get the same functionality.

[Malenx]

Would you be willing to post the entirety of your hack svempa? I'm in need of a similar setup, but am learning php and sql as I go.

Thankfully your hacks posted thus far have been a good catalyst for me dive into a deeper learning.

[the_real_svempa]

Malenx,

No problem, pls observe that my PHP experience is virtually nil, my Joomla knowledge IS nil and there is a lot of trial and error behind the hacks since I had to take a "black box" approach to the problem. The first Hack, for detailed control of publishing permissions, is not changed from the version I posted some time ago, and I understand you have seen that.

The Hack for controlling menu item access affects the module router.php in /includes and is also in two parts, first a function which I put at the very end of the module:

Code: Select all

/** Joomla! Hack by Svempa for User Menu Permissions)
	 *
     *  Get menuitem - user connection from table
     *
     */
    function get_menuitem_user($item)
	{
		$db =& JFactory::getDBO();
		$user	= & JFactory::getUser();
		$user_id = $user->get('id');
//Deny access if user not logged on and the menu item is protected from any registred user		
		$aid	= $user->get('aid',0);
		if (! $aid) {
			$query = 'SELECT count(*) FROM #__menuitem_user as g WHERE g.menuitem_id = '.$item.' AND g.function = "D"';
			$db->setQuery($query);
				if (!$db->query()) {
					JError::raiseError( 900, JText::_("Fel vid dbaccess ".$query));
					} 
			$number = $db->loadResult();
			if ($number > 0) return -1;
			}
// Check if the user is a member of a Team, in that case substitute the control id for the user id
		$query='SELECT t.control_id as cid FROM #__team_user tu, #__teams t WHERE tu.user_id = '.$user_id.' AND tu.team_id = t.team_id';
		$db->setQuery($query);
				if (!$db->query()) {
					JError::raiseError( 904, JText::_("Fel vid dbaccess ".$query));
				}
		$cid = $db->loadResult();
		if ($cid) $user_id = $cid;
// Check deny-table		
// Deny access if user connected to current menu item in deny-table	        
		$query = 'SELECT g.menuitem_id'
			. ' FROM #__menuitem_user AS g'	
			. ' WHERE g.user_id=' .$user_id. ' AND g.function = "D" order by g.menuitem_id';		
		$db->setQuery($query);
				if (!$db->query()) {
					JError::raiseError( 900, JText::_("Fel vid dbaccess ".$query));
				}
		$mids = $db->loadResultArray();
		foreach ($mids as $menuitem_id)
			{
				if ($menuitem_id == $item) return -1; 
			}		
// If not in deny-table, check allow-table
// If menu item in this table, user id must be connected to current menu item to allow access		
		$number = 0;
		$query = 'SELECT g.user_id'
				. ' FROM #__menuitem_user AS g'	
				. ' WHERE g.menuitem_id=' .$item. ' AND g.function = "A" ';		
		$db->setQuery($query);
				if (!$db->query()) {
					JError::raiseError( 900, JText::_("Fel vid dbaccess ".$query));
				}
		$uids = $db->loadResultArray();
		foreach ($uids as $uid)
				{
				$number++;
				if ($user_id == $uid) return 0; 
				}
		if ($number == 0)return 0; else return -1;		
	}

Second a few lines of code which should be put just before the 'return' statement at the end of one of the first functions in the module, called 'parseRawRoute'. After the change it will look like this:

Code: Select all

// Set the active menu item
		$menu->setActive($this->getVar('Itemid'));
		
	// Joomla! Hack by Svempa
	// check menu item permissions
		$itemid = JRequest::getInt('Itemid', null);	
		if (isset($itemid))    
	    	$mp = get_menuitem_user ($itemid);	    
    	if ($mp < 0)  JError::raiseError( 403, JText::_('Not Authorised') );		
	// end of hack	

		return $vars;
	}

As you can see the Hack uses a new table called '#__menuitem_user' having three columns, two of them of type INT called menuitem_id and user_id which are used to relate users to menu items. The third column is a VARCHAR(1) and can only have the values 'A' or 'D'. A value of 'D' means that the menu item is Denied to the user, while a value of 'A' means that the user has Access to the menu item while it is Denied to all other users who are not also given explicit access to the menu item.

The Hack for viewing rights of modules affects helper.php in /libraries/joomla/application/modules. The code is to be inserted just before the return statement of the last function called 'load'. It will look like this after the change:

Code: Select all

// Joomla! Hack by Svempa
// Check modules permissions
		$db =& JFactory::getDBO();
		$user	= & JFactory::getUser();
		$user_id = $user->get('id');
// Check if the user is a member of a Team, in that case substitute the control id for the user id
		$query='SELECT t.control_id as cid FROM #__team_user tu, #__teams t WHERE tu.user_id = '.$user_id.' AND tu.team_id = t.team_id';
		$db->setQuery($query);
				if (!$db->query()) {
					JError::raiseError( 904, JText::_("Fel vid dbaccess ".$query));
				}
		$cid = $db->loadResult();
		if ($cid) $user_id = $cid;
// Remove modules denied to this user		
		$query='SELECT mu.module_id as mid FROM #__module_user mu WHERE mu.user_id = '.$user_id.' AND mu.function = "D"';
		$db->setQuery($query);
				if (!$db->query()) {
					JError::raiseError( 902, JText::_("Fel vid dbaccess ".$query));
				}
		$mids = $db->loadResultArray();
		$total		= count($modules);
		if ($total > 0 && count($mids) > 0) {		
				for ($i = 0; $i < $total; $i++)	if (in_array ($modules[$i]->id,$mids)) unset($modules[$i]);	
				$modules=array_values($modules);
				}
//			}
// Remove modules if they are exclusively allowed to another user
		$query='SELECT DISTINCT mu.module_id as mid FROM #__module_user mu WHERE mu.user_id <> '.$user_id.' AND mu.function = "A" AND NOT EXISTS '
				.'(SELECT mx.module_id FROM #__module_user mx WHERE mx.user_id = '.$user_id.' AND mx.module_id = mu.module_id AND mx.function = "A")';
		$db->setQuery($query);
				if (!$db->query()) {
					JError::raiseError( 903, JText::_("Fel vid dbaccess ".$query));
				}
		$mids = $db->loadResultArray();
		$total		= count($modules);		
		if ($total > 0 && count($mids) > 0) {		
			for ($i = 0; $i < $total; $i++)	if (in_array ($modules[$i]->id,$mids)) unset($modules[$i]);	
			$modules=array_values($modules);
				}
// end of hack

             return $modules;

The Hack uses one new table called '#__module_user' which is constructed exactly like the table in the previous Hack, only this time it relates modules to users.

A difference in the logic is that while a menu item protected from any registered user also is protected from all guests, a module that cannot (probably by own choice) be viewed by a registred user can still be viewed by guests. However, in both cases guests are barred from any menu items or modules that are Allowed to one (or several) user(s) using the code 'A';

For the Team functionality a Team table called '#__teams' is needed, it must contain a team ID and a Control User ID, the rest is up to you. I have put in a name and a comment column in my version. Also we need a table relating users to teams called '#__team_user', this table needs only two columns type INT named team_id and user_id.

I also use 13 small utility programs for maintaining the tables, they are extremely simple (which is why they are so many) and all text is in Swedish. But if you wish I could zip them into a file and mail them to you, I note you have a mail address published.

Hope this code will be of help to you! Do not be too critical of the coding, remember that my PHP skills are low :-)!

[masterchief]

the_real_svempa, Malenx, would it be ok if you discussed the fine details of the hack off-list or in another thread. Thanks.

[petoroth]

Not only for Hackwar

Petoroth, why should I set the rights you are explaining for each individual user? The moment that I have two users working in the same area, setting up the one group and assigning those users to that group is already simpler. Especially if you have a site with 10.000 users where you have a hundred sections with different access rights, its easier to create 100 groups with access to only one section and then assign the users to the different groups.

I try to explain myself. You wrote, that it is easier to create so many groups with access to only one section and then assign the users to the different groups. I don´t think.
Why not to build ACL on your ideas?
I underline once again that one user can be for one section author and for another publisher... => According to you have said about creating group for publishing in section or category and my mention of possibility of user to be Author, Editor, Publisher for a Category/Section I think it is not the right way to administer the access permissions. Then you have to do for one section minimally 3 groups: GROUP1_author, GROUP1_editor, GROUP1_publisher.
Then we have to think about other components,3rd parties components, moduls..., not only com_content.

A very good example is the cACL MVC componnet (demo site: http://dev.tradevn.info/administrator/), although it is a comercial solution and maybe core-hack.
I always think the publishing permissions must be based on Users.

[masterchief]

Thanks for your comments petoroth. Implementing ACL is quite simply a huge task and will be done in stages. We may eventually get to the point where individual users can be singled out (the system will support it anyway) but we'll be taking it in steps. ACL brings complexities in design and UI (trust me, I've been working semi-solid on it for a few weeks now). I'm predicting the first cut in 1.6 will be fairly rich but we have to make some simplifications so that most of the userbase "get it" without having to dig into the documentation ... that's going to be a challenge. Limiting assignment to user groups is a logic "first go" simplification to make rather than trying to do everything at once.

Hope this helps.

[ircmaxell]

Hmm, interesting... Could you provide a use case for this? Why would this be needed instead of a custom authentication plugin?

[skOre]

Of course!

The best example would of course be my AEC Component, which restricts login based on whether a user has a membership or not (and redirects if not). At the moment, I have to use an authentication plugin and tell my users to disable all the others... since one other active authentication plugin that returns an OK would spoil the effect.

I could of course make it a system plugin, but that would get quite ressource hungry.

If you want me to make up other examples... Say you have additional components that require the user to have data in their area, like a forum profile. Now you can certainly let the user put that in on registration, but what if you want to add the component in later and have the user do the additional "registration" on their next login?

Or it could be that you have a central server which is called on user login to make sure that the user is authorized. So in that example, everything relating to the login process authorization is not on the original server itself and thus cannot be incorporated into the standard login. Instead of hacking that, having a dedicated authorization plugin would help a lot.

Personally, I find it to be a logical necessity - if you have OR, you also need AND.

[adrianlewis]

Hi Andrew et al,

Just thought that I'd pop my 2 cents in here. I've been following this topic avidly for some time now, from RokACL to where it is going today. This might be taking things a little too far here but there has also been a significant amount of talk about user metadata for use with community type sites. Can we take this into consideration when setting up groups so that groups can also have metadata easily attached to them?

Many groups would be behind the scenes but pretty soon people will want to use the ACL groups for front end activities. One such use as has already been mentioned in this thread would be for sports teams for instance. Personally, I would like to have groups for company/employer in a project that I've had in the pipeline for some time now. This may be a case of using a 3rd party extension like groupjive which somehow links into the core ACL groups but I personally would love to see a standard for both user and group metadata.

To begin with, I would have thought that it would be relatively easy to implement some form of group type - just one additional db field per group that can be used in queries. So for instance if you wanted to see what social groups a user is in or the sports team that a user is in etc etc, you can simply refer to the username and find groups with type x rather than trying to get all groups, and then filtering out the groups that should only be seen by backend admins for ACL purposes only.

For sites that already have user metadata for individual users' profiles, the ability to have teams, groups, bands etc with their own profiles too would be great. I'm not saying that this should be done in 1.6 (it would be amazing though!) but any work done with what does end up in 1.6 needs to be extensible, and preferably in tune with the way that user metadata is likely to be stored.

Cheers,

Adrian

[the_real_svempa]

This is from another thread, http://forum.joomla.org/viewtopic.php?f=500&t=266296 :

onBeforeSave
The onBeforeSave trigger is designed to allow the system to handle updates of content before it goes to the database. onBeforeSave would be tied to a response that would determine if the content should actually be saved. If a false has been returned by any plugin responding to an onBeforeSave event then the processing should be aborted and the content not saved. The reason why we have this behaviour is to allow for extended workflow for content. For example users may be able to update a content item but it might require another user to approve it before that new version is released to the website. Without the ability to reject a content update (the plugin rejecting should probably store it somewhere else, though it may also be an ACL plugin that rejects based on other criteria). This trigger should be passed an object (or objects) containing the new content and the old content.

The response from the content save update is an object that has three states: a default accept state, a do not save and a reject. The default accept state is used for items like simple record keeping or anything else that might go through (normal state at present). A do not save state is when an object has been saved elsewhere and the user should be directed to the normal list page with the appropriate message. The final one is a reject which means that the edit may not have been saved anywhere and has been rejected entirely and the user should be redirected back to their content item (with all of its content in tact) and a message noted as to why it was rejected.

This would be a really nice feature. My first hack for publishing permissions could then be rewritten as a plugin, and the onBeforeSave trigger could also be used for many other things. If it is difficult to implement this trigger for everything that goes into the database I would like at least to have this trigger for content items.