<mose> luis what's your mod about phpgacl btw ?
<luigi> I really don't like that initiative
<mose> the perms system is reaching some limits right now
<luigi> Permissions are too core for Tiki to rely in a external package
<luigi> It's not neat to have the core tiki CMS modules written by one team and the permission system that manages the objects by another team
<mose> well, the idea is more to melt teams
<mose> but marc would talk about it better then me
<Chealer> I don't really know if that makes a different but phpGACL "team" has apparently a single coder
<Chealer> and 2 documentors
<Chealer> should be quite simple too
<luigi> I didn't like either the AXOs ACOs and those terms, things will be too complex for simple users
<luigi> or simple developers
<mose> what we have right now is not very easy too
<mose> but more flat
<luigi> Well it can't be easier, you just indicate who can do what
<Chealer> -> compared to too simple now 😕
<Chealer> we can decide if we wanna deal with AXOs by default or if it should be an advanced option
<dheltzel> we would have to make a simple interface for normal usage
<mose> right now perms are hardcoded in templates
<luigi> The point is if it is that different to change or enhance the internal tiki permission system
<mose> yes, that would be a change
<dheltzel> perhaps we could make an abstraction level first, with functions to check perms like phpGACL uses, then it could be dropped in if deisred, like LDAP
<Chealer> I think yes!
<mose> yup
<luigi> But you must also check permissions in templates
<mose> we can have an optionnal acl layer
<luigi> To know if you display or not a link etc....
<mose> well, about links display
<dheltzel> could the function call in the php script set some smarty vars that the template would check
<mose> we lack some tricks
<mose> dheltzel: yes, probably
<dheltzel> perhaps we need to encapsulate even the phpGACL functions into our own class to set needed vars after determinig perms
<luigi> Let's start with a simple question: what's missing in the current permission system?
<mose> spreading and inheritance
<mlaporte> audit trail
<mose> and many entries in lists retrievals
<Chealer> if you wanna get a look at a real problem I suggest you tracker 800081
<Chealer> but you could spent half an hour reading/thiking about it 😕
<luigi> Define "spreading"
<mlaporte> permissions inherited via category
<Chealer> I should reply to it about how phpGACL addresses that in not much time
<mose> like setting up perms for many content at same time
<luigi> I'm worried about one issue
<dheltzel> luigi: what areas of tiki are you most interested in improving now? and how much time can you spend with us for 1.8 ?

• mose chuckles
• dheltzel reporter mode OFF

<luigi> Some people will want "spreading", other "inheritance" etc etc etc eventually to satisfy all the interface will be too complex
<dheltzel> i agree, a perfect example is Zope/Plone
<luigi> How can you enhance the permission system with a zillion features without making it difficult to setup for users?
<mose> by having sets of rules
<mlaporte> make it optional
<mose> predifined settings
<luigi> But that will add complexity to the code and be a source of bugs...
<dheltzel> if MS and their usability team can't get perms powerful and easy to use at once, fat chance we weill 😊
<mlaporte> we are missing wysiwyca
<mose> that can be conducted with the actual system
<mose> matter of running each function and add perms checks
<mose> but it can have perfs issues
<mose> well, it will have in any case
<mlaporte> it would be nice to have a default permission for object created by user/group

• gmuslera (~gmuslera@r200-40-234-112.adsl.anteldata.net.uy) has joined channel #tikiwiki

<gmuslera> hi
<Chealer> hi
<mlaporte> like we have now for users are admins of wiki pages they create (but with more flexibility)
<mose> what phpgacl adds, is more modularity in the way to design your rights, and the possibility to change your mind without huge manual process
<mose> as it's sortof abstracted
<gmuslera> that remembers me that i have to put the design problems of actual permission system 😊
<mose> well, you can talk about that with luis ?
<gmuslera> the idea how is now have problems in restrictive environments at the very least, when you disable things by default but made exceptions for users or groups
<mlaporte> fyi, chealer was refferring to: https://sourceforge.net/tracker/index.php?func=detail&aid=800081&group_id=64258&atid=506849
<Chealer> >what phpgacl adds, is more modularity in the way to design your rights, and the possibility to change your mind without huge manual process
<Chealer> I totally agree. modularity doesn't mean more complex to the end user assuming we are careful in our default design.
<mose> it means more complex, a little, because more possibiliies
<mose> but those possibilities can be visually sorted
<mose> more easily that what we have
<luigi> First of all I think the current permission system must be supported so old users already happy with tiki can upgrade without having to learn a new permission system
<mose> sure a dual system would be nice for a transition if any
<luigi> So the current interface should be supported and we can add a new interface with more features for new users or users that need more power
<Chealer> that should be no problem.
<gmuslera> or to have a wizard that do that migrates current schemes to ACLs
<mlaporte> even current interface needs an improvement
<luigi> Hi Gustavo, no, old users will want the same interface to admin their permissions
<luigi> I know a good number of users that have 0 complaints about the permission system, specially intranet admins
<gmuslera> even if the new one is more clear?
<mlaporte> it's a pain to remove permissions
<Chealer> I'm not so sure avout that. It's current users who request more permissions
<gmuslera> I have 1 complaint about the permission system from an intranet admin 😊
<luigi> I didn't say all the current users liked the permissions
<mose> I complain for my intranet
<mose> 😉

