project tracker

Xarigami Core [key: xgami]

All trackers
Issue List
Road Map

Issue xgami-000540

Issue summary Details
Xarigami Core
+ xarigami cumulus 1.6.0

Extended Privileges: specializations in the modules

Reported:  Mar 28, 2010 10:11 PM    Updated: May 2, 2012 01:40 PM by

Version affected: - xarigami cumulus 1.2.0

The privileges are handled well in Xarigami thanks to some very robust classes defined in xarprivileges.php within the privileges module (core).

When it comes to handle multiple and organized items (such categories and articles), things become restrained, uneasy, or even impossible without some 'hacks' or parallel ways to handle rights.

More than that, among a list of module items displayed, it seems not smart to have to do n xarSecurityCheck. The worst is that in some advanced use cases, you might need to define as many privileges as you have items.

So the logic would be to handle permissions to some module items, directly in the module APIs. However, adding some parent inheritance, is not possible without revisiting Privilege Mask, and is still restricted by the basic way that the Privilege API resolves matching privileges.

A silly idea would be to revisit entirely the way privileges work in the core and also in modules, but it will be against compatibility sake and smooth upgrade.

Of course, it would be plained silly to revamp entirely the privileges in Cumulus. So the solution here is to make the most harmless implementation while giving the maximum versatility to module developers.

I have imagined many ways to link module and the core privilege management, most seemed to me to be not good enough, to be even worth mentioning. One thing kept my attention, the very object oriented nature of the code in xarprivileges.php. In fact, to benefit of the greatest versatility, connecting to the modules to those objects seemed to me to be the most efficient way. Well, I have not even considered to write any wrapper to connect to this API, would have been a nightmare. My solution is to directly create some module specific classes inheriting and extending the xarPrivilege/xarPrivileges classes.

Those extended privileges classes would be able to implement additional code and information to process much better the various items and entities relative to this very module. The core itself will eventually use them without really knowing it. The implementation is to eventually instance inherited classes instead of the based one.

So basically the privileges will work exactly the same as long as you have not overridden, or ommited to call based methods. Modules not having any implementation will continue to instantiate based privilege classes, working exactly the same as before.

How does it work? In the xarprivileges.php, there are two functions acting like instance builder.

So for instance, a new xarPrivilege() will be replaced by a new_xarPrivilege() call and will eventually use as arguments a string of the module name or an existing instance, to eventually determine an inherited class to use. Some sensitive methods in xarSecurity and Privilege module API have been updated to benefit of it. In some others, no changes were made as they are useless.

To implement it in the module: should include: - xarModSetVar('modulename', 'extended_privileges', 1) in the xarinit.php - a file in the module root folder called xarprivileges.php - for a module named 'categories', the new classes to add should be

class xarCategoriesPrivileges extends xarPrivileges { // Add your own specific or overriding methods (don't forget to call the base methods too for full compatibility) }

class xarCategoriesPrivilege extends xarPrivilege { // Add your own specific or overriding methods (don't forget to call the base methods too for full compatibility) } - some change in other files to replace or to enhanced the xarSecurityCheck() with some direct calls to the extended privilege classes.

The entire feature can be deactivated using a define switch in xarprivileges.php (XAR_ENABLE_EXTENDED_PRIVILEGES). But as I said, even on, it should be harmless.

I may eventually write a dev notes with these details. Still need to validate the naming for the instance builders. Seems to be named as private functions, which should not be valid to be called in the privilege module.

Commited in main branch! Lakys Mar 28, 2010 11:26 PM

Revision: 7b6560e3815ab3a8951ce71f42a92644caabf20d
Ancestor: 725d21ce05207237c364f579eecfe3478434edf5
Author: lakys-xarigami@lakeworks.com
Date: 3/29/2010 1:17:59 AM
Branch: com.2skies.xarigami.core

Modified files:

Jo, if you judge it is too intrusive in the core, or not safe enough, please feel free to remove it from the main branch.

Category module 1.4 (or 1.5) using it will come soon hopefully.

And feedback are most welcome Smile


Re: First fixes Lakys Mar 30, 2010 11:00 PM

Two days ago:
Revision: 48014d2776e18fdd04a8967965ad849751c4c267

Revision 22d803705709477deae4596d192f4564765d01d3

Those fixes are really important as it cannot work properly without them.


The extended privileges feature has been removed from the main branch and placed into:

thanks to Jo Smile


Split off classes Lakys Apr 25, 2010 02:46 PM

Well it seems I omitted to mention this work made early in April:
Privileges classes were split and placed into a xarclass subfolder.
At the module side, it will be similar.

For now xarprivileges.php will remain in the core, it will be removed. in the modules (categories for now).

Revision: 190a39eac39d1eed16cec6c719e06ca44a7cb0ae
Ancestor: e27e0f79a4fe46de83dbf0e01043a6faaf4856ba
Author: lakys-xarigami@lakeworks.com
Date: 4/6/2010 12:18:29 AM
Branch: com.2skies.xarigami.core.newprivileges

Added files:
Added directories:


Privileges: split off the classes into xarclass folder (new files included)