• mose wanna be a user

<luigi> I said that we must support the x% of users that already use the interface without asking for new permissions or changes
<Chealer> but anyway, the default administration for Perms should be as easy as current, if not, easiyer. So 😕
<luigi> You can't make the interface as easy as it is once you start adding grouping, iheritance and so
<Chealer> "default administration" -> "default complexity level"
<gmuslera> well... we are talking without knowing how good or bad will be the other permission system 😊
<mlaporte> yup, and there should be a way (like phpBB) to list current rights for one user
<mlaporte> what can I do?
<mose> that can be tried as a module
<mose> a special extra feature
<mose> just to figure out
<Chealer> I read the whole description about phpGACL (finished yesterady). I didn't assimilite totally all ideas (I'mtalking about AXO)
<gmuslera> but
<gmuslera> oops 😊
<Chealer> (yet)
<luigi> I guess that a good way to start is to forget about phpGACL
<luigi> and think what our ideal permission system for tiki would look like
<luigi> in terms of functionality and interface
<luigi> Then we can analize if that can be implemented using phpGACL and how
<gmuslera> but anyway, i still think there are a flaw on how the permission system is designed, is not that is easier or harder, is just that in certain situations don't work or at least is not intuitive for users
<mlaporte> ok, I suggest we rewrite/collaborate on PermissionDev
<Chealer> yes
<Chealer> and I suggest above tracker as a basis for discussion
<Chealer> a "virtual case study"
<luigi> We should write some "must haves" and "nice to haves" for the (new) permission system
<Chealer> to figure out how to solve this problem in phpGACL is not that easy
<Chealer> btw phpGACL is really easy to visualize without AXO.
<Chealer> I'm wondering if the default phpGACL ARO tree is not more simple than what we have. at least it's Star Wars used to its limits.

Please list below what we want:

• Audit trail for everything,
  • admin settings
  • all registered users name are tikimessage links for instant accountabliity
• permissions for features (ex.: add tiki_p_wiki_history, tiki_p_wiki_similar, tiki_p_wiki_slides, tiki_p_wiki_export)
• ACLs for all objects, including users, groups, categories, etc
• Inherit permissions via category system
• permission documentation should be easily accessible. Maybe the current one line description in an overLIB box and a clickable link brings you to the explanation on FeatureXAdmin.
• Users should be able to check what they are allowed to do in their private section.
• by clicking on the name of a group, we should be able to see the list of group members.
• permission naming should be consistent. Please see TikiNomenclature

• The user interface should hide the actual impllementation from interface as much as it can. So in actual scheme for a wiki page instead of enabling/disabling tiki_p_view for a Wiki page, simply show "View" (or "Wiki View" if the context can't be told). Those more descriptive strings could also be translated, making a bit more multilingual actual interface.
• The programming interface could also hide most of the actual implementation. Using a function that tell for a given object that you can or not do some given action in certain environment will protect most modules from security implementation changes
• In the actual scheme object security overrides global security. But with security could be made a sorted list, evaluated sequentially and that returns the first line that matches, appending at the end of the object secuirity first the category rules and then the global rules. A special group "Everyone" could be used to cut the chain, enabling or disabling for any user the access if that point is reached. This way, the security setting for an object could use only its settings or left the global applied if no special restriction is found.

I think that this should work with actual permission implementation and with phpGACL without much changes in actual interface and programs if the above implementation abstraction is done.

• Object ownership could be part of the permissions list, and put in the top of it. That way an user could see/edit objects that he own if the system policy enables that.

Adopt a hierarchical "entitlements" based permissions model. This requires a highly generic data model, and will result in incredible flexibility later on. Many of the benefits only really come along when customisation is included, but here's something of an overview:

(I can't draw, so use your imagination). Start with a "top node" called System. System is an "entity". Below system are two countries, UK and US. Whilst they're called countries, they're just entities as well - we've just given them the name "country". The UK entity has the "UKP currency" entitlement, where as the US entity has "USD".

Below each country, there might be regions, or functional groups (eg. sales, technical etc). Below each ot those, perhaps more groups, or users. The key thing to note is that the hierarchy can be as high as you want, each entry is just an entity (although we may assign a name to an entity to make it easier for use to understand). The main difference between a "user" and a "group" is that the group does not have the "log on" entitlement.

As you go down the hierarchy, you only get access to the hierarchy of permissions enabled above you. For example, in this example, UK based groups get access to "Scottish Pounds" and "English Pounds". This means there must be hierarchical permissions, as well as a hierarchy of entities.

There's another complication... granting of entitlements. If a user in the UK is actually a manager, then she may be given the "grant" entitlement on a set of permissions (as well as the "create user" entitlement). Presumably, that manager would not be able to create more managers (so cannot grant the "create user") - that may take a "director" (ie. a manager with "grant create user").

The real complexity and power comes from the building of pages for users. Instead of simply writing a list of menu items, each item is entitled. If there's no entitlement, then you don't see the menu item. That same principle goes for all entities in a page, so in a Tiki sense, menus, modules, rss, etc etc.

Clearly, each page has to be built in a "generic" way that checks entitlements. Tiki is no where near that at the moment, because each PHP and TPL is written however the developer wants. With entitlements, all permissions code disappears from the PHP (and put into a library). The page output is less simple too, but once a framework is in place, making an entitlements based application is relatively easy (and as an application developer, you don't need to think about security!).

The main advantages are:

• Users get a view of the application that is completely geared to them. That is, a user can be created that (for example) only has "read blogs". That user will be completely unaware that there's also a Wiki on the system. Further, they might only have access to "UK blogs", so they would never know there were US blogs too (and unless they're hacking, will never see "permission denied").
• It is possible to delegate user administration to non-admin users. Those users may not have any other "write" capabilities, and could concievably be nothing except user creators or modifiers.
• It is possible to arrange that no user has overall, superuser access to the system (a bit like C2 security 😉
• Application developers do not need to consider security
• All applications use a consistent security model and permission set (new applications can easily add permissions too).
• The features and facilities open to users are decided by the systems provider, not the application developer
• The scope for presentation customisation in association with entitlements is enormous. Much of this is in Tiki already.
• The scope for more complex applications (like business systems) increases.
• Security becomes incredibly fine-grained

I'll be honest, I'm not an expert on this subject, but it's well worth some looking into. The possibilities it opens up are incredible - most obviously, one "generic" application that users see as one thing or another. The devolved administration means that larger teams are supported, the only way to run a really big site. Also, each "page" or application will operate in the same way, and more code is shared in a library. Whilst "scope" is the most obvious benefit, without entitlements, Tiki may remain somehwat limited to "small" applications.

Note: This is just notes for now, it will be formalized and made readable later.

Overview

In tiki there are users and there are groups. A single user can be in many groups, everyone is in the Anonymous group. Each group has a set of permissions assigned to them. See the end-user docs for more information along these lines. From a developer perspective, global variables are created that we can test when wanting to know about permissions.

When a page loads

The permission variables get defined globally, and are of the form $tiki_p_permissionname. They are all set to either 'y' or 'n'. That is why you see lots of scripts containing

if($tiki_p_something == 'y') { ... }

All (most?) of the things in tiki end up including tiki-setup_base.php, which is mostly a permissions setup file. First of all it gets a list of all the possible permissions from the database and sets them all to 'n'.

Then it uses userslib (lib/userslib.php) to figure out what permissions the user has. Specifically, it uses the get_user_permissions function to get a list. Then it goes through and sets $tiki_p_permissionname to 'y'.

Then it checks for admin permissions and makes sure that some permissions they imply get assigned. By example, having tiki_p_admin_wiki implies you should have tiki_p_view. The permissions associated to each feature are obtained with get_permissions.

At the end, all permissions are set to 'y' if you have tiki_p_admin permission.

Note: Besides setting up these permissions, tiki-setup_base.php just sets user preferences.

Usage inside template files is:

{if $tiki_p_permissionname == 'y'} ... {/if}

I think these are hard to convert to a new permission system. - ohertel