RFC: ACL Asset management in 1.6

[Hannes Papenberg]

Hello folks,
first I have to apologize. As I said in the status update for 1.6, I
promised to deliver this quite some time ago. But now here is my first
proof of concept on this one.

What is all this about?
The topic of this post is the asset management in the ACL of Joomla 1.6.
Assets are the content objects in Joomla, for example categories,
articles and weblinks. At this moment, you can only control assets in
1.6 in terms of viewing permissions, which are controlled by
Level3-rules. Other actions, for example editing an article, should be
controlled by Level2-rules. Andrew proposed one way to handle these in
1.6 by saving a JSON array in an extra field for each content object
with its permissions for the different groups. In my opinion this has
some flaws, the first being the requirement for a storage object
equivalent to a MySQL text column to handle permissions for an object.
If we are talking about files or other data objects that we want to
control which are not necessarily stored in the database, this makes it
more complicated, since we need a seperate datastorage for the access
informations. Also, for the developer its another system to learn,
besides the "normal" ACL system. Thats why I tried to implement the
asset management inside the original datastructure.

How does it work?
Not all of the now described features are already implemented in the
proof of concept. Nevertheless, here goes nothing:
If you need to control the access to your articles (everything except
viewing that is) as a developer, you create an XML file with some
informations about this. Then, in your edit screen for that content
item, you include a new object, which reads the XML and renders a proper
form to set the access rights for that content item. Upon saving in a
JTable object, additional code is executed that either stores the new
rules or attaches the asset to the rules of a parent. The work involved
for a third party developer is pretty minimal and changes to a parent
asset automatically traverse through the whole tree.

For the user, its pretty basic to use. If you edit an object, you have
an additional radio button, which enables if you want to inherit the
rules from the objects parents or if you want to create seperate rules
for this asset. If you inherit, thats all you have to do. If you don't,
you get a list of groups, which, upon clicking on one group, shows a
list of actions with checkboxes besides them. You select what you want
and thats it. Click save when you are done with editing that object and
all your rules are saved.

Now whats still missing?
At the moment, this code just shows that the concept is possible.
Otherwise, its pretty messed up... The XML file to control the action
list is not implemented yet, it is only implemented in the com_content
categories at this moment and the code is horrible. This needs a lot
more clean up before it can go into trunk permanently. Also, the output
currently looks bad and a check if the user is even allowed to edit the
access rights needs to be implemented, too.

I wanna have a real world example!
Think about content categories and articles. Articles are children of
content categories and content categories are children of their parent
content categories. So we set up a content category and give it some
access rights. For example the usergroup "forum moderators" can only
write new articles, but not edit old ones and not publish them in this
category. Then we create two more categories in that first category.
They both inherit the rules from their parent category. We write about a
hundred articles in those categories, which all automatically inherit
from the first category.
Now we notice that we also wanted to give the usergroup
"facilitymanagers" edit access to those articles. So we edit the first
category, set the access rights the way we want and save. Automatically
all the other objects get the same access rights. But now the
facilitymanagers have access to all three categories. We only wanted
them to have access to the parent category and one of the two child
categories and their articles. So we edit the one category that they are
not allowed to edit and set the radio button from "inherit" to "don't
inherit" and set new access rights. Again, saving and all content
objects have their rights as expected.

And where can I find this magical code?
Here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=17890
Attached to this Trackeritem is a patch against the current 1.6 trunk.
if you test this, please make sure that you re-installed after applying
the patch, since it adds a new field to the jos_access_assets table.

I'd like to hear your questions and opinions, also in comparison to
Andrews proposal, so that we can make a community driven decision here
which idea to use. This is most likely the main reason why we haven't
got the Beta yet. I'd like us to make a decision about this until
wednesday, september 9th, (thats next week) so that we can properly
implement this for the Beta and have enough time. Of course, if the
discussion requires it, we will push the time limit. This is an
important decision that has a lot of impact on Joomla, so I hope we can
have a heated debate about this in the coming 5 days. Since both Andrew
and I are a bit biased about which implementation to choose, I also hope
that a lot of you will state their preference on which solution to choose.

Hannes

[Andrew Eddie]

Hi Hannes.

Thanks for the explaination. One logic correction and several observations.

Firstly, the JSON storage is in a wide VARCHAR, not a TEXT field. As
of MySQL 5.0.3 a VARCHAR is allowed to have up to 64k of data. Where
using UTF-8 that give you an effective maximum of around 20k, or
VARCHAR(20480). Note that a row also has a practical maximum of 64k
as well. The advantage of this is that a VARCHAR, when retrieve, is
stored with the rest of the data. A TEXT or BLOB is actually stored
in a separate lookup and so is slightly more inefficient when
retrieving. The one downside to wide VARCHAR's is than while they are
stored very efficiently on disk, when memory is allocated, the maximum
width is used so you do need to be careful using them.

This nullifies your first argument.

Second observation is that storage, reading and writing of XML is way
heavier than JSON and we have been trying to standardise on JSON is
many otherplaces in the code. Or have I misunderstood your point?

Can you please show the example of what the data you are storing looks
like and where it's stored? I got a little confused because at one
point you are saying storage in the database is a bad idea and at
another point you are adding a field. My gut feel is you are arguing
for exactly the same system as I proposed with the only different
being where and in what format the data is stored in (I think).

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/9/5 Hannes Papenberg <hack...@googlemail.com>:

[Hannes Papenberg]

Hello Andrew,
my point about your solution was, that you would need an additional
storage for this JSON string somewhere for something like a file for
example or some other data object that is not in your database. Thats
why I said that you would most likely need to add another table for that
case then. I myself do not want to write to an XML file. I wanted to use
the tables as they are in the database at the moment with the little
addition that I add a field to the asset table to define the parent of
an asset from which it should inherit. In the end this means that the
whole ACL system is encapsulated in the database tables that are modeled
after the phpGACL schema, instead of moving them (partly) into each
content table as your proposal suggests. This has the benefit of
inheritence across tables and its done automatically inside the Joomla
system instead of by the third party developer. The ACL system does not
differentiate between a categorie and an article, even though they are
in different tables in the system itself. As a third party developer you
only have to hand the new rules over to the system, instead of having to
find out which objects would have to be touched to inherit these rules
by yourself.

Hannes

Andrew Eddie schrieb:

[Andrew Eddie]

Ok, I misunderstood.

The scaling of the asset table and the asset-action/asset-rule maps is
what I'm really worried about. If you are going to have a parent for
inheritance, the asset table is the wrong place. It at least needs to
be in the asset_action map because that's where it is directly
related. The asset table should not care about any other object.

The other thing is you don't have to be generic. The rule is always
enforced in the context of something. Why not take advantage of that
simplification.

Whatever the case, I'm not suggesting "my way" is perfect, but I think
the phpgacl way is over engineered and has scaling issues (not in the
phpgacl schema itself, but in the way Joomla has to interact with it).
We also have to think about the poor old bug squad (not to mention
the developer) that is going to try to debug ACL issues. With data
stored in context you may very well loose a little bit of flexibility,
but gosh, it's going to be easier to maintain and debug. This is not
about finding the best academic solution (phpgacl in it's purest form
is already there) - it's about finding the best practical solution.

Remember I've been working with phpgacl for many years now but I have
also written a winnowing system as well (for dotProject) - I probably
know it the best of anyone and was as initially enthusiastic as you
are now. Louis and I built the API you want to use and thought we
were pretty happy with it. However, my Content Manager extensions
uses it and I have no end of trouble with support - sometimes it
works, sometimes it doesn't. I am genuinely concerned that the system
and the corresponding UI needs a big rethink. In this case less
moving parts with a small sacrifice in some functions could be a
better solution.

There are too many points of failure in the phpgacl schema at the
moment and fixing data corruption is a big deal (on the bright side I
could charge people lots of money to fix their corrupt data tables).
phpgacl is perfect if you are controlling your data for your
standalone application. I don't think it's a good fit for Joomla
because we don't have complete control over how people use it. We
need a simpler and robust API.

I also think inheritance is a slippery slope that really needs to be
thought about properly. There are cases when you want it, and cases
where you don't. I still need to think more on inheritance and what
is the line of best fit for that whatever the system is.

[Amy Stephen]

On Sep 4, 6:03 pm, Andrew Eddie <mambob...@gmail.com> wrote:

I also think inheritance is a slippery slope that really needs to be
thought about properly.  There are cases when you want it, and cases
where you don't.  I still need to think more on inheritance and what
is the line of best fit for that whatever the system is.
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

Good point, Andrew.

When security is defined at a "parent" category (node), I would like
to see a checkbox that would be activated to indicate that option
should extend to the lowest level of detail. (Removal of a security
definition should work the same, in reverse.) This is a commonly used
user interface pattern for folder security in operating systems and
should be straight forward for users. The other, perhaps more
important benefit, would be a reduction in complexity of data
retrieval queries. (In other words, you would not have to look
upstream.) That should help third party developers a great deal
because this is getting complex.

Point 2 - I talked to Hannes today about concerns denormalizing data
when populating the tables.

The data model is in 3NF, which is good. It would make sense to
populate the access_actions table with only actions (i.e., Logon,
Install, Configure, View, Create, Update, Delete) and not add a "View"
row for each asset (i.e., com_content.article, core.menu,
core.categories, etc.) Asset definitions are properly stored in the
access_assets table. That's just two of the nine tables. The
denormalization has a mushrooming impact on table size.

Now, if I understood Hannes, correctly, the denormalization is for
performance. I'm puzzled by that though. In all the years of data
warehousing I've done, denormalizing to a single table that is then
used in the select queries does speed things up by reducing table
joins. But, this does not seem to be reducing joins, but rather just
adding more rows to the tables. If that's true, it would actually slow
down the queries. We might want to benchmark some of these ideas?

So, what do you guys think about loading the data in 3NF and seeing
where performance is at. Then, if there are concerns, maybe add a
single denormalized structure (1 table) to speed up those queries?
(Which also begs the question - do you think for most implementations,
performance will be a concern? I guess I'm not sure about that.)

Point 3 - I'm also wondering about all of those tables, Andrew, and
whether it's overkill. There has to be a way to simplify this. There's
users, actions, and assets. Surely 9 tables are not required for that?
Hmmm.

Point 4 - I agree with Hannes that having a nice handful of Use Cases
would be helpful for discussions and prototyping queries. It should
also help others begin to understand what's coming in 1.6. It's easier
for most people to think about those "real life scenarios" rather than
code, and having users verify the ACL will meet their needs is very
helpful. If there is agreement, maybe those interested could suggest
use cases in a new thread?

I'm still looking at it - but those are a few ideas I wanted to
share.

Thanks for encouraging involvement.
Amy :)

[Sam Moffatt]

Hi all,

On Sat, Sep 5, 2009 at 1:58 AM, Hannes
Papenberg<hack...@googlemail.com> wrote:
>
> Hello folks,
> first I have to apologize. As I said in the status update for 1.6, I
> promised to deliver this quite some time ago. But now here is my first
> proof of concept on this one.
>
> What is all this about?
> The topic of this post is the asset management in the ACL of Joomla 1.6.
> Assets are the content objects in Joomla, for example categories,
> articles and weblinks. At this moment, you can only control assets in
> 1.6 in terms of viewing permissions, which are controlled by
> Level3-rules. Other actions, for example editing an article, should be
> controlled by Level2-rules. Andrew proposed one way to handle these in
> 1.6 by saving a JSON array in an extra field for each content object
> with its permissions for the different groups. In my opinion this has
> some flaws, the first being the requirement for a storage object
> equivalent to a MySQL text column to handle permissions for an object.
> If we are talking about files or other data objects that we want to
> control which are not necessarily stored in the database, this makes it
> more complicated, since we need a seperate datastorage for the access
> informations.

If I look at existing systems that handle non-database objects (e.g.
files) they all have tables with additional metadata information
anyway or even for efficiency (e.g. building an FS tree via SQL would
be much easier than PHP opendir'ing for example). I commented to this
effect on an earlier thread, I am yet to see a strong example where
your database would be dearth of rows to link to files and in your
case you need to create an asset entry anyway so you're actually doing
the same thing in different techniques (instead of adding a row to
your own table you add it to a core table).

> For the user, its pretty basic to use. If you edit an object, you have
> an additional radio button, which enables if you want to inherit the
> rules from the objects parents or if you want to create seperate rules
> for this asset. If you inherit, thats all you have to do. If you don't,
> you get a list of groups, which, upon clicking on one group, shows a
> list of actions with checkboxes besides them. You select what you want
> and thats it. Click save when you are done with editing that object and
> all your rules are saved.

What if I want to both inherit permissions but override some
permissions locally? This is a very common operation in file systems
and I don't see it changing for Joomla!. A good example might be a
category that contains peoples biographies or contact details so we
might wish to delegate updates to that to either the owner or perhaps
their secretary however we might wish to inherit the rest of the
permissions from the category so that the majority of the permissions
can be controlled in a general sense whilst still giving the
flexibility of specificity. Copying the permissions from the parent at
the point of creation isn't efficient or wanted in this case, you
actually want mutable permissions.

On Sat, Sep 5, 2009 at 7:56 AM, Andrew Eddie<mamb...@gmail.com> wrote:
> Firstly, the JSON storage is in a wide VARCHAR, not a TEXT field.  As
> of MySQL 5.0.3 a VARCHAR is allowed to have up to 64k of data.  Where
> using UTF-8 that give you an effective maximum of around 20k, or
> VARCHAR(20480).  Note that a row also has a practical maximum of 64k
> as well.  The advantage of this is that a VARCHAR, when retrieve, is
> stored with the rest of the data.  A TEXT or BLOB is actually stored
> in a separate lookup and so is slightly more inefficient when
> retrieving.  The one downside to wide VARCHAR's is than while they are
> stored very efficiently on disk, when memory is allocated, the maximum
> width is used so you do need to be careful using them.

Curious question, what if someone has a lot of permissions, is there a
risk of data corruption due to truncation? Should we perhaps put
checks in to ensure that we don't run into a situation where data is
lost in the system, potentially corrupting the field and causing
deserialisation to fail? Practically I don't think that it will happen
for a majority of cases however as you suggest we can't control all
uses. As an aside, most of these tables already have TEXT fields
anyway, what is the performance hit for loading multiple text fields
for a row? What impact is there on potential caching as well, do
text's get cached better than varchars (especially if a varchar is
using the full size in memory where as a text only uses the portion
required with some structure overhead i'm sure).

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

Sam -

I guess I am thinking about the inherit and override more simply.

When security on a folder is changed in an operating system, that
change can be replicated to subordinate objects, if the user so
elects. But, it's just a one-time deal that can immediately be
overridden when a subfolder or file has different requirements (i.e.,
your secretary example). To me, the system should not try to keep that
choice in affect from that point on. (Maybe I didn't understand you,
though?)

The other somewhat related question relates to defaults for new
objects which I assume would initially be set to parent values and
could be manually changed by the user?

I can see where Andrew's idea on the JSON field might be good for
performance (even storing group primary keys in a list for quick use
in an IN statement might be good.). I wish I had a feel for expected
query speed to know whether or not that complexity would be
worthwhile. The joins are straight forward. The denormalized list
(stored as JSON, XML, or a SQL list) adds complication. It would be
good to test ideas like that with prototyping, though.

Amy

[Andrew Eddie]

@Amy

phpgacl is already in third normal form, totally agree. I have tried
to make it work in 3NF and there are consequences. The reasons are
not for performance but practicality and we are ONLY talking about
type 2 rules which in Joomla's case have specific context therefore
you can eliminate some of the variables and make some compromises.

@Sam

Data truncation is a possible concern. There should be a check but I
would wager that the UI would clap out or be unmanageable before you
reached the practical limit. That's no excuse for not keeping this
in mind. There are some cheats in that we could encode that one field
in a latin charset to coax a little more space out of it. We can also
simplify further by not have the exclusions. We'd need to do some
testing.

I would be prepared to look at a third hybrid solution and that would
be to more or less keep the asset table but merge it with the
permissions, for example:

content | context_id | action | permissions | inherit (??)

That's still manageable in terms of teaching dev's what the
relationships are and giving them a chance to debug sticky situations.
99% of the time, all but allow_groups will contain '{}'. The lookup
is not onerous and inheritance is handled in by ordering (the calling
component has to be responsible for that though) through merging
arrays.

The query is relatively simple. If you are in a category, it's

SELECT action, permissions, inherit
FROM #__action_permissions
WHERE context = 'com_catalog' AND context_id = 42

Where 'permissions' is a JSON object (1000 individual id's might be
6kb). The result set can be shoved a helper object. It's possible
and would provide a great factor of safety against data truncation
(which could come into play if you had like 10 or 20 individual
actions - is that sane, I dunno, but it could happen).

We don't need to store actions in a table, that's done in the JForm XML.

The great thing about the JSON format is that you pull back one row
and you have all the information you need about the ACL. Remember!
These ACL's need to be check *every* time because public users have a
chance to do things as well. We don't have the luxury of assuming if
$userId == 0 ignore access checks. This is why it's so important to
make sure this system is as efficient as possible without compromising
too much power.

And the beauty is that you could possibly use both types. At the
article level, I think a single JSON actions field would do admirably
(if you are setting thousands of people individually you need more
user groups). For categories, or objects needing a lot of actions to
control, you could use the hybrid mapping table.

To be honestly, I think it's really a case of "suck it and see". It
may not work, but then again, it might cover more than enough bases
for the next few versions. The is enough information stored that if
we even did have to go back to phpgacl-style, the tables are drop-dead
easy to build.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/5 Amy Stephen <amyst...@gmail.com>:

[Sam Moffatt]

On Sat, Sep 5, 2009 at 12:03 PM, Amy Stephen<amyst...@gmail.com> wrote:
>
> Sam -
>
> I guess I am thinking about the inherit and override more simply.
>
> When security on a folder is changed in an operating system, that
> change can be replicated to subordinate objects, if the user so
> elects. But, it's just a one-time deal that can immediately be
> overridden when a subfolder or file has different requirements (i.e.,
> your secretary example). To me, the system should not try to keep that
> choice in affect from that point on. (Maybe I didn't understand you,
> though?)

The thing is that in Windows security model derived operating systems
the permissions are almost always inherited. In Windows, the child
object doesn't say "hey, I'll take your perms" but the parent object
is what determines the inheritance. A container object has one of
either options for controlling inheritance (one of which is no
inheritance) for a given permission that is set. This way when you set
a new permission on the container object it gets replicated onto the
child object even if the child object has permissions of its own. The
issue I have is that permissions are rarely one time, they change.
Requirements change and the parent (or grandparent) object's
permissions might change. In this situation that doesn't grant them
permission to edit the items as you would expect because the
permissions aren't inherited so that the secretary can edit it. The
risk of oversimplifying inheritance in the model proposed is that it
doesn't make sense to people because someone will set a permission on
a category and then will get a complaint that someone can't edit
something because we don't have a full DACL model and that particular
item isn't inherited. All I'm after is the realisation that
inheritance or nothing creates problems down the line, especially
since it will behave differently to the ACL model that almost everyone
has sitting on their desk*.

Sam Moffatt
http://pasamio.id.au

* The Windows model is also used in NFSv4 ACL's, Mac OS X and ZFS.
POSIX ACL's are similar but have a few quirks of their own (Mac OS X
implements a variant again of POSIX). Novell's model is similar again
but I don't think many people are still using Novell anyway.

[Amy Stephen]

To make certain we are talking about the same

Your example:

someone will set a permission on a category and then will get a complaint that someone can't edit something because we don't have a full DACL model and that particular item isn't inherited.

Example - Category/Content Structure

University
  \-- College of Arts and Sciences
        \--English Department
             \-- Secretary
                   \-- Article 1
                   \-- Article 2

Is this what you are saying? The English Department Chair changes the permissions for the English Department by removing all existing Groups, and then adding a Group the Secretary is NOT in, each time, replicating the changes down.

In that case, it is true, the Secretary would not be able to update the Secretary Category or Articles.

I guess if that's what you are saying, I don't see it as a system issue. Maybe the Department Chair wanted to lock the Secretary out.   (If not, would you please give an example? Thanks!)

+++++

BTW - I think we need to add a parameter that allows the Site Admin to enable update access to content created by the user. That would also help with the problem I think you are wondering about.

[Amy Stephen]

I spent time looking at the Interface and tables and have recommendations for simplifying the data model that I think has promise.

Briefly, I recommend these changes and explain these points in detail, below:
- Use Groups and Actions to implement what used to be accomplished using Legacy Group and Level. (And do not use Legacy Group and Level data elements, anymore.)
- Normalize data for Actions and Assets.
- Simplify the ACL tables to these five: Groups, Group Members, Actions, Assets, and Rules.
- Use the “User – Action – Asset” structure for *all* permissions. (In other words, don't use the Rule Types 1, 2, and 3).
- Default the ACLso it is *exactly* like 1.5 so those who do not need more do not have to fuss with this.

With the data model clarified in those ways, the queries are simple and similar and easy for developers to use. I don't see performance issues, personally, but am curious for feedback.

++++++++++

Cleanup Legacy Groups and Levels

The legacy data elements: Group and Level, should not be used in current form. Instead, their function will be merged into the new ACL “User – Action – Asset” structure.

1.       Legacy Group

a.       Public and Registered become new “foundation” Groups

b.      Author, Editor, Publisher will be used as Actions

c.       Manager, Administrator, Super Admin will be default Groups with Registered as a Parent

 

2.       Legacy Level

a.       Public and Registered are now “foundation” Groups (see above).

b.      Special is replaced by Action (Login) and Asset (Administrator).

c.       Confidential is not needed. Just give access to self and no one else.

d.      Along with it, remove the “Default Access Level “in the Site-Site Settings-Global Configuration Utility

 

3.       Move out of Global Configuration

a.       Into User Manager Options:

                                                               i.      Global Configuration – Site – Site Settings

1.       Default Editor

2.       New User Account Activation

3.       Front-end User Parameters

b.      Remove from Application completely

                                                               i.      Global Configuration – Site – Site Settings

1.       Default Access Level (Do not replace - access levels go away)

c.       Move Into User Manager: Groups

                                                               i.      Global Configuration – System –User Settings

1.       Allow User Registration (Default Action for Public Group)

2.       New User Registration Type (Default Action for Registered Group)

User – Action – Asset

Everything should follow this simple pattern: User – Action – Asset. There is no reason to complicate with Rule Type 1, 2, and 3. Keep it simple - everything can be nicely defined with those three elements:

·         User – describes who, could be a single User and it could be a Group of Users

 

·         Action –describes what can be done, keep it a clean, normalized list of actions

o   Login

o   View

o   Create

o   Activate

o   Update

o   Publish (Includes archive, delete) (for users, includes activate, enable)

o   Install

o   Manage (Configure)

o   Uninstall (Isn’t Install enough?)

o   Third-party developers

§  Can add Actions – must be uniquely named

§  Cannot remove core actions – API should not allow

§  Can use core actions – and they should follow the pattern!

 

·         Asset – Defines “what” can be acted on by whom (Note: List of appropriate Actions are shown with Assets, below, to demonstrate a normalized list can be used to achieve specifity needed.)

 

o   Frontend

§  Action: Login

o   Administrator

§  Action:  Login

§  Note: This is why the “Special” level is no longer needed.

o   Each Content Components

§  User Interface: display as Tree top is “All Content”, then each Content Components and the set of Categories for that Component, if appropriate

§  Assets: Administrator User, Administrator Contact, Banners, Content, Frontend Contact, Frontend User, Groups, Mass Mail, Media, Menus, Newsfeeds, Redirect, Front Users, Web links (Note: No reason to separate out Categories. Category access goes with the associated Content Components.)

§  Actions: View, Create, Activate (User only), Update, Publish action

§  Note: Any level, including “All Content”, and each of the Content Components, can be selected as the Asset. Of course, so can the Content Categories and Items.

o   Each System Item

§  Assets: Administrator Languages, Administrator Modules, Administrator Templates, Cache, Check-in, Global Configuration, Site Languages, Site Modules, Site Templates, Plugins, System Information

§  Actions: Install, Manage (Configure), Uninstall

User Manager Options

As mentioned above, the following three options should be moved into User Manager Options from the Global Configuration – Site – Site Settings.

·         Default Editor

·         New User Account Activation

·         Front-end User Parameters

Default Groups

Goal: Defaults upon install should begin with ACL settings that *exactly* match what 1.5 does. The User should not have to do anything if they want the same ACL as they always had. (Of course, technically, the way it’s done will be different and the language used to describe data elements will change, but, the Use Case remains the same.)

Legacy Groups Public, Registered, Manager, Administrator, Super Administrator will be defined Groups. The old Legacy Groups: Author, Editor, and Publisher are now Actions.

Levels go away completely. Remove Menu Item and Level Option in User Manager. Public and Registered are Groups. Special is determined when a User has Action Login for Asset Administrator. Confidential is not needed. If access is not defined for content , then it will be confidential.

Here are default groups:

1.       Public 

a.       Replaces Legacy Group Public *and* Level Public. This is a special system group that represents a visitor who is not logged on. No Groups should be added as subordinates to Public. Public cannot be removed.

b.      Upon install, these are the defaults for Public:

·   Public – View – All Content

·   Public – Create – Frontend User (Replaces Global Configuration New User Account Activation)

·   Public – Create –Frontend Contact (Form Submission)

c.       Public and Registered are mutually exclusive - visitor may not be both at the same time.

 

2.       Registered

a.       Replaces Level Registered. Special system group that all members belong to. Groups must be added as subordinates to the Registered Group. Registered cannot be removed.

b.      Defaults at install:

§  Registered – Activate – User

§  Registered – Login – Frontend

§  Registered -  Publisher – All Content  (replaces Global Configuration User Registration Type)

3.       Manager

a.       Replaces Legacy Group Registered.

b.      Should not be deleted; can disable ???

c.       Defaults at install (user in Manager Group automatically gets Registered):

§  Manager – Login – Frontend

§  Manager – Login – Backend

§  Manager – Publish – Administrator Contact

§  Manager – Publish – Banners

§  Manager – Publish – Content

§  Manager – Publish – Newsfeed

§  Manager – Publish – Media

§  Manager – Publish – Web links

§  Manager – Publish – Newsfeeds

 

4.       Administrator

a.       Replaces Legacy Group Administrator.

b.      Should not be deleted; can disable ???

c.       Defaults at install (user in Manager Group automatically gets Registered):

§  Administrator – Login – Frontend

§  Administrator – Login – Backend

§  Administrator – Publish – All

§  Administrator – Manage –Administrator Languages

§  Administrator – Manage –Administrator Modules

§  Administrator – Manage –Site Languages

§  Administrator – Manage –Site Modules

§  Administrator – Manage –Site Plugins

§  Administrator – Manage –System Information

 

5.       Super Administrator

a.       Replaces Legacy Group Super Administrator.

b.      Cannot delete or disable.

c.       Defaults at install:

§  Administrator – Login – Frontend

§  Administrator – Login – Backend

§  Administrator – Publish – All

§  Administrator – Manage –All

Groups (User Defined)

Groups can be defined for the purpose of assigning User-Action- Asset ACL Rules and then adding Users to the Groups.

Note: Given the Default Registered Setting, All Registered Users have View – All Content. That would have to be turned OFF before User Groups could restrict access. It would be good if the creation of a Group checked to see if Registered had the default on – and then prompted the user to disable it, if necessary.

Question: Should User Defined Groups inherit the authority of Children Groups? I suggest not to do that. Too many node based structures gets confusing.

Very simple process:

·         User – Group (users are member assigned to the group)

·         Action – from list, above

·         Asset – from list, above

User

The User Manager must enable the selection of one, or many, groups for each User.

Data Model

 

/*==============================================================*/

/* Table : actions                                              */

/*==============================================================*/

create table if not exists actions

(

   id                             int(11)                        not null AUTO_INCREMENT,

   "action"                       varchar(255)                   not null,

   can_delete                     int

)

ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=31;

 

/*==============================================================*/

/* Table : assets                                               */

/*==============================================================*/

create table if not exists assets

(

   id                             int(11)                        not null AUTO_INCREMENT,

   asset                          varchar(255)                   not null,

   can_delete                     int,

   category_id                    int(11),

   content_id                     int(11)

)

ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=31;

 

 

/*==============================================================*/

/* Table : groups                                               */

/*==============================================================*/

create table if not exists groups

(

   id                             int(11)                        not null AUTO_INCREMENT,

   parent_id                      int(11)                        not null default 0,

   name                           varchar(255)                   not null,

   can_delete                     int

)

ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=31;

 

/*==============================================================*/

/* Table : rules                                                */

/*==============================================================*/

create table if not exists rules

(

   group_id                       int(11)                        not null default 0,

   action_id                      int(11)                        not null default 0,

   asset_id                       int(11)                        not null default 0,

   category_id                    int(11),

   content_id                     int(11)

)

ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=31;

 

/*==============================================================*/

/* Table : group_members                                        */

/*==============================================================*/

create table if not exists group_members

(

   group_id                       int(11)                        not null AUTO_INCREMENT,

   user_id                        int(11)                        not null default 0

)

ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=31;

 

 

Use Case PSEUDO code SQL

USER – ACTION – ASSET

 

Install an Extension

Formerly, this was Rule Type 1. But, it’s implemented the same - USER  – ACTION - ASSET

SELECT c.user_id

FROM jos_users a,

rules b,

group_members c

WHERE the user is enabled, not blocked, etc.

AND b.group_id = c.group_id

AND c.user_id = THE USERID LOGGED

AND b.action_id = INSTALL ACTION

AND a.id = b.content_id

 

Retrieve Content

Formerly, this was Rule Type 2. But, it’s implemented the same - USER – ACTION - ASSET

SELECT a.content, a.fields

FROM jos_content a,

rules b,

group_members c

WHERE the content is published and not checked out, etc.

AND b.group_id = c.group_id

AND c.user_id = THE USERID LOGGED

AND b.action_id =CONTENT

AND a.id = b.content_id

 

Public Viewing

SELECT c.user_id

FROM jos_users a,

rules b,

group_members c

WHERE the user is enabled, not blocked, etc.

AND b.group_id = c.group_id

AND c.user_id = THE USERID LOGGED

AND b.action_id =FRONTEND LOGIN

AND a.id = b.content_id

 

Note: The Public user id of 0 must be defined in the users table – and in the group_members.for public group. It will work just like a regular user.

 

[Amy Stephen]

I attached the Word Document http://groups.google.com/group/joomla-dev-cms/web/ACL.docx
in case that's easier to read.

[Hannes Papenberg]

Hello again, :-)
my main goal behind my proposal was, that it is dead easy to use for
developers. Yes, it is a pretty complicated system, both in terms of
tables and of code, but for the developer to get ACL implemented into
his component including an inheritence system, is absolutely easy. He
only has to set one variable inside the class to enable the ACL system
and in my proposal you need 4 functions that tell you the name of the
component, the name of the asset, a prefix and the parent of that asset.
In your component itself you include an additional field in your form
and you need to create one XML file. (If you are experienced) this is
done in 5 minutes.

You don't have to think about how the permissions are stored in your own
tables, you don't have to think about how the rules are translated into
the JSON object and it does the basic logic of inheritence for you. This
comes with the price of a lot more complexity and more danger for the
data integrity.

I'm a big fan of making it easy for the third party developer since I've
recently had to work with some of the bigger third party applications
for Joomla, among them Virtuemart, which allows having a tree of
categories, but does not use a nested sets model, creating a whole heap
of problems for me. If they would have it easier and could just use a
class like its included in 1.6 that does all this already for them, the
overall quality of third party extensions are more likely to be raised.

Inheritence is very important for me, but I see that my proposal has
problems both in this area and in data integrity. Maybe we could do
something along the lines that Andrew proposed. We use the JSON model,
but don't store it in the content objects table, but have a seperate
asset table for them. In that table we have two varchar fields, one for
the asset specific access rights and one for the access rights inherited
from its parent. My goal is, that all inheritence is handled upon saving
and not when you are looking stuff up. To get the whole tree, we make
this a nested sets table, too. Inheritence would be handled the way that
during saving we get the parent object of the current item, get both the
array from the "inherited"-field and from the "own_access"-field, merge
them and then XOR them with the specific rules for the current item. The
resulting rest of the parent array is stored in the "inherited"-field
and the specific rules of the current item are stored in the
"own_access"-field. Now we have to go up the rest of the tree and do
this action for all other items up the tree to inherit the changes lower
down.

Now that we practically made the connecting tables between assets and
rules and between assets and assetgroups obsolete, and since we are
changing this system even more, this has some implications for me. I
would boldly ask: What do we need the rules table for?
We still have three types of rules:
Type 1: Direct connections between usergroups and actions -> One mapping
table between those two would be enough. That mapping table would just
have to have a switch for "allow" and "deny".
Type 2: See described above.
Type 3: Direct connection between usergroups and assetgroups -> A
mapping table like for Type 1 rules would be enough, too.
If we restrict the system a bit and only allow to set access rights for
usergroups, we can save 5 tables. (jos_access_asset_assetgroup_map,
jos_access_asset_rule_map, jos_access_rules, jos_usergroups_rule_map,
jos_user_rule_map, the other mapping tables prefixed with jos_access_*
would map directly to usergroups)

How does that sound?

Hannes

Amy Stephen schrieb:

> To make certain we are talking about the same
>
> Your example:
>
> someone will set a permission on a category and then will get a
> complaint that someone can't edit something because we don't have
> a full DACL model and that particular item isn't inherited.
>
>
>
> Example - Category/Content Structure
>
> University
> \-- College of Arts and Sciences
> \--English Department
> \-- Secretary
> \-- Article 1
> \-- Article 2
>
> Is this what you are saying? The English Department Chair changes the

> permissions for the _English Department_ by removing all existing

[Sam Moffatt]

I think we're not quite on the same track.

On Sat, Sep 5, 2009 at 7:39 PM, Amy Stephen<amyst...@gmail.com> wrote:
> Example - Category/Content Structure
>
> University
>   \-- College of Arts and Sciences
>         \--English Department

> \-- Staff Bios
>                    \-- Article 1 - Bio Dean of Department
>                    \-- Article 2 - Bio Lecturer
Slightly modified your diagram.

So in this model the bio's are maintained by the respective biography
owners. Easy enough to model with an owner edit ability applied
somewhere nice and high. The Dean of the Department is important
though that they should be able to edit their own but sometimes
they're busy and like the secretary to update it. They like editing
their own to put in superfluous stuff and our kindly secretary helps
resolve that as well. Since we only want the secretary in this case to
edit article 1 not article 2 we can't set it at a higher level and
have it inherit, we need to set it specifically for article 1 which
means we then can't inherit permissions.

Later on the College of Arts and Sciences appoints a web master to
maintain their sprawling web page collective. They give this person
the privilege to edit any article at the College level as one of their
new roles will be to periodically check pages and fix typos/grammar
issues. They one day go to edit the Dean's bio because they notice a
typo in it but can't because before their appointment the secretary
was granted access, the item stopped inheriting and therefore their
later permission grant is inaccessible for the given item.

One might suggest that the problem raised above is easily worked
around by providing an "apply to children" operation that takes this
new permission for the web master and applies it to all child items
that aren't set to inherit but the problem then arises of how you
revoke this permission? You can't necessarily do that because before
that they might have been granted access to an item that you unset
that should still remain because that permissions is still valid.
However you can't easily leave it there because the person then has
more privileges on disparate items than they should.

My belief is that in the majority of cases you actually want
permissions to inherit all of the time if you're going to have
inheritance. We should follow in the footsteps of a system that has
proven itself reasonably well (Windows) and offer at least a similar
behaviour instead of defining a unique behaviour. This doesn't mean we
implement every little feature it has (I have four pages of summarised
text on it if anyone is actually interested) however I'd certainly
replicate the concepts. Your average system administrator understands
it, most power users have a grasp of it and there is a reasonable
amount of documentation we can borrow as well.

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

Great, thank you, Sam.

Day 1:

University
\-- College of Arts and Sciences
\--English Department
\-- Staff Bios

\-- Article 1 - Bio Dean of Department - Only
Permissions are Secretary - Publisher

\-- Article 2 - Bio Lecturer

Day 2:
Dude gets job. Is assigned responsibility for oversight of all content
in the College of Arts and Sciences.

Group "CollegeWeb" created.
-- Joomla! adds a row to the Group table.

User "CollegeWebMaster" added to Group.
-- Joomla! adds a row to the Group Members table.

ACL Rule Created: Group "CollegeWeb" assigned "Publisher" Action to
Asset "Content-College of Arts and Sciences." and the User clicks the
checkbox "Apply to Childern"
-- Joomla! adds five rows in the rules table:
1. Group: CollegeWeb; Action: Publisher, Asset: Article, College of
Arts and Sciences Category
2. Group: CollegeWeb; Action: Publisher, Asset: Article, English
Department Category
3. Group: CollegeWeb; Action: Publisher, Asset: Article, Staff Bios
Category
4. Group: CollegeWeb; Action: Publisher, Asset: Article, Staff Bios
Category, Bio Dean of Department Content Item
5. Group: CollegeWeb; Action: Publisher, Asset: Article, Staff Bios
Category, Bio Lecturer

Sam - at this point, the concept of inheritance is *done* for this
transaction - it's a one-time batch operation.

Resulting ACL:

University
\-- College of Arts and Sciences - CollegeWeb - Publisher
\--English Department - CollegeWeb - Publisher
\-- Staff Bios - CollegeWeb - Publisher
\-- Article 1 - Bio Dean of Department - Secretary
AND CollegeWeb - Publisher
\-- Article 2 - Bio Lecturer - CollegeWeb -
Publisher

Day 3:
Dude goes to lunch with visiting faculty member. He comments on the
crappy job the secretary has done maintaining the Dean's bio. How was
he to know he was talking to the Dean's daughter? Apparently, she took
her husband's sir name in marriage! On top of that unfortunate
blunder, nepotism runs ramped in the department. The secretary is her
brother, the son of the Dean! Dude given a stay of execution and
allowed to continue managing content for the College, with the
exception of the Dean's Bio, a role once again reserved for the
secretary.

ACL Rule Deleted:
4. Group: CollegeWeb; Action: Publisher, Asset: Article, Staff Bios
Category, Bio Dean of Department Content Item


Resulting ACL:

University
\-- College of Arts and Sciences - CollegeWeb - Publisher
\--English Department - CollegeWeb - Publisher
\-- Staff Bios - CollegeWeb - Publisher
\-- Article 1 - Bio Dean of Department -
Secretary
\-- Article 2 - Bio Lecturer - CollegeWeb -
Publisher

Agree with your point that enhanced ACL will complicate life. Going
out the door in 1.6, the simpler, the better, in my thinking. For me,
that means "Apply to children" is a one time deal and Joomla! adds a
Rule for each item. If there are exceptions, then those rules can be
located, and then deleted.

"Apply to Children" is simply a time-saver, in my thinking. It's used
when there are no exceptions, or fewer exceptions then there are
correct assignments.

In the example above, absent "Apply to Children", 5 rules would have
to be manually created. Folks ain't going to like that. ;-)

Thanks for the excellent description.
Amy

[Amy Stephen]

Hannes -

I'm going to try to apply the data simplification concepts I described
to your patch. It should not complicate things for the developer. It
really should make queries faster and certainly the concepts will be
MUCH easier for folks to understand.

Wish me luck! ;-)
Amy

[Amy Stephen]

OK, the installation fails at the DB step with the SQL change in place (likely sample data.)

Thenn, the Category Edit for Content fails with this error:

Parse error: parse error in E:\Web\joomla1.6\libraries\joomla\form\fields\accessrules.php on line 81

Is your patch more for visual inspection right now? Rather than use to see how the Category ACL rule assignment works?

Thanks!
Amy

[Hannes Papenberg]

It worked on my end... I'll check that again later and report back.

Hannes

Amy Stephen schrieb:

> OK, the installation fails at the DB step with the SQL change in place
> (likely sample data.)
>
> Thenn, the Category Edit for Content fails with this error:
>
> Parse error: parse error in
> E:\Web\joomla1.6\libraries\joomla\form\fields\accessrules.php on

> line /81/

[elin]

Dead easy for users is the most important thing.

What do users need to do?
What are their expectations of how things will act?
Where will they go wrong and how do we make that less likely?

Deal with those in the core.

If it's easy for third party developers that's a good thing, but that
will happen from building clean, logical and well documented code that
shows them how to address the same questions about users that the
core components do.


Elin

On Sep 5, 11:17 am, Amy Stephen <amystep...@gmail.com> wrote:
> OK, the installation fails at the DB step with the SQL change in place
> (likely sample data.)
>
> Thenn, the Category Edit for Content fails with this error:
>
> Parse error: parse error in

> E:\Web\joomla1.6\libraries\joomla\form\fields\accessrules.php on line *81*

[Andrew Eddie]

I think the place to start here is to define actually what the problem
is, and then look to the appropriate solution. Start with what the
system needs to provide and then work down from there. Otherwise we
are going to be arguing with out microscopic view of everything.

So let's refine Amy's example so that we know what the boundaries are
before we start talking code.

One thing that has been missed so far is the fact that categories span
data types. So in the example we need to use at least two object
types. I suggest we consider articles, web links and contacts. For
now, forget about how the API works (we'll get to that), just define
the problem and what the user needs to "see" in the UI.

Could I suggest though that the example uses a country|state|town type
of tree because that's sort of what was started in the 1.6 sample
data. Let's then throw that as a page in the group so everyone can
refer to it and ultimately it's the point of truth for the bug squad
to fix issues or reject wishes.

Sound like a plan?

Then when we get to the API we need to pull apart how it looks with
examples (Hannes, you can't just say "it works" and "it's easy").

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/5 Amy Stephen <amyst...@gmail.com>:

[Sam Moffatt]

Hi Amy,

A quick aside to something that occurred to me is that we're doing the
inheritance model backwards. You don't choose your parents, you are a
descendent of them and typically inherit their attributes. You might
override these but at the base you inherit by default.

On Sat, Sep 5, 2009 at 11:48 PM, Amy Stephen<amyst...@gmail.com> wrote:
>
> Great, thank you, Sam.
>
> Day 1:
>
> University
>   \-- College of Arts and Sciences
>         \--English Department

>             \-- Staff Bios - Owner Edit

>                    \-- Article 1 - Bio Dean of Department

> Permissions are Secretary - Publisher, Owner Edit

>                    \-- Article 2 - Bio Lecturer

The inherited permission is still there for the dean (the owner) to be
able to edit as well as the secretary.

>
>
> Day 2:
> Dude gets job. Is assigned responsibility for oversight of all content
> in the College of Arts and Sciences.
>
> Group "CollegeWeb" created.
> -- Joomla! adds a row to the Group table.
>
> User "CollegeWebMaster" added to Group.
> -- Joomla! adds a row to the Group Members table.
>
> ACL Rule Created: Group "CollegeWeb" assigned "Publisher" Action to
> Asset "Content-College of Arts and Sciences." and the User clicks the
> checkbox "Apply to Childern"
> -- Joomla! adds five rows in the rules table:
> 1. Group: CollegeWeb; Action: Publisher, Asset: Article, College of
> Arts and Sciences Category
> 2. Group: CollegeWeb; Action: Publisher, Asset: Article, English
> Department Category
> 3. Group: CollegeWeb; Action: Publisher, Asset: Article, Staff Bios
> Category
> 4. Group: CollegeWeb; Action: Publisher, Asset: Article, Staff Bios
> Category, Bio Dean of Department Content Item
> 5. Group: CollegeWeb; Action: Publisher, Asset: Article, Staff Bios
> Category, Bio Lecturer
>
> Sam - at this point, the concept of inheritance is *done* for this
> transaction - it's a one-time batch operation.

That isn't inheritance though, it is just copying permissions to
children. You have no way of easily distinguishing the inherited
permission from one that might be set manually and unless you link the
permission back to the originating permission so that you can easily
revert the effects of that permission. However if you are going to
have a row for each inherited permission that is going to cause a
large explosion in rows. One permission at the root of the tree is
potentially going to add rows all over the place because you have to
add entries to those things that aren't set to implicit inherit (not
to mention finding them) in both categories and their child articles.

Again I don't feel this is how you would expect it to work and isn't
how it works for what most people use daily. You set a permission at
the top of the tree and it gets merged in at the bottom somehow. You
remove said permission and it disappears.

> Agree with your point that enhanced ACL will complicate life. Going
> out the door in 1.6, the simpler, the better, in my thinking. For me,
> that means "Apply to children" is a one time deal and Joomla! adds a
> Rule for each item. If there are exceptions, then those rules can be
> located, and then deleted.
>
> "Apply to Children" is simply a time-saver, in my thinking. It's used
> when there are no exceptions, or fewer exceptions then there are
> correct assignments.
>
> In the example above, absent "Apply to Children", 5 rules would have
> to be manually created. Folks ain't going to like that. ;-)

But you fail to address the issue of 'unapplying' the permission. To
revert a particular permission people aren't going to like going to n
many items to manually unapply in a way that doesn't nuke the
non-related permissions unless you record somewhere that a given
permission that you're effectively copying is from somewhere else.
What you actually are doing is copying the permission, not inheriting
it, for those items that aren't inheriting just because they want to
set one permission (in this case, granting one person extra the
ability to edit an item).

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

On Sep 5, 6:01 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> I think the place to start here is to define actually what the problem
> is, and then look to the appropriate solution.  Start with what the
> system needs to provide and then work down from there.  Otherwise we
> are going to be arguing with out microscopic view of everything.

Yup, exactly, this is simply an opportunity for fine tuning and a
chance to simplify. I think the plans are pretty solid under foot
already, so "problem" is might be a strong word. But, yes, let's get
laser focused on these improvements and not get pulled off into little
details.

>
> So let's refine Amy's example so that we know what the boundaries are
> before we start talking code.

Great, thank-you, thank-you! I appreciate that!

Today, I have continued working through data model tweaking and
sketching out/proofing a set of use cases. I ended up adding back in
one of the table that defines which actions are possible by asset.
(Use cases are very good for finding holes in thinking. :-P )

I was planning next to present mock-ups using presentation software,
like Powerpoint. I punted on the code concept realizing how much that
would slow me down and very possibly end up being a waste of time if
this idea doesn't pan out. So, I believe we are on the same track.

My next plan - develop a set of mockups to cast these ideas onto the
Interface. I'll pull together screen shots with changes visually
identified. I'll explain how the User would interacts with the
Interface, and how the Interface should respond. As you say, this can
be generalized (ex. .some components will be treated the same, I'll
describe one, and list the other components that should be treated the
same way.)

From this "powerpoint presentation", we should have a list of all
actions needed and a clear understanding of process and data. I hope
that should be easy enough to talk thru as a group, I think. After we
discuss and make adjustments, running use cases from people who have
been waiting for ACL would be a good sanity check.

I am hopeful that such a process should help someone of Hannes's
coding ability to make adjustments pretty easily, and hopefully not
waste too much of his time going back and forth with code change.

Sound good?

>
> One thing that has been missed so far is the fact that categories span
> data types.  So in the example we need to use at least two object
> types.  I suggest we consider articles, web links and contacts.  

Well, I didn't speak too it clearly, but I'm recommending categories
not be an object on their own, but rather be treated in exactly the
same way, same rules, as the associated content. Not to worry if that
makes no sense, it will be visible in the prototype.

For
> now, forget about how the API works (we'll get to that), just define
> the problem and what the user needs to "see" in the UI.

++++

>
> Could I suggest though that the example uses a country|state|town type
> of tree because that's sort of what was started in the 1.6 sample
> data.  Let's then throw that as a page in the group so everyone can
> refer to it and ultimately it's the point of truth for the bug squad
> to fix issues or reject wishes.
>
> Sound like a plan?

Agree. Yes! Andrew - thank you.

Amy :)

[Amy Stephen]

On Sep 5, 6:03 pm, Sam Moffatt <pasa...@gmail.com> wrote:
> Hi Amy,
>
> A quick aside to something that occurred to me is that we're doing the
> inheritance model backwards. You don't choose your parents, you are a
> descendent of them and typically inherit their attributes. You might
> override these but at the base you inherit by default.

Understand the illustration. Below, you distinguish between "copying
permission to children" and "inheritance." And, that distinction
wasn't something I was articulating before, but it is, as you are
pointing out, an important distinction.

When we have the prototype I described to Andrew, we will, of course,
talk about every single User Action and how the application responds
to it. So, those examples will help us make certain your concerns are
addressed (or clarify where those are not addressed.)

Overall, I think the distinction will be like this:

1. Adding a rule (potentially) involves "copying permission to
children."
2. Removing a rule (potentially) involves "removing permission from
children." (Let's see that in motion and see what you think.)
3, Creating new content calls into play"inheritance" -- which will
come from the container object.

Now, let's get something visual in front of us and see. That's the
first test.

>
> On Sat, Sep 5, 2009 at 11:48 PM, Amy Stephen<amystep...@gmail.com> wrote:
>
> > Great, thank you, Sam.
>
> > Day 1:
>
> > University
> >   \-- College of Arts and Sciences
> >         \--English Department
> >             \-- Staff Bios - Owner Edit
> >                    \-- Article 1 - Bio Dean of Department
> > Permissions are Secretary - Publisher, Owner Edit
> >                    \-- Article 2 - Bio Lecturer
>
> The inherited permission is still there for the dean (the owner) to be
> able to edit as well as the secretary.

Yes. Interesting nuance. We'll prototype this. I'll explain how I see
it with the prototype. Then, let's see what flexibility we might have
or if that's the plan moving forward. So - good example to portray.

>
> > Sam - at this point, the concept of inheritance is *done* for this
> > transaction - it's a one-time batch operation.
>
> That isn't inheritance though, it is just copying permissions to
> children. You have no way of easily distinguishing the inherited
> permission from one that might be set manually and unless you link the
> permission back to the originating permission so that you can easily
> revert the effects of that permission.

> However if you are going to
> have a row for each inherited permission that is going to cause a
> large explosion in rows.

Yes, that is the plan! Thank you for saving me from explaining why we
don't need to track how rules were created. (And, Sam, I hope we don't
go down that road since it would be very complex and a *nightmare* for
the Bug Squad to maintain!)

Now - I recognize that *this spot in the road* is "the big question
mark" with my proposed approach.To be honest, I am not worried about
because the rules table is basically numeric key values.

Having said that, proofing this concept is one of our LAST steps.
Let's get the data requirements and user interface refined. Then, we
should test other ideas. This is also the *spot in the road* that
Andrew is talking about with his JSON concept. I have a couple of
other ideas along the lines of Andrew's, too, and I think Hannes, and
probably yourself do as well. So, to me, this is extremely important
but certainly we have many choices and one will work. Agree?

One permission at the root of the tree is
> potentially going to add rows all over the place because you have to
> add entries to those things that aren't set to implicit inherit (not
> to mention finding them) in both categories and their child articles.

Again, a bit of a tuning thing, but briefly, if we are worried about
this, for the outlayers, like "Public" and "Administrator", we could
do some implicit logic.

But, my very strong preference, Sam, is to build it "right" because
that is maintainable and simple. Then tweak what we have to for
performance. Implicit permissioning will create nightmare SQL. There's
nothing more elegant than a join.

One point, Sam, to reflect on my experience with this in Data
Warehousing. Huge, HUGE, tables - and we used nothing but row level
access and had thousands and thousands of users, k? So, I'm not
worried but I understand you are saying "watch out here." And we'll
see. Indexing can be a big savior and let's not throw any descriptions
into the rule table - keep it small and numeric.

>
> Again I don't feel this is how you would expect it to work and isn't
> how it works for what most people use daily. You set a permission at
> the top of the tree and it gets merged in at the bottom somehow. You
> remove said permission and it disappears.

Yes. Those are the goals and that is what people expect and you should
make sure the prototype proves it.

>
> > Agree with your point that enhanced ACL will complicate life. Going
> > out the door in 1.6, the simpler, the better, in my thinking. For me,
> > that means "Apply to children" is a one time deal and Joomla! adds a
> > Rule for each item. If there are exceptions, then those rules can be
> > located, and then deleted.
>
> > "Apply to Children" is simply a time-saver, in my thinking. It's used
> > when there are no exceptions, or fewer exceptions then there are
> > correct assignments.
>
> > In the example above, absent "Apply to Children", 5 rules would have
> > to be manually created. Folks ain't going to like that. ;-)
>
> But you fail to address the issue of 'unapplying' the permission. To
> revert a particular permission people aren't going to like going to n
> many items to manually unapply in a way that doesn't nuke the
> non-related permissions unless you record somewhere that a given
> permission that you're effectively copying is from somewhere else.
> What you actually are doing is copying the permission, not inheriting
> it, for those items that aren't inheriting just because they want to
> set one permission (in this case, granting one person extra the
> ability to edit an item).

I think I know what might I might not have made clear. Because you
continue to raise this point about "uncopying" the permissions and I
am so *not* worried about this! Quick example - but mainly - let's
see how it works in the prototype.

Add Example:
- Add a rule that says "Group 1 can publish Articles for the College
of Arts and Sciences" - and - select the "Copy permissions to
children" option.

University
\-- College of Arts and Sciences
\--English Department
\-- Staff Bios - Owner Edit
\-- Article 1 - Bio Dean of Department

The result - the Rule Table will have 4 rows (this example assumes
there is only 1 article in that tree):

Row 1 - Group 1 - Publish - Content - College of Arts and Sciences
Category ID
Row 2 - Group 1 - Publish - Content - English Department Category ID
Row 3 - Group 1 - Publish - Content - Staff Bios Category ID
Row 4 - Group 1 - Publish - Content - Staff Bios Category ID - Article
1 Content ID


Delete Example:
- Locate and remove this row, again selecting the "Apply permission
change to children" option:

Row 1 - Group 1 - Publish - Content - College of Arts and Sciences
Category ID

The other rows would be found and removed using the same logic that
created them - not a problem!
Row 2 - Group 1 - Publish - Content - English Department Category ID
Row 3 - Group 1 - Publish - Content - Staff Bios Category ID
Row 4 - Group 1 - Publish - Content - Staff Bios Category ID - Article
1 Content ID

Now, if time passed and someone removed Row 3 on their own, then only
2 and 4 would match the criteria and get deleted.

Let's review this closely in the prototype and see what "gotcha's"
might pop-out, but I'm pretty comfortable with this, Sam, in terms of
adding and removing. We'll see. Yes, another good area. You are
officially in charge of testing the prototype and defining use
cases. :-P

>
> Sam Moffatthttp://pasamio.id.au

OK, I'll try within the next day to get that prototype together. If I
misunderstood you, the examples should help us get more focused and in
tune on thinking.

Thanks so much, Sam!
Amy :)

[Andrew Eddie]

Hi Amy

Just forget about the schema and how a rule would be constructed
programattically - we'll get to that. Just work on the "how would a
non-techie" describe what they want to do.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/6 Amy Stephen <amyst...@gmail.com>:

[Amy Stephen]

My draft schema is done - I'm ready to mockup the application. I must confess, Andrew, since I'm a database person, I use schema development to help me think. So, it might be an unusual approach for some but I don't do anything before the data model is sketched out. It's just how I'm wired.

No worries, though. I am now working on the step you are suggesting -> "How would a non-techie describe what they want to do." That's the powerpoint mockups I was describing.  I'llIt shouldn't take long now that I have my head around it. Hopefully, tomorrow.

Thanks!

[Hannes Papenberg]

I'm not sure if I understand you correctly Andrew. I hope you mean that
we should just describe what kind of permissions a user wants to set up.
Otherwise I'm embarrassing myself in the following lines. :-)

I, Joe User, want to go into my Joomla and set the following permissions:
- I want to select who has access to the backend.
- I want to select which components others are allowed to see
- I want to select if someone should have access to the global
configuration and the global parameters of components
- I want to restrict my editors to only certain special categories to
create new articles or edit existing ones. (They've got no business in
the disclaimer or the contacts page)
- I want to assign them a category to play with and preset the
permissions that should apply for the articles that those people are
creating in there.
- I want to be able to change the permissions for a category and those
changes should also apply to already existing articles. I've learned
that from the parameter system in 1.5, where I can set something to "use
globals".

Is that a proper description?

Having this written down shows me, that we might have a problem to
fulfill the fourth requirement with the JSON concept, since it would
mean, that we have to load all categories, process the JSON arrays in
them and check if you have permissions to that category. This might
cause a performance problem when we get into certain size ranges.

Hannes

Amy Stephen schrieb:

> My draft schema is done - I'm ready to mockup the application. I must
> confess, Andrew, since I'm a database person, I use schema development
> to help me think. So, it might be an unusual approach for some but I
> don't do anything before the data model is sketched out. It's just how
> I'm wired.
>
> No worries, though. I am now working on the step you are suggesting ->
> "How would a non-techie describe what they want to do." That's the
> powerpoint mockups I was describing. I'llIt shouldn't take long now
> that I have my head around it. Hopefully, tomorrow.
>
> Thanks!
>
> On Sat, Sep 5, 2009 at 8:01 PM, Andrew Eddie <mamb...@gmail.com
> <mailto:mamb...@gmail.com>> wrote:
>
>
> Hi Amy
>
> Just forget about the schema and how a rule would be constructed
> programattically - we'll get to that. Just work on the "how would a
> non-techie" describe what they want to do.
>
> Regards,
> Andrew Eddie
> http://www.theartofjoomla.com - the art of becoming a Joomla developer
>
>
>
>
> 2009/9/6 Amy Stephen <amyst...@gmail.com

> <mailto:amyst...@gmail.com>>:

> >
> >
> >
> > On Sep 5, 6:03 pm, Sam Moffatt <pasa...@gmail.com

> >> Sam Moffatthttp://pasamio.id.au <http://pasamio.id.au>

[diri]

On 5 Sep., 04:03, Amy Stephen <amystep...@gmail.com> wrote:
> ...

> I can see where Andrew's idea on the JSON field might be good for
> performance (even storing group primary keys in a list for quick use
> in an IN statement might be good.). I wish I had a feel for expected
> query speed to know whether or not that complexity would be
> worthwhile. The joins are straight forward. The denormalized list
> (stored as JSON, XML, or a SQL list) adds complication. It would be
> good to test ideas like that with prototyping, though.

Amy, last winter I had to implement a solution providing automatic
update of an existing database where nobody knows the level of it.
Only thing known is an actual reference database which reflects most
recent status of an application (sold for many $$$ ...).

Solution is to read all information from reference-db and each
customer's db. Afterwards you have to perform many checks in relation
to tables, fields, indexes, keys, foreign keys, stored procedures and
much more. Having done that you have to spit out an update script
which updates customer's db without loss of data.

While developing this I started using many JOINs to save time. I.e.
with MS SQLServer and it's provided sample DB it took about 15 minutes
to a) read reference db b) read another (similar, modified) db c)
create update script.

Changing JOINs to nested select statements (select a,b,c from (select
x,y,z from ...)) saved more than 30% of time. When I saw this I went
away from 2NF and 3NF. Implementation of specific parts is
implemented in kind of flat single tables instead of multiple tables
like being used after normalization.

Time needed than on very same systems:
Less than 1 minute for all actions even when there is a DB with more
than 1.000 tables.

When we are at speed there is almost nothing than kind of flat tables.
This take more knowledge of SQL but, needs dictate what to choose.

In case of ACL for a CMS:

You, Sam and Hannes provided some scenarios which should be written
down in understandable words first.

One will always find the problem of suffering of something when you
choose a role (group) based ACL only. There must be chance to
introduce exceptions based on persons.

Hannes told a simple scenario while you and Sam where discussing a
more sophisticated scenario with orientation like in real world of
clubs, magazines and companies.

To extend both:
I.e. somebody will be able to create a new item but, there is no
permission to edit (update) it.

What if 'somebody' encounters a typo a moment after saving the item?

What if there is somebody allowed to create and edit but, before
publishing there must be some proof reading before something being
edited will be published (common workflow in magazines)?

When we are at ACL developer team must clearly state what Joomla!
should become:
A system for hobbyists or a sophisticated system usable in
professional environment without complicated 3rd party extensions as
well.

[elin]

I understand that the full power of the ACL design is not going to be
exposed in the 1.6 core, but I think it is important to leave the
potential for more powerful uses there.

In the end, when it's fully implemented, users should be able to
assign rignts to specific assets to specific individuals (who are
members of whatever group is eligible to do something like access this
type of content) on the fly i.e. when they create or manage an item
inside of a component. This is already how it works in the better
document management, project management and group management
extensions. Every single time I create a content item that I want a
new possibly unique combination of 4 people to review before
publishing at which point I'm going to make the item available to the
public should I have to create a new permanent group in the ACL UI?
No, that would be ridiculous. If I make a blog post about ACL and I
want Hannes and Andrew to read it before I publish, I should not have
to go create a Hannes, Andrew and Elin group and then if I want Diri
and Amy to read it go and modify that group to add them. I should just
be able to open my blog and click off their names. After they give me
feedback, I or someone with publish rights for that content should be
able to go and change the setting to public and that "group"
disappears forever. I shouldn't even have access to the ACL interface
if I'm a blogger, and I shouldn't have to go to a super administrator
to do something as "simple" as let a few people read or edit my
draft. Simple being in quotes because it is an obvious use case for
the end user, but not obviously not so simple in code.

At the same time, I do think it is important for workflow to be able
to filter for everything in a component you can edit or publish based
on your group memberships that whoever designed the site sat down and
diagramed. I think modifying those groupings should be relatively
rare. So using com_content as an example, the category filters should
only show me categories that I have access to. Maybe it's not going
to be perfect, but it's going to be a step in the right direction.

So as a webmaster maybe I think it's not either/or. Maybe you need
some part that is on the fly, really specific and you have some part
for the permanent structural groups that deal with clumps of content
can be easily queried. I don't know, maybe I don't understand the
code issues wel enough, but that is what I would like to be able to
do.

Elin

[Mike Hamanaka]

Hi,

I have been keeping up the past few days with ACL stuff.

I am wondering if it is in the plans to have some sort of notification
to users who have been granted access to specific assets or items.

If The superadmin just granted me access to an item for review in a
special group as Elin mentioned, I might not know, or would I?

Mike Hamanaka
Website Production
Vertualize.com

[Amy Stephen]

I'm reading comments, but am staying focused on Andrew's assignments to propose Interface changes. I hope to have this done today. (Plus, it's my son's 19th birthday - w00t!)

What would be SUPER SUPER helpful would be for people to jot down Use Cases. Hannes has a great starter list. Sam has a good set of technical issues we need to verify.

I would suggest you dream big, here, and not assume any restrictions. Think about how you *want* to build Web sites and what types of access control you would need. Try to write these Use Cases out as non-technical prose. Avoid using any Joomla! terminology. Here's an example of one I want to see available:

Implement Joomla! in an elementary school setting.

All school personnel, students, and interested parents, will have sign on access.

School administration will have an area to share news with the general public.

A special section only accessible to school personnel will be used to share news items, policy statements, and announcements. Normal daily administrative information, such as 'lunch counts' and absences will be posted by faculty for use by the administrative offices. Given the sensitivity of naming absent students who could be home, alone, it is critical to never reveal this information publicly.

Each classroom teacher will have a separate area to share news, events, supply lists, spelling word assignments, and requests for assistance.

Most articles will be open to the public. The public can comment on these articles but comments from non-members will be moderated prior to publication.
Some classroom articles might be sensitive in nature, for example, scheduled plans  detailing time and location for field trips. The classroom teacher must be able to restrict those articles for view by only those with sign on access.

Each student will have a separate area for their personal online portfolio.

The student portfolio can only be viewed by the student, faculty, and parent.
Students will submit work to their portfolio.
Students may not publish work for public access.
The classroom teacher will review work and provide assessment feedback.
The classroom teacher might publish selected items to a publicly viewable "showcase."
Parents will have access to view all work submitted by their children.
Parents can read teacher feedback and post comments and questions.
Students can comment on their work and in response to other feedback.

Please leave the soapboxes behind. Statements reminding that the solution must be easy are not helpful in the slightest, it's highly offensive, in fact! Only a moronic fool would want a complex solution, folks! Let's not insinuate people are that silly. We all want easy. We all want flexible. Users are not more important than developers and developers are not more important than users. Without one, there's no reason for the other, so, we are going to try to meet everyone's needs, as much as possible. But, we can't meet your needs if you don't share what those needs are. And "easy" is not something that can be mathematically proven.

If you want to help, get specific with what you need, don't assume restrictions, and post those Use Cases.

More soon!
Amy :)

[Amy Stephen]

Elin -

Easy on the 'ridiculous' - please.

Groups are absolutely going to be key. It's a data architecture element. There is absolutely no reason that people can't have individual groups. I've already considered how awesome it would be to have a configuration option that automated that.

You have very good use case information in there. Try to word it in the affirmative - like you are creating a requirements document that developers are going to bid on. Try not to add in judgmental comments or critic a possible system flaw for a system that has not yet been created!

In you is a great deal of knowledge on how people need the ACL to work. Write those things down and challenge the group. I am optimistic about our chances to meet your challenges.

Thanks!
Amy

[Amy Stephen]

Briefly, for all you ubergeeks who love performance challenges - w00t! I am sorry to say this, but, we don't have any performance challenges yet. We don't even have our plan, let alone the code to implement the plan. lol! So, hold that thought!

Right now, we are collecting use cases. I am putting together a Powerpoint with a first shot at a proposed user interface for people to respond too. (and first draft of modifications to the data model.)

I do understand that non-relational blob engines are coming into vogue (if I ever forgot, it would be brief since that's all Mitch Pirtle ever talks about any more. ;-) ) BUT this is a MySQL relational database environment and using standard approaches will always be easiest for our developers to understand, and then implement in their extensions since we are all experienced with that technology.

Having said that, if someone doesn't agree with my comment, that's cool. But, we don't have a performance problem to solve yet, so, let's hold those thoughts as we lumber towards getting there!

I am pleased to see you posting in, Diri, especially with your years of application and database experience. Tthanks for participating!
Amy :)

[diri]

Hi Amy!

On 6 Sep., 20:05, Amy Stephen <amystep...@gmail.com> wrote:
> Right now, we are collecting use cases.

This should be the very first step. Before we don't know the "what"
nobody is able to say something about the "how". ;)

> I do understand that non-relational blob engines are coming into vogue (if I
> ever forgot, it would be brief since that's all Mitch Pirtle ever talks
> about any more. ;-) ) BUT this is a MySQL relational database environment
> and using standard approaches will always be easiest for our developers to
> understand, and then implement in their extensions since we are all
> experienced with that technology.

What I wrote about performance has nothing to do with db engine being
used. I adopted work mentioned to MySQL, Oracle and PostgreSQL in
parts and found same results.

I'm eager waiting to see something about the "what" and appriciate
your work very much. Thank you, Ami!

[Hannes Papenberg]

And hello again,
I've been giving the whole ACL system a lot of thought today, tried to
re-evaluate the three proposals that we currently have on the tableau
and invested even more time in thinking about alternative systems with
new tools, etc. For example I tried to investigate if we could do the
whole ACL system as a set of stored procedures and MySQL triggers, in
the hopes to reduce the complexity from two systems (PHP and MySQL) to
just one. In the end its not realistic to create such a system. It would
also be as complex as my first proposal, so we would have little to no
gain from this. Anyway.

In the end we currently have two very different systems in terms of data
storage and with one important difference. The first system is the one
that Andrew proposed with JSON encoded multi-dimensional arrays for the
access informations. Where those are stored is something to discuss
elsewhere. The second system is the "original" phpGACL approach which I
was following after with my patch that started this thread. While
Andrews system is relatively easy to implement and has little overhead,
it has one disadvantage: You can't filter a query-result in MySQL on
other action permissions than the view permission. My system is
(theoretically) capable of doing that, but it is very complex and the
possibility for integrity-errors is unequally larger than in Andrews
proposal.

What does the missing feature mean in reality for you as a user? If you
have a usergroup that is only allowed to edit articles in one category
and you don't have any filters set yet in the backend article manager, a
user from that usergroup would still see the complete list of articles,
but the edit link would be greyed out. So you wont have a neat short
list, but only a long list of articles to which you don't always
actually have edit-access to. The viewing permission is not affected by
this. Now we have to decide if this feature is this important to us that
we will invest even more time into research (or that we take the risk of
the more complex solution) or if we are okay without this and
concentrate further on Andrews idea.

I'd like to hear your opinion on this one. :-)

Hannes

Hannes Papenberg schrieb:

[Andrew Eddie]

Hannes, with all due respect, forget about the technical
implementation, forget about JSON vs 3rd normal form tables, forget
about the API for a minute (and probably a few more). You can't do
any comparison until you have requirements to compare to. To that end
we need to work out the basic "specification" first for the whole ACL
system. Yes, it's boring and you'd rather be coding but this is what
release managing is all about. Mentally I've thrown my own RFC out
the window because I have no idea whether it's right in terms of what
is actually required.

The steps, in my opinion (and I think they've already been mentioned)
is work out:

1. what you want to control
2. how do you control it in the UI
3. how to support it via an API
4. what schema is required to support the API

Currently we are going in the reverse order and that's not going to
get us anywhere. "Better" ACL must be in 1.6, that's a given. But
there are a million-and-one opinions on what that looks like - let's
narrow it down a bit. If we don't do that then we'll end up in the
mess we had in 1.5 with different people thinking the router should
behave in different ways. Let's agree first on what we are doing with
ACL before working out how to implement it.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/8 Hannes Papenberg <hack...@googlemail.com>:

[Amy Stephen]

I forwarded a rough draft of where I am at to Andrew and Hannes. I have the User Manager (Users, Groups, Rules, and Members) sketched out and am now looking at how Content Levels will work. There's a lot to consider so it's taking me longer than I expected (or hoped!)

As I look at the WebImagery post from June that introduced ACL concepts - http://webimagery.net/banter/an-introduction-to-the-joomla-16-acl-api.html - this pseduo code has me confused.

The criteria for which content is not visible in this example. So, how is the $user->authorizedLevels know how to retrieve only those Groups the User belongs too that also relates to the specific content needed?

$db     = &JFactory::getDBO();

$user   = &JFactory::getUser();

$groups = implode(',', $user->authorisedLevels());

 
$query = 'SELECT *' . 
    ' FROM `#__content`' .
    ' WHERE `access` IN ('.$groups.')';

 
$db->setQuery($query);

Perhaps more clearly, what would this code look like if I wanted to retrieve all articles for Featured in Categories 1 and 2?

Thanks!

[Amy Stephen]

On Mon, Sep 7, 2009 at 9:44 PM, Andrew Eddie <mamb...@gmail.com> wrote:

If we don't do that then we'll end up in the
mess we had in 1.5 with different people thinking the router should
behave in different ways.  Let's agree first on what we are doing with
ACL before working out how to implement it.

First, a giggle that quickly turned into a long sigh for hours we all lost debugging that freakin router. Followed by a hearty "Amen!"

Let's go!

[Amy Stephen]

Sorry for spamming, one more thing, if someone wants the draft before it's done, email me.

I didn't want to send it out broadly and confuse before it was complete.

When I sent it a few minutes ago to Andrew (and a hopefully sleeping Hannes), Andrew correctly reminded me to stay on list. If you can wait, it won't be long. Andrew and Hannes are also doing analysis so it's gearing up.

Thanks.

[Amy Stephen]

Anyone know the secret to "lft" and "rgt"?

Trying to use the Category Manager to test out this Use Case, but I
think those values are what's causing problems.

In advance, thanks!

[Amy Stephen]

I posted an analysis and design concepts document for the ACL on the
CMS File list http://groups.google.com/group/joomla-dev-cms/web/Joomla%201.6%20Access%20Control.pdf

The document has several parts:

1. Current situation - review of ACL elements in 1.5;

2. Goals for ACL in 1.6, identifying high level changes for four
areas: System Access, System Administration, Content Development, and
View Access.

3. User Manager Design Recommendations to implement those goals,
including data clarification that should help simplify the Interface
and code base.

4. Custom Groups, Access Control Rules, and Members - "the area" I see
as a "make it or break it deal" with the ACL implementation. It will
be key to design Widgets that enable the user to easily build Groups,
Memberships, Three part Access Control Rule sets. Mocked up wireframes
are available for the various pages and detailed UX proposals on the
Widgets.

5. View Access Level for Content, Menu Items, and Modules. I ran out
of time or I would have mocked up a more comprehensive Access List
widget. I think it will be key that Groups can be created at that
location, from any combination of Group and Member selection. It is
also important that these Widgets link together, so creating a Group
would naturally lead to a choice of Membership selection, and/or Rule
creation. I will continue working on that provided feedback is
positive on these directions.

6. Use Case with the Elementary School example I provided. My
conclusion is the design is flexible and powerful. I cannot conceive
of a content and organizational arrangement where these tools would
not provide the sensitivity needed. As is often the case, the trade-
off for flexibility is complexity. Again, the reason for powerful,
interactive Widgets that cover that complexity by keeping the User on
the same page, retrieving data without page loads, and keeping a tight
integration between Groups - Members - Users - Rules - and Content.

If I have time, I'll try to record a presentation which should help
convey points better.

Feel free to review the PDF and offer your suggestions, questions.

Thanks!
Amy

[Andrea Tarr at Tarr Consulting]

I'd love to hear a good explanation as well. From what I could see they are
used for the tree structure to contain & identify the extent of the
descendents. If you have lft 16 & rgt 17, there are no children. If you have
lft 9 and rgt 24, then the family consists of 15 and their lft & rgt are all
between 9 & 24. So, for instance, if you want to select the family, you can
select based on the lft & rgt values.

Andy

Andrea Tarr
www.tarrconsulting.com

[Hannes Papenberg]

Almost. Left and Right or lft and rgt are part of the nested sets model:
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
It allows to load a complete (sub)tree in one query, manages the
ordering of elements and makes the parent field obsolete. We are still
keeping the parent field, because it simplifies handling. :-)

Hannes

Andrea Tarr at Tarr Consulting schrieb:

[Amy Stephen]

It's broken in the Category manager. My question was less definitional and more - what manual values can I insert so it works?

Thanks!

[Andrea Tarr at Tarr Consulting]

What are you having trouble with? Defining the parent doesn’t work on new items, but if you go back in you can edit the parent and it will stick. Sometimes I need to hit rebuild to straighten things up.

 

I’m not playing with the acl, so that might be introducing other things.

 

Andy

 

Andrea Tarr

www.tarrconsulting.com

 

---

[Amy Stephen]

Parent - ok, I'll look at the table in phpMyAdmin and see if those parent values are set.

Thanks!

[Andrea Tarr at Tarr Consulting]

You don’t need to go into the database for this one. It actually works on when you save an existing item, just not a brandnew item. New, Apply, change parent, Save even works.

[Amy Stephen]

lol - cool - thanks!

[Andrea Tarr at Tarr Consulting]

I located the problem with the new category parents and submitted a patch to the Joomla 1.6 bug list.

[Amy Stephen]

This evening, I recorded the Overview of the Design Document and I
updated the document.

I would appreciate your time reviewing the material and responding in
agreement or disagreement with the design elements. If we can get
agreement on design plans, then moving forward with physical design
details will be possible.

Material
- Overview of the Design Document: http://tinyurl.com/JACLPresent
- Updated design document: http://tinyurl.com/Joomla16ACL
- Collection of Use Cases: http://tinyurl.com/JUseCases

This evening, I'll post on Community for feedback, ideas and possible
problems with the design.

Thank you!
Amy :)

[Amy Stephen]

Community blog post is published.

http://tinyurl.com/FeedbackAC

[Andrew Eddie]

Quick Notes:

Remove groups columns - agree. Also add a popup "profile" view to
quickly see al the user stats of the user without going into the edit
form. What you propose in the "Members" view can be done in the
current "Group" view in my opinion without reinventing too much of the
wheel.

Regarding widgets in general, we need to have Ajax working
unobtrusively. In other words, test the "refresh" version first, then
add bells and whistles. Ajax doubles the time to debug. The concept
is good (I think) but leave the ajax for a future version.

Default group - agree.

I think you need to add the legacy groups because it would be
confusing to upgraded sites. For new sites, meh, maybe those could be
different. We at least need to test that those legacy groups work as
advertised so you might as well include them. The notion that they
are legacy though is not correct in my opinion. They are "just
groups".

Group-action-asset: colours are backwards :)

"View" is special and is linked to the Access Levels and it falls
under the Type 3 rule category. Group-action-asset is a Type 2 rule.
Group-action is a Type 1 rule. Suffice to say you break the whole
system if view is included here.

I think the tree is fine but I agree let's not worry about
inheritance. I think the tree structure will help people organise
large organisations (actually I know it does with implementations of
Control).

I think the action widgets need to be in the context of the asset.
You get into scaling problems when you add other extensions and types
of data - so let the "type" of data manage rules it knows about.
Still use widgets but do it in context. You will have the case where
a person will have access to categories, but not to the user manager.
Also would like to experiment if allow|deny is possible (allow to all,
deny to some).

The view access stuff you propose will require an entire
re-architecting of anything we've done to date. It's in the too-hard
or back-square-one basket. It's a compromise between power and ease
of use. I actually do not know how to achieve what you propose
programmatically, nor does Mike Benoit who created phpGACL.

Other than that good overview. Something to add to the introduction
is that in 1.5 all this stuff is actually there, but just hidden and
hard-coded in the API. So we are bringing out actions that Joomla
already uses, you just didn't know about them. However, one weakness
is that you've only concentrated on articles and not really thought
about how other extensions come into the picture (what happens when 50
extensions, including core, are installed all having their own bite at
the ACL pie).

That said, I still think we need to establish a matrix of all the type
1, 2 and 3 rules that the Joomla stack will support before we spend
too much time on the UI. If we dig too much into the UI first, we
risk running into scaling problems. I don't really care what the
process is that get's us there, but it needs to be done.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/10 Amy Stephen <amyst...@gmail.com>:

[Amy Stephen]

On Wed, Sep 9, 2009 at 8:53 PM, Andrew Eddie <mamb...@gmail.com> wrote:

Quick Notes:

Remove groups columns - agree. Also add a popup "profile" view to
quickly see al the user stats of the user without going into the edit
form.  What you propose in the "Members" view can be done in the
current "Group" view in my opinion without reinventing too much of the
wheel.

Profile view - I also thought that might be nice, kind of dismissed it not knowing how valuable. ?

Members View - would allow for the multiplicity of Group.
 

Regarding widgets in general, we need to have Ajax working
unobtrusively.  In other words, test the "refresh" version first, then
add bells and whistles.  Ajax doubles the time to debug.  The concept
is good (I think) but leave the ajax for a future version.

Hm. I think it's pretty important. You'd have to design the pages differently w/out Ajax (meaning you'd have to have several pages.)

Let's keep thinking on that.

 

Default group - agree.

I think you need to add the legacy groups because it would be
confusing to upgraded sites.  

Then, for upgrades, let's add it. Agree on that for certain.
 

For new sites, meh, maybe those could be
different.  

Agree.
 

We at least need to test that those legacy groups work as
advertised so you might as well include them. 

The notion that they
are legacy though is not correct in my opinion.  They are "just
groups".

Indeed. Problem is - the groups are confusing.

Here's my concern. Someone is looking at the new ACL. They have a need for 2 areas - each with different Publishers. So, they create 2 groups - assign a rule for the groups - assign the correct person to each area.

Then, they add those individuals to the System-provided Publisher group, too.

Now, their fine-tuned Group/Rules is worthless.

Further, they don't test the rules and don't figure it out for sometime.

I think it's asking for trouble to add it. I went around and around on this one for reasons you mention and your ideas on Upgrade seem to be a good compromise. New sites? I think no, personally.
 

Group-action-asset: colours are backwards :)

lol - I'm hoping that's a joke.
 

"View" is special and is linked to the Access Levels and it falls
under the Type 3 rule category.  Group-action-asset is a Type 2 rule.
Group-action is a Type 1 rule.  Suffice to say you break the whole
system if view is included here.

Andrew - I think Type 1, 2 and 3 rules are overly complex. Group - Action - Asset - time and time and time again, I think is easier. That's the reason I kept it the same.
 

I think the tree is fine but I agree let's not worry about
inheritance.  I think the tree structure will help people organise
large organisations (actually I know it does with implementations of
Control).

Well, I wondered that, as well. It implies inheritance, which isn't good. A hierarchy for presentation purposes could be helpful. I'm okay with that compromise, provided we can community inheritance is out.

 

I think the action widgets need to be in the context of the asset.

The action widgets are designed in the context of the object containing it.

So - Group Widget on User page - assumes User.

Rules Widget on Group page - assumes Group.

Member Widget on Group page - assumes Group.

Group Widget on Content Page - assumes the Content (Component, Menu, Menu Item, Module) that it is on.

So, yes, the Widgets are "intelligent" in that sense.
 

You get into scaling problems when you add other extensions and types
of data - so let the "type" of data manage rules it knows about.

The data design I have will be much smaller - fewer tables, fewer columns, few data elements, than is what is in place now. It's 3NF and minimal.
 

Still use widgets but do it in context.  You will have the case where
a person will have access to categories, but not to the user manager.

Now, I'm wondering if you watched the video? I think it helped explain the document better. I made that very point but probably wasn't clear unless you heard the explanation.
 

Also would like to experiment if allow|deny is possible (allow to all,
deny to some).

Hm. :)
 

The view access stuff you propose will require an entire
re-architecting of anything we've done to date.  It's in the too-hard
or back-square-one basket.

Not really, but yes, it's a fine-tuning in terms of data architecture. Now, listen though, it builds on what you have but tweaks it in terms of flexibility, and Andrew, trust me, it'll be a huge hit. Far simpler approach but much more flexible for our needs.

 

 It's a compromise between power and ease
of use.  I actually do not know how to achieve what you propose 

programmatically, nor does Mike Benoit who created phpGACL.

OK, so, I know this is very, very workable and I will produce the data model and the queries to show you. This is yours and the phpGACL design - just tweaked a bit.
 

Other than that good overview.  Something to add to the introduction
is that in 1.5 all this stuff is actually there, but just hidden and
hard-coded in the API.  So we are bringing out actions that Joomla
already uses, you just didn't know about them.  However, one weakness
is that you've only concentrated on articles and not really thought
about how other extensions come into the picture (what happens when 50
extensions, including core, are installed all having their own bite at
the ACL pie).

ALL content is treated that way. It's no different. Anyone who installs 50 extensions will feel it but - again - Andrew - this is a smaller footprint than what's there now, so, not sure the point?
 

That said, I still think we need to establish a matrix of all the type
1, 2 and 3 rules that the Joomla stack will support before we spend
too much time on the UI.  If we dig too much into the UI first, we
risk running into scaling problems.  I don't really care what the
process is that get's us there, but it needs to be done.

Disagree, but that's just because we look at development differently. I look from the data and usage side first, you are focused on the development. Thank goodness we have varied perspectives.

I feel very good about these improvements, Andrew, and I think it's not as challenging to bring it in as you might think.

Thank you!

 

[Andrew Eddie]

Regarding the view permission, you can disagree with me but you are
travelling down a road I have already walked. Good luck.

Like I said, I don't care how we get there, but an ACL specification
must be done - next week would be preferable.

[Amy Stephen]

On Wed, Sep 9, 2009 at 9:39 PM, Andrew Eddie <mamb...@gmail.com> wrote:

Regarding the view permission, you can disagree with me but you are
travelling down a road I have already walked.  Good luck.

lol - Tell me about this road then, please.

Are you saying that you tried using Groups for the listbox of Access Level options? That's what I am saying - retrieve the list of options from the Groups. After all, it's those rules that permit or do NOT premit the showing of the content!

SELECT DISTINCT group name
FROM rules
WHERE (content I am currently editing) MATCHES (content defined within the rule)
    AND (the rule provides VIEW access-so I know it's okay)
ORDER BY group name

? confused ?

What am I missing, Andrew? (I'm sorry, but I am just not getting it. This looks super-easy to me)


 

[Andrew Eddie]

I have no idea whether that query is relevant because it presupposes a
schema supporting an API, retrieving information from a UI to meet
certain requirements ... and what were they again ??

I will say this once more. Define the requirements first, then sort
out the UI, API and Schema. Establish the point of truth first.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/10 Amy Stephen <amyst...@gmail.com>:

[Amy Stephen]

I presented a very clear proposal, based on a fairly complex and reasonable Use case, that demonstrates requirements for an Access Control environment. It includes design, process, wireframes and usage instructions for how we could provide for those requirements and how it would be used. I even showed how I tested those ideas with the Use Case and provided my feedback on those results.

In my thinking, I have fulfilled the request you made of me on Friday. Certainly, what I provided is a far clearer picture of what we might collectively work towards in the ACL than *anything else* I have seen to date.

Do you have a requirements document that you have written for what's in place now? Does the development team have anything spec'd out that we should be reviewing? Do you have an example of what you consider to be an acceptable form or process or end result?

Those types of examples might help me "establish the point of truth" - your sarcasm does not.

Good night. It's been too many hours and days pulling this together. Maybe more later if it's clear what I am supposed to do.

[diri]

Hi Amy!

On 10 Sep., 05:35, Amy Stephen <amystep...@gmail.com> wrote:
> I presented a very clear proposal, based on a fairly complex and reasonable
> Use case, that demonstrates requirements for an Access Control environment.
> It includes design, process, wireframes and usage instructions for how we
> could provide for those requirements and how it would be used. I even showed
> how I tested those ideas with the Use Case and provided my feedback on those
> results.
>
> In my thinking, I have fulfilled the request you made of me on Friday.

Don't get me wrong, please, but:

Amy, I'm not able to see what can be set in relation to ACL after
having multiple very close looks at your proposal.

IMHO you stick to much with UI and similar while there is no
definition of *WHAT CAN BE DONE* . Again: I still don't know
capabilities of ACL.

I assume a simple matrix would provide what is needed as very first
step:
Which action can be taken by whom, or: What can be set / allowed.

Excuse me again, please, but, I fear you do a lot of work without
having done groundwork. Don't take the saddle without having a horse,
please.

Afterwards (after fixing features) implementation can be discussed as
well as integration into UI.

[Amy Stephen]

Diri -

The proposal lays out very clearly who (3 specific system and custom groups) can do what (eight specific actions) to what (a set of 25 assets). If you want me to put that into Matrix form, give me 5 minutes.

Thanks!
Amy

[Hannes Papenberg]

Hi people,
we had some more meetings yesterday and discussed the current status of
1.6 in the Release Team. Since when I started this thread I had set an
expire date on this discussion, I wanted to inform you, that we are
extending the timeframe at least till next saturday to get the best
possible result out of this process here. So, lets get back to the
drawing board and finish these plans. :-)

Hannes

Amy Stephen schrieb:
> I attached the Word Document http://groups.google.com/group/joomla-dev-cms/web/ACL.docx
> in case that's easier to read.
>
> >
>
>

[Amy Stephen]

Bless you!

[diri]

> Bless you!

Seconded!

Amy,

may be you could provide a matrix about who can do what and which
permission can be set by whom.

I mean something like

permission applies_to_user set_on set_by
read group category group_admin
read users category editor
write user item user

You will see how it has to look when you try to show scenarios
mentioned in such abstract but nevertheless very easy to understand
way.

Most probably you will encounter several traps and pitfalls when doing
it this way. Such a matrix is no five-minute-job, I fear ... ;)

[diri]

Ooops, forgot to mention some permissions:

permission applies_to_user
set_on set_by
set_permission user
action_set_permission user

[Amy Stephen]

Diri -

It appears from this little matrix that you might not have watched the video or used the document linked to from that blog post page. There were a number of updates between versions. These permissions you are listing are not at all what is being described.

Please do take time with that material, it is actually pretty substantive. http://community.joomla.org/blogs/community/1036-joomla-16-access-control-design-concepts.html

Now - I've also 25+ years in the industry and there are thousands of ways to define requirements - but there is one thing in common for any well developed set - and that is that this information comes from Users.  Our goal is to nail what they need and writing things cryptically will make it difficult for us to reach out and get some feedback. The video and the illustrations provided are intended to reach them - and judging from the response - it's working.

Cryptic stuff coming for geeks, never fear! And, do not hesitate to jump in and offer your best shot at what you think is important documentation. Given your background, I am quite certain you can do it! So, don't wait for permission - but if you are looking for an invite - you are invited to do it! :)

Thanks!

[Andrew Eddie]

Hi Amy

I apologise for the sarcasm, but I seem to be repeating myself over
and over. I already told you that I thought your proposal as a
presentation was really good, but it was something for a few steps
down the track. The development team is the community (last I looked
- hopefully it hasn't changed) and the spec is what I'm asking for. I
already gave you an example of the level of detail I thought we should
start at here: http://groups.google.com/group/joomla-dev-cms/web/joomla-1-6-acl-specification
I've since started to put it in matrix form and do multiple passes
(ok this works for article, what happens when we add in the Banners
component, or the installer).

What you have done is helpful, but please don't be offended that I
disagree with how you draw some of your conclusions. It's good in
terms of helping people see that this is a wide-angle-lens job (no
microscopes allowed). But you are over focusing on articles when
Joomla the access control system has to be more platform-like. I was
over focusing on the API and schema without regard to what the system
was supposed to do. Dust off, learn, move forward.

[Andrew Eddie]

Thanks Hannes.

I think a week to at least get a compass heading should be achievable.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/11 Hannes Papenberg <hack...@googlemail.com>:

[elin]

This thread is a general discussion of ACL issues not discussion of
one person's specific ideas. Diri and everyone else please feel free
to post whatever you want related to the original topic.

Elin

On Sep 10, 3:39 pm, Amy Stephen <amystep...@gmail.com> wrote:
> Diri -
>
> It appears from this little matrix that you might not have watched the video
> or used the document linked to from that blog post page. There were a number
> of updates between versions. These permissions you are listing are not at
> all what is being described.
>

> Please do take time with that material, it is actually pretty substantive.http://community.joomla.org/blogs/community/1036-joomla-16-access-con...

>
> Now - I've also 25+ years in the industry and there are thousands of ways to
> define requirements - but there is one thing in common for any well
> developed set - and that is that this information comes from Users. Our
> goal is to nail what they need and writing things cryptically will make it
> difficult for us to reach out and get some feedback. The video and the
> illustrations provided are intended to reach them - and judging from the
> response - it's working.
>
> Cryptic stuff coming for geeks, never fear! And, do not hesitate to jump in
> and offer your best shot at what you think is important documentation. Given
> your background, I am quite certain you can do it! So, don't wait for
> permission - but if you are looking for an invite - you are invited to do
> it! :)
>
> Thanks!
>

[Amy Stephen]

Andrew -

I appreciate your apology. Thank you. It's important we try to be respectful, even when we are frustrated. :)

Thanks for sharing that link for others, too. Yes, you did share that link with me, but it was only after I shared the first draft of material with you and Hannes. You had suggested this other approach, but I responded to you that after several days preparing information in non-technical way so that we could get feedback from users, I wanted to finish that approach, publish it, before beginning another task. Your initial call was to figure out what they need was a good one and we can develop stronger specifications with their involvement. Andrew, they just cannot respond to technical specifications, they need screen shots, and ideas, and verbal explanation.

So. That's what I finished and the response has been very helpful. I hope you have a few minutes to read some of what they are saying.

Don't need to "dust off." I've been working *hard* all day. I have 18 pages of geeky technical specifications and am continuing to work in that direction. You might not like it but I'll GPL it and you can take it and have your way with it as soon as the draft is complete.

I was thinking today that I sure do wish when I volunteered to join the release team and help with specifications and communications, you guys would have taken me up on my offer. Communication is essential and I have a strong set of communication skill, technical knowledge and dedication to this project. Maybe if my offer had been accepted we wouldn't feel so rushed right now. Had to be said.

Let's keep moving - the work you have done is excellent, as usual. With these tweaks, Andrew, I think we are going to move from a very weak ACL in 1.5 to truly state of the art. Thank you for your continued contributions and support and friendship all of these years.

Amy :)

[Ron Severdia]

On Sep 9, 6:53 pm, Andrew Eddie <mambob...@gmail.com> wrote:
>
> Remove groups columns - agree. Also add a popup "profile" view to
> quickly see al the user stats of the user without going into the edit
> form.  What you propose in the "Members" view can be done in the
> current "Group" view in my opinion without reinventing too much of the
> wheel.

Out of all the ACL proposals, ideas & recommendations I've seen so far
from everyone, this is the only bit that I would disagree with. I
don't think the fact that a user can belong to multiple groups is
enough of a justification to remove the column. As a site admin, it
would be painful to try and do a comparison on several people who are
in a particular group and then switch with a filter to see the members
of another group. It's probably OK with a single user, but once you
start comparing multiple users, it forces the admin to get out a
pencil and paper to keep track.

If the groups are set up properly, a user should belong to no more
than probably 2 or 3 groups at most anyway. I'm willing to entertain
the scenario where an inexperienced admin adds a user to 20 different
groups. If people feel cases like that are going to be the norm rather
then the exception, I'm personally willing to entertain the idea of
some other way to display the information (via tooltip or something
else). But just removing the column and relying on the filter is not
the answer.

[Amy Stephen]

Ron - you might want to watch the video or at least download the presentation. I recommend adding a Member list page - on that page will be one line per user/group - so, you can get every single group, every single person is in.

Thanks!

[Andrew Eddie]

Attached is more what I had in mind for what a specification might
eventually look like. It's very "draft" and each time I look at a
different component, something new pops up that cascades (hrm, maybe
that wasn't the smartest way to think of that).

The first page just establishes the game plan. I don't really care
whether the goals and strategies are perfect, they are just what they
are - just a point of reference.

The second page starts to break down, just using simple language, what
an extension will want to do. Note there is a common behaviour
defined because some of the more content intensive extensions have
near identical requirements.

The last page is looking at what the decision matrix looks like and
what the unique information that will need to be stored (I don't care
normalisation or how it is stored at this stage) in order that we can
establish whether or not a rule can be checked and you get the right
answer in context.

If we can finish that in a week, we will be in a good place for people
to start thinking about how the UI then works, what the developer's
API needs to look like to support it and of course what schema
logically follows. It establishes the point of truth by which we can
compare programming strategies, actually implement the sucker but more
importantly (I think) what the maintenance requirements are for the
Bug Squad and test cases.

After that can come all the flashy presentations and stuff and I'll be
right behind that band wagon. But for now, let's just use words.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/11 Amy Stephen <amyst...@gmail.com>:

[Amy Stephen]

Here's the draft I mentioned I was working on today. Had nephews and nieces tonight - so - didn't get more done.

Personally, I think you are going into detail on what the various types of Updates might be, and since we aren't changing those processes, I don't see as necessary to document for the ACL. (minor detail.)

To me, this is a simple check before the action. No reason to go into what the Component does - just catch the logic before it does it - check permissions - and deny or allow.

To me, this says it all:

Publish - View, Create, Update, Publish, Delete, Archive
Publish Weblinks
Publish Weblinks Category
Publish Weblinks Category Item

And - no reason to handle Category differently. It's a key part of the Component and the Component Rules should cover.

I feel like we are at the same place we were on Friday. I'm documenting what it would take to support my data model and you are documenting yours. One of us should stop wasting our time.

I wanted to make my ideas really clear. I thought those ideas made a lot of sense and I thought if you say them, we could straighten a few differences of opinion out and move on. That presentation I provided was in support of the data model I recommend we use. It's in 3NF, and users define all rules within the Group. The rules defined there are available for the "Access List".

Your data model is in 3NF, but it's populated with redundant data. You've said that had to be done but I still don't understand why. I think that redundancy is creating problems. I do not understand - still - why you are creating another source of data for Access List. How is it not confusing for Users to create Rules and associate those with Groups and put people into Groups -- and then have an entirely second process to create View rules? I do not like it. Not at all. Further - how do Groups associated with those View rules? Seems mucky, Andrew. And I still have not heard an explanation as to why it must be done that way. (I've asked. I've heard you wish me luck. I've heard you say you've tried that direction, etc., But, I have not heard your reasons.)

To be honest, I would really like to see a full picture of your UI ideas like the one I showed. Even if you could take my presentation - pull out what you don't want - add in what you need - then, if the flow seemed right, I could force my DBA heart to ignore the redundancy and pretend I didn't know about it. ;-)

Thing is, I don't want to waste your time or anyone else's time - and I don't want to waste my time. ;-) I've tried to present my case. Further documenting my case into cryptic form - and you documenting your case into cryptic form continues to waste someone's time.

What should we do?

[Júlio Pontes (Joomila)]

Hi guys,

I wish help you on ACL. I will try explain my Idea of ACL for Joomla
implemented on NoixACL 2.1 (development)

We have a segmented ACL in 5 parts.
- Extension
- Application
- Roles
- Rules
- Restrictions

NoixACL provides a lightweight and flexible access control list (ACL)
implementation for privileges management. In general, an application
may utilize such ACL's to control access to certain protected objects
by other requesting objects. We can have diferent settings by
applications(site/administrator)

How works

//get the aplication id
$applicationId = JFactory::getApplication()->getClientId();
//define the extension
$extension = new NoixACLExtension('com_content');
//define action
$actions = 'view';
//define restrictions ( if need )
$restictions = array(
'catid' => 5,
'user' => 1
);
$restriction = new NoixACLRestriction( json_encode($restictions); );

//define a role
$role = new NoixACLRole('Articles Manager');

now we can define a rule

$noixacl = new NoixAcl();
$noixacl->allow( $applicationId, $role, $extension, $action,
$restrictions);

for check if group have access.. we use the same logic



$noixacl->isAllowed( $applicationId, 'Articles Manager',
'com_content', 'view', );

If yo uhave a role and wish extract all rules you can:

//you can get a repository to help you to manage ACL

$roleRepository = new NoixAclRoleRepository();
$roleRepository->findRoleId( $id );
$roleRepository->findByUserId( $uid );

//if need you can extract rules from Role group

$noixacl->extractRules( $roleObject );

you can assign role to user or a usergroup.

...
this is a basic idea...

I wish this help in anything..

[Ron Severdia]

On Sep 10, 7:10 pm, Amy Stephen <amystep...@gmail.com> wrote:
> Ron - you might want to watch the video or at least download the
> presentation.

Saw both before I posted. :)

[diri]

Hi Amy,

On 11 Sep., 05:56, Amy Stephen <amystep...@gmail.com> wrote:
> Here's the draft I mentioned I was working on today. Had nephews and nieces
> tonight - so - didn't get more done.

you have done a lot of work, phuuu....

Thank you!

Now, it looks like you have a different view about defining possible
ACL than i have.

Example, quote from page 13:
“All Content” includes anything presented on the Web site. It is fully
inclusive. Publishing includes View, Create, Publish, Delete, and
Archive rights. Publishing authority includes the same abilities for
related Categories.
End quote.

Here you are there where I am all the time: "All Content" includes
anything. It is fully inclusive.

"anything" means content, banner, link, user permission, ... . Really
any thing.

Datamodell is of no interest at the moment. This step depends very
much on agreement about "anything".

> To me, this says it all:
>
> Publish - View, Create, Update, Publish, Delete, Archive
> Publish Weblinks
> Publish Weblinks Category
> Publish Weblinks Category Item
>
> And - no reason to handle Category differently. It's a key part of the
> Component and the Component Rules should cover.

Here is something where I would like to change permission:
"Publish" must not include "Create" all the time. "Delete" is also not
needed for a "publisher" IMHO. "Publish" might include "Update" to be
able to do spell checking and to fix typos.

Remark:
I look at whole system this way. I do not distinguish tasks related to
users, menus, categories, banners, content, ..., whatever. Whichever
permission exists can be granted, restricted or denied to everybody
and on everything in my oppinion. Question is how granular ACL should
be.

To illustrate it:
You are a teacher and run a project with class A. You have all
administrative permissions related to this project.

You assign a project leader for Task A.1 with permission to create
menus, assign permissons to create and edit items as well as to
publish items.

When project goes further you do the same for Task A.2 and so on.

Some months later class changes, you exchange complete group of
project members with new users.

This scenario is very common over here not only at schools.

[on Sponge]

Hi Amy, great work and so much effort behind what you have done with
the video. I have been quietly reading all the emails through the
google groups and have been looking for the time to jump in. I
assumed that time would be 1.7 as my history of the joomla dev
community is limited, however, this discussion presents an opportunity
to start sooner :) So here is my first post ...

Firstly, I love the widgets in the article creation and well in fact,
most of what you have displayed. I have a few comments/questions/
suggestions ....

In the user list - I would keep the Group column as most users will be
in one group and perhaps a mouse over tool tip to see the other groups
for those in more. Also in the user list, I think the ability to tick
tick tick and add to Group function (ie mass add to group) would be a
massive time saver. I recognise there is a widget to add members to
groups however that list has limited real estate and is still a 'one
at a time' action.

In the Members list/page ... the drop down boxes are used to sort by
either username, name, group. This is inconsistent with the other
lists/pages in that these drop down boxes are normally filters. We
normally click on the column header to sort. Also, I would like to
see the default to be sorted by groups since the user list already, by
default, sorts by username. The listing by groups, I think, would be
best served by some form of collapsable/expandable interface allowing
one to see an immediate overview of all groups and then opening a
group to see its members. If you allow for multiple group opens at
once, then this would allow for a quick comparison of two or more
groups.

Also, in groups. The ability to tag / categorise groups would be
useful. Examples could include security, mass mailing,
administration, design, etc. From an administrative point of view,
this will greatly help with the management of groups. It is typical
of companies / administrators to create many many many groups only to
confuse themselves. By allowing tags would ease the categorisation /
management. Personally, I try to separate groups for mailing lists vs
groups for access control purposes.

Group Members Widget, please include email address. Many times when
managing groups admin will use the email address to find users. For
example those who have registered for a new workshop through email.
The task is typically create a group and grant that group permission
to a kunena forum. Then add those who sent an email to the group.
Its a pain to search the user list for all the email addresses to find
the user name.

During registration, we can define the default group - typically the
Registered group. It would be nice that when registering users from
the backend we have the ability to add users to multiple groups rather
than having to add them after and/or having to specify many groups,
say 10, for each newly registered person. Eg. Registered and students
or Registered and Teachers and HODs. This will save much of the to
and fro when doing mass roll outs to known communities.

Making the user related parameters, from the global configuration, is
useful as you have suggested and for similar reasons, why would we not
make them available from both places? In fact, this is a question I
had for all of the system wide parameters that are getting moved out.
I do not believe it would be confusing to administrators to allow
access from both areas. If fact, I think for the system
administrators with global configuration access this would be
beneficial instead of having to go in and out of the various areas to
make system wide changes especially when setting up a new website.
Anyway, not that big a deal just that I know many ppl who are starting
out use the global configuration as an area to see what is possible
and thus moving everything out limits that learning. So personally, I
would challenge the trend and instead so make those parameters
available from both places.

Removing all the legacy groups. I assume there will be a migration
script mapping users from old to new for our current member lists?
Would it be better to keep the legacy groups there for 1.6, removing
them in 1.7? This would eliminate the need for any mapping scripts.
What about other groups that many have created already?

When creating articles, defining which groups can view this article
and/or creating new groups - brilliant :) You stated that this would
be available to publishers and above?? What is above when the parent/
child relationship has / is being removed? Shouldn't the widget be an
asset/object itself and this be granted access to one or more groups?


---------------------------------
One thing that was not clear to me, watching the video, was whether or
not the defined Groups (creator, publisher, etc.) was manageable or if
they had a predefined / fixed set of permissions. It appears as those
they are fixed. Which means that if you can archive you can also
delete as an example. Is my understanding correct? If so, then a few
more comments ......

The issue describe was that some administrators wanted to assign edit
privileges to users who could only create?? Correct me if I am wrong
on this. Now we have the option to use a system wide parameter to say
creators can create or creators can create and edit. What happens
when we want some creators to create only and others to create and
edit? To do this we must, I assume, set the system wide parameter
such that creators cannot edit. Then add, those specific creators to
a publishing group. But what if I don't want them to delete and
archive? Ie edit only. Would it make more sense to have authors,
editors, publishers? Or keep the various permissions independent ie
no access, view, deposit, append, update, edit, install, un-install,
publish, unpublish archive, delete and then assign these permissions
to the various groups. A real example is one of my business partners
can deposit articles but cannot read them. I have an journalist who
can read and edit the article but not delete nor publish. I have an
editor who can read, edit, archive and delete. Of course I may even
want to restrict who can publish / unpublish or who can allow articles
to be replicated to another website in the case of multiple websites
in which case I may want to create my own permission called
synchronise.

How do we explicitly deny access, to a particular article, say ART,
from a specific person, say ABC? I assume that person would be
assigned to the registered group along with another 10,000 or so
people. Then, I would have to create a specific group called deny_art
to article ART and include ABC in that group. Then grant deny_art to
everything else that is going on??

[Andrew Eddie]

I'm sorry that you feel the spreadsheet is cryptic. It's actually
pretty close to your .docx. It's not normalised by the way... Don't
know what made you think it should be.

Some comments on the .docx (which thankfully gmail can read):

"Registered" does not have to equate to "logged in". Logging in is
just an action that any groups can do now. The trunk currently
supports this. This is an important mindset change to grasp
("registered" is just the "name" of a group - it has no special
meaning other than that). The trunk currently supports the notion of
"multiple" registered entry points. You can right now create some
interesting effects with this.

You don't need system and custom groups (and the protection of not
removing system groups). You just need validation logic to ensure a
minimum condition is met so that at least on person can log into the
backend as a super user. See my previous point about the fact that no
group is particularly more or less important than any other. Worst
case though we have abilities for web masters to get back into the
site.

The guest group doesn't have to apply just to the frontend. It's the
only exception to the rule in that it does have a special meaning,
that is, it's an anonymous user.

Your public group is illogical - it cannot represent users logged in
and not logged in.

The above negates needing API to handle the logic you'd need to
automatically assign users to your public and registered groups.
That's unnecessary overhead.

In your rules, you should not lump publish in with update, delete and
archive. Update and delete are different processes from changing the
state of a field (published, unpublished, trash, archive). You will
have trouble continuing with that logic.

I think the 1.5 way of handling the view access is really quite simple
and people understand it - not really interested in breaking that
formula. I don't see people saying the 1.5 method is wrong, just not
flexible enough. The access-level to user-group mapping is running
now in the trunk and it's totally transparent to anyone upgrading from
1.5 to 1.6 (nothing knew to learn out of the box). This is not a
hypothetical argument about whether it works or not - it does and it's
in the trunk. The implementation for 3PD's is also drop-dead simple.
All they have to learn is change:

WHERE access <= $user->aid

to

WHERE access IN JAcl::getAllowedGroups()

(note, pseudocode). It's elegant, easy to learn and easy to maintain
and it's already 100% done and implemented. It just works (like my
Mac - except for reading docx's). I don't see any case to undo it.

Comments is an interesting one. Are they entities unto themselves or
are they linked to the content? I think comment view rights are
probably better handled as options within a option or the content. If
there is a case for "you have to be in a particular group to see
comments" then maybe that's invalid, but is it "normal" behaviour.
I'd err on not. The same goes for ratings. Neither comments nor
ratings have any meaning unless tied to content.

Your respond actions don't grow on me immediately - but I'd really
need to digest that more. There could be some merit maybe just
looking things from a different perspective. Just haven't thought far
enough down the tracked of ancillary content.

The balance, apart from a few small things, seems to be on par.

The document is what I'd expect to see regardless of whether I agree
(or not) with it in total or in part.

[Andrew Eddie]

Hi Sponge

2009/9/11 on Sponge <goo...@onsponge.com>:

>
> Also, in groups.  The ability to tag / categorise groups would be
> useful.  Examples could include security, mass mailing,
> administration, design, etc.  From an administrative point of view,
> this will greatly help with the management of groups.  It is typical
> of companies / administrators to create many many many groups only to
> confuse themselves.  By allowing tags would ease the categorisation /
> management.  Personally, I try to separate groups for mailing lists vs
> groups for access control purposes.

There is nothing stopping you from creating benign container groups, eg:

Public
- Registered
- - Mailing List
- - - PHP
- - - MySQL

Where mailing lists has no users (but could be used to send an alert
to all mailing list groups).

> One thing that was not clear to me, watching the video, was whether or
> not the defined Groups (creator, publisher, etc.) was manageable or if
> they had a predefined / fixed set of permissions.  It appears as those
> they are fixed.  Which means that if you can archive you can also
> delete as an example.  Is my understanding correct?  If so, then a few
> more comments ......

It's fixed in 1.5. 1.6 is about unfixing it (pun intended).

> The issue describe was that some administrators wanted to assign edit
> privileges to users who could only create??  Correct me if I am wrong
> on this.  Now we have the option to use a system wide parameter to say
> creators can create or creators can create and edit.  What happens
> when we want some creators to create only and others to create and
> edit?  To do this we must, I assume, set the system wide parameter
> such that creators cannot edit.  Then add, those specific creators to
> a publishing group.  But what if I don't want them to delete and
> archive?  Ie edit only.  Would it make more sense to have authors,
> editors, publishers?  Or keep the various permissions independent ie
> no access, view, deposit, append, update, edit, install, un-install,
> publish, unpublish archive, delete and then assign these permissions
> to the various groups.  A real example is one of my business partners
> can deposit articles but cannot read them.  I have an journalist who
> can read and edit the article but not delete nor publish.  I have an
> editor who can read, edit, archive and delete.  Of course I may even
> want to restrict who can publish / unpublish or who can allow articles
> to be replicated to another website in the case of multiple websites
> in which case I may want to create my own permission called
> synchronise.

There is no real need to change the default groups because they serve
a useful purpose (and good examples). The advantage in 1.6 is that
you'll be able to tweak what "author" means if you need to. Or you
can delete the sub-tree from authors down and roll your own.

> How do we explicitly deny access, to a particular article, say ART,
> from a specific person, say ABC?  I assume that person would be
> assigned to the registered group along with another 10,000 or so
> people.  Then, I would have to create a specific group called deny_art
> to article ART and include ABC in that group.  Then grant deny_art to
> everything else that is going on??

I'd like to assume that "allow" and "deny" can be supported at least
for now. So you can blacklist (allow all, deny some) or white list
(deny all, allow some).

[Andrew Eddie]

2009/9/11 diri <di...@gmx.net>:

>
> Remark:
> I look at whole system this way. I do not distinguish tasks related to
> users, menus, categories, banners, content, ..., whatever. Whichever
> permission exists can be granted, restricted or denied to everybody
> and on everything in my oppinion. Question is how granular ACL should
> be.

The problem with granularity is that it comes at a price. You have to
accept that in order to get granularity, you have to administer at the
same granularity (in other words, the time you spend managing
increases where you want permissions to be more granular). It's not
possible to say I want 5th order granularity but be as easy as 1st
order (assuming 1st order is a very basic rule set related to all
users). With coarse granularity you can probably get away with
consider all content to be equal. Go finer and you have to start
taking individual content types into account.

[diri]

Hi Andrew!

On 11 Sep., 09:40, Andrew Eddie <mambob...@gmail.com> wrote:
> 2009/9/11 diri <d...@gmx.net>:

> > I look at whole system this way. I do not distinguish tasks related to
> > users, menus, categories, banners, content, ..., whatever. Whichever
> > permission exists can be granted, restricted or denied to everybody
> > and on everything in my oppinion. Question is how granular ACL should
> > be.
>
> The problem with granularity is that it comes at a price.  You have to
> accept that in order to get granularity, you have to administer at the
> same granularity (in other words, the time you spend managing
> increases where you want permissions to be more granular).  It's not
> possible to say I want 5th order granularity but be as easy as 1st
> order (assuming 1st order is a very basic rule set related to all
> users).  With coarse granularity you can probably get away with
> consider all content to be equal.  Go finer and you have to start
> taking individual content types into account.

You are correct and my idea about ACL is really system wide for this:

In most basic meaning you have several actions being possible only
(R,W,D,U, ..., you outlined them in your sheet).

1. To keep things easy for everybody have some kind of possible
general settings which apply to system similar to already known ACL
i.e. from Joomla!1.5.

2. Give chance to deny, restrict and grant different permissions on
everything in core.

Of course there are costs. But, IMNSHO costs are smaller as soon as a
complete system for everything is implemented in core. I.e. as soon as
you have distinctions in relation to type of object (item) the costs
will rise because they must be treated in special ways. Doing it
global you need few functions for everything only you can use caching
and more improving technologies.

Real problems might arise with real large systems and many different
"user groups". I can see it at large forum sites with many moderators
and co-moderators. I think handling of permissions in a CMS system is
similar to a sophisticated forum because I don't see any *real*
difference in such functionality.

[elin]

Fantastic start Andrew. Absolutely we should be building an
infrastructure that can be partially exposed in 1.6, further developed
by 3pds starting now and then devloped in 1.7, 1.8 and beyond
gradually be exposed.

I especially value the clear articulation of first principles and. the
systematic approach you are taking to building from there. Maybe it's
that timber engineering experience of yours that leads you to approach
it this way, but this makes me confident that the house is not going
to collapse under its own weight. I really appreciate your thoughts
about the two person site, excellent reminder for someone like me who
has been thinking more about what woudl happen if the data on the
forums site were pulled into Joomla.

First question: You are thinking of the access to categories actions
as controlled by access to com_categories, correct? Because this is
mainly focused on subtrees. Should delete, trash etc actions apply to
the complete subtrees, is that correct? Related to this, I worry
about the fact that we still have uncategorized content in this go
round, which makes com_content different from all of the other
components and much harder to handle with ACL unless we effectively
treat it as a category. Getting rid of the separate "static conent" in
1.5 was a big step but I think that it remains difficult to manage
unless we treat "uncategorized" as a category (and not outside of the
tree).

Second question: How do you want people to help fill in your matrix?
Comments in this thread? Updated spreadsheets that you can merge? In
a Google doc? Some other way?

Elin

[Amy Stephen]

Andrew -

How about this - you work on the library and define the API. I'll refine the UI plans. Hannes can lead on the application code. Lots to do - we can spread it out and try to nail details as we bring these things together.

Sound good?

Amy

[elin]

Andrew is this the kind of thing you ae looking forL

Cache Clear cache
Purge cache should these be separate?
Categories (component) View full tree

Checkin Global checkin of all
Checkin in specific category
Checkin specific extension
Checkin of own
Config Configure all global
Configure System
Configure Site
Configure Server
Configure each component Should we make a common configure?
Contact Contacts per common content
Categories per common category
Configure per common configure or is this under configure?
Content Articles per common content
Categories per common category
Configure per common configure
CPanel

Installer Install per extension type
Uninstall per extension type
Manage per extension type
Update per extenion type
Discover per extension type
View warnings

Or is that too detailed? You're right this will definitely be
iterative.

Elin

[Amy Stephen]

Those are all listed in the document I shared last night, Elin

Should be able to at least start from there - can't imagine there are too many more.

[elin]

Again, anyone feel free to post your thoughts, questions, and
responses to ANY other posts that you wish to or your own ideas. We
have development coordinators to deal with managing the information
and ideas, and if it gets too confusing for them they will surely let
us know. I know they are taking all of these interesting ideas into
consideration.


Elin

> > Elin- Hide quoted text -
>
> - Show quoted text -

[Amy Stephen]

First of all, thank you to Hannes for helping me understand. I understand the technical issues, tradeoffs, and reasons much better, now. I want to see if I can explain some of what I am seeing, make certain I understand, finally, why it is the way it is, and see if we can agree on a goal where it's clear a) what we won't give up and b) what we think might be worth trying to improve. Hope so, anyway! :)

Awesome.

The elegance of content retrieval for frontend access is brilliant. It will *not* get any faster than that, nor could it be easier for third party devs.

That must never change. It's perfect. The WebImagery folks did a blog post awhile back that demonstrates that simplicity:

$db     = &JFactory::getDBO();

$user   = &JFactory::getUser();

$groups = implode(',', $user->authorisedLevels());

 
$query = 'SELECT *' . 
    ' FROM `#__content`' .
    ' WHERE `access` IN ('.$groups.')';

 
$db->setQuery($query);

The User object has a session value populated one time containing authorized "Access Levels."

Each piece of "content" will have one access level - so - it's an easy, quick WHERE clause to see if the User can View this Content.  Very little change to migrate an Extension to 1.6's ACL, too.



The cost

A lot of design decisions for View access were made with that WHERE clause in mind, and rightly so. It was a worthy goal to design around. Some implications of those choices we can happily live with because it's worth it! But, I believe some User Interface choices made we can still improve without touching that View access piece.

Here are some of the elements of the User Interface that tend to be less intuitive -- that are directly connected to feeding that query.



1. Group Edit

The current interface allows you to:

• Create a Group (meaning - an object with a name).
• Assign the Group  "Manage" permissions (ex. Manage Plugins).

That's it.

The Group Edit page is not a place where all Access Control information comes together for a Group or can be maintained for a Group, like I had assumed and hoped.

So, these are things you cannot do on the Group Page:

• Can't see Members for the Group.
• Can't add Members for a Group.
• Can't define Content Access Rules for the Group.
• Can't see all the Rules for the Group.

I just thought this page wasn't done, yet, and that we would obviously a place somewhere in the Administrator where someone could review what a Group is authorized to do. But, there is no such place. So, what if responsibilities change for a group? How would someone begin to figure out how to modify previous assignments for this Group.

OK, that's a bit of a weakness, right?


2. Access Level Edit

As you have heard me saying, I found the Access Level pages, (including the need for a Global Configuration Default for Access Level), *extremely* confusing!

In my thinking, since we moved to Groups and Rules, you'd just add a View Rule for your Group and be on your way.

Now, if a content editor wanted to change the Access Level for Content, while editing the Content, they could use the Access Level (in my mind, now a listbox of Group Names) and make a different selection. Easy enough.

But, it doesn't work that way.

If you want to use a Group for View Access:
a. Create a Group.
b. Then, create an Access Level.
c. Then, select that Group you created while you are editing the Access Level.
c. Then, go into the Asset and select that new Access Level.

If you want multiple Groups to have View Access to something you must create an access level for each unique combination of Groups. There is no listing of all of these selections, so, you could create dozens of Access Level definitions, each for the same combination of Groups. You'd have no way of knowing.

Now, if we were going to be honest, we'd have to admit, those steps are not intuitive, and that is not the best way to manage data.

OK, I thought the house just wasn't done being built. But, this is the design. So, why in the heck are we jumping through these hoops? OK, I get it now, it's because we need a single value for that fabulous Query that makes View Access super, geeky fast and easy for developers to implement.

OK, finally I see why. And, I agree that keeping things "super freaky fast" and easy for extension developers is a uncompromisable goal. I'm on board with that query and whatever we have to do to keep it just like it is. It's a work of art.



3. Is this a Worthy Goal?

Would all be agreeable if we could figure out how to make it happen that we have a Group page where Rules and Members and Group would all come together? Would all be agreeable to getting rid of (or at least hiding) the Access Level in the User Interface?  Of course, the boundary is, we can't touch that Query.

I love the work done under the scenes on this. You guys are clever when it comes to the making things scream on the frontend. So clever, in fact, it took a question and answer session with Hannes for me to get my mind around this.

I think we could be clever and pull that UI back together, too.  Is it worth a try, at least?

Thanks - special thanks to Hannes, who must be the most patient man on earth. Wow.
Amy

[Andrew Eddie]

Hi Amy

1. The group page is far from finished. Please don't make assumptions
as if it is. It will probably change based on the outcomes of this
discussion.

2. I'm content with the UI for view access in terms of presenting it
to the community for comment. I get you don't like it - that's fine.
But so far I've not had any other critical feedback. I'm sure there
will be, and things neither of us have thought about. Like I have
said before: wet concrete. But it's all that is needed for beta.
Personally I think it's the line of best fit - balancing many
competing desires and requirements.

3. The problem with doing all you rules in one place is the permission
to allow setting of the rules in the first place (I've already
mentioned this). A component needs to have areas accessible to users
in context because we can't predict what the web master will want a
content provider to do. For example, you may want a user to be able
to control all category permissions, but have no access to the user
management system. This is actually where your idea of widgets comes
into play nicely. There may be a place for a
super-rule-management-page, I have no disagreement with that, but it's
not necessary for beta. All we have to do for beta is demonstrate
that we can enact type 2 rules (invent your own analogy for that when
explaining at a Joomla Day, but in this discussion I will use the
technical term), the UI works, the API is clean and the schema is
robust. Small steps Amy, small steps.

I think it's worth putting the fine points of where you set
permissions aside for a moment - it seems to be too emotionally
charged. We are missing out on some other interesting areas as well.

Modules - anything quirky there we need to take into account in terms
of "what" the system should support.

Menus - like categories, this is a tree. Can we consolidate behaviour
so that any tree data can be treated consistently. For example, are
their use cases for limiting a user to managing sub-trees.

Plugins - is access control really relevant?

Templates - is access control relevant?

Let's put those wide-angle lens's back on. We've got our microscopes out again.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/12 Amy Stephen <amyst...@gmail.com>:

[Andrew Eddie]

Hi Elin

Yeah, that's what I'm thinking, including the questions you pose.
It's probably worth erring on overboard initially, we can always prune
down if something feels over-engineered.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/12 elin <elin....@gmail.com>:

[Amy Stephen]

Definitely agree that this is *not* a Beta Blocker. And, I definitely
agree that this can smooth out, now that I see what you are doing and
why you are doing it. It all makes perfect sense to me.

I believe we can hide the Access Level step - and still keep it there
for the reasons it is there - but "secretly" create it as a bridge for
that View List.

We can also hide the single select for Access Level in the content -
let them select multiple - create a single element for the group -
associate it with the user - use it in the queries - but never show it
on the Interface.

So, those things, Andrew, are things we can smooth out.

I appreciate that it's not fun when someone gets something in their
head that bugs 'em and they don't let go until they figure it out. If
we can figure out how to survive those episodes, Andrew, we'll become
a community of developers. It was good talking on this and not having
it get personal. Tribute to your character.

Yea, yea, yea, small steps. Whatever the heck that means! ;-)

I'm on board. I'll think on those other things, too.

Thanks, Andrew,
Amy :)

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/9/12 Amy Stephen <amystep...@gmail.com>:

[Andrew Eddie]

Hi Elin

> First question: You are thinking of the access to categories actions
> as controlled by access to com_categories, correct?  Because this is
> mainly focused on subtrees. Should delete, trash etc actions apply to
> the complete subtrees, is that correct?

I dunno. I can see a use for it - but it might be too much work to
achieve in 1.6. I think there's scope to say "yes, this should be
done" but it has 1.7 beside it for implementation.

> Related to this, I worry
> about the fact that we still have uncategorized content in this go
> round, which makes com_content different from all of the other
> components and much harder to handle with ACL unless we effectively
> treat it as a category. Getting rid of the separate "static conent" in
> 1.5 was a big step but I think that it remains difficult to manage
> unless we treat "uncategorized" as a category (and not outside of the
> tree).

I think uncategorised content is hard to work out what to do with it.
I think basically it falls back to whatever global rules are applied
to it. For example, if you have global edit rights on articles, you
can edit uncategorised content. I think that's a reasonable
compromise. I think the use case from allowing a user only to do
uncategorised content, but nothing else, would be rare (though I could
be wrong).

> Second question: How do you want people to help fill in your matrix?
> Comments in this thread? Updated spreadsheets that you can merge?  In
> a Google doc? Some other way?

Post suggestions here is fine. I'll chip away on it over the next
week. It's already mutated a couple of times from when it started -
I'm sure someone will bring up other points that will throw a curve
ball (like Amy's "response" action - I hadn't really considered that
one). If it ends up being useful, well and good, if not, it's no
issue to throw it away. To try and fail is still valuable.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer






>

> Elin
>
>
>
> >
>

[Amy Stephen]

One more thing, Andrew, as a point of clarification - I am *not* in
favor of *only* doing all permissioning in one place. It should be
done - as you are - within the context of the content, too. And, I
agree, for some people, that's all they will be able to access. Not
missing that point. But, if we possibly can bring it all together as a
unified picture - that would be very nice. Very nice.

Thanks, again!
Amy

On Sep 11, 4:54 pm, Andrew Eddie <mambob...@gmail.com> wrote:

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/9/12 Amy Stephen <amystep...@gmail.com>:

[Andrew Eddie]

Hi Amy

A "super matrix" of some hitherto unknown description will be
required. There are a number of ways to do it but I think that
happens after "right, all the setting of permissions work nicely -
what tools do we need to make complex systems easier to
manage/debug/etc". It's possible a number of different flavours will
be required - dunno yet - will have to wait and see.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/9/12 Amy Stephen <amyst...@gmail.com>:

[Amy Stephen]

I hope you've found my comments and ideas helpful. That was my intention.

Thanks!

[Hannes Papenberg]

Hello folks,
as Amy said, we did talk quite a bit today. I also talked to other
people and threw around some ideas on all this ACL. I'm going to try to
give an overview which different approaches we are currently facing,
which benefits and which downsides they have. I'm also going to give
some of my opinions on this.

First of all, I'm not talking about UI, except for the case when the
structure asks for additional UI elements. My main concerns at this
moment are (in that order):
1. Performance
2. Actions possible with the system
3. Ease of use for third party developers
4. Ease of use for the user

My usecase is the following: I'm working for an online-printing
business. We have a large shop of printing services that you can buy, a
print-on-demand area where you can design your on-demand-product, a
service area which has an extensive FAQ and a userforum. I've got a
group of designers working on the design of the site itself and I've got
product designers that are creating the product descriptions and images.
Besides that I have two more groups responsible for the shop, the
accountants, which change the price for items in the shop and in the
on-demand-application and the processing group, which processes the
orders. In the on-demand area I have another group, the developers,
which need access to the site for testing purposes, but only to the
on-demand-area. In the service area I have some telephone support guys,
which answer questions and put them into the FAQ. They also work in the
forum, but there are also dedicated moderators for that, too. On top of
all this, we have the server admins, which need access to everything.

My other usecase is the opposite: We have a kindergarten with 10 people
caring for the children. They need a website for their organisation
which they can handle on their own, add and update content. It has
initially been set up by a small design company. The kindergarten
teachers are not very tech-savvy.

If we can provide a system that caters to both usecases, we found the
right one.

At the moment, I have five different systems in front of me. Some are
very similar, some are completely different. Lets go through them:

The phpGACL system
This is the original system that most of our later ideas are based on. I
wont explain the complete schema behind it, but a few things have to be
said:
First of all we have sections. All objects in the system are put into a
section to give it a context. This means that actions or content items
are bound to that section, for example com_content, and are only looked
at in that context. In the end this means, that you can have a "manage"
action in both the com_content and the com_weblinks context and they
both mean different things. The next objects are users, which can be put
into usergroups. With the action objects, you have your first rule
possibility. That means that you connect users and/or usergroups via a
rule to actions, all in the context of a section. This however only
allows rules like "Usergroup X can login to the backend" or "Usergroup Y
can edit all content items". As soon as you have a variable amount of
access objects, you need an additional type of access object. (To give a
few examples: A fixed amount of access objects would be the login
possibility. You can only login to the frontend and the backend and that
wont change. A variable amount of access objects would be the article
system, because an editor can add articles without touching the code and
the amount of articles will change all the time.) In any case, thats
what the asset objects are for. Those can also be put into groups. This
allows rules like "Usergroup Z can 'edit' 'Article 22'".
phpGACL is the maximum in flexibility. You wont find anything more
flexible out there than this. But this of course comes by a price, which
in this case is both speed and complexity. You wont find something more
complex than this. ;-)

The Joomla-ACL system with a Hannes-flavour
Sorry, I don't have a better name for this. But back to the topic: This
system is very similar to phpGACL, except that some of the stuff is
simplified. Instead of a seperate table to handle the user objects,
those are merged with the Joomla user table. You also can only have one
type of section per request for all objects, instead of different
sections. (in phpGACL you could have the action com_weblinks.manage on
the asset com_content.article22) The biggest difference however is, that
we are using the assetgroups to handle the view permissions exclusively.
Basically, we are creating assetgroups as replacement for the access
levels in 1.5, so that you can get all access levels that you are
allowed to see in one query, put them in your session and if you want to
query for example the #__content table, you do a simple "WHERE access IN
(<assetgroup IDs>)" and you only get back the content that you are
allowed to see.
This system currently does not really effectively lets you store
permissions for assets, which is why I added a parent field to the
assets table, so that you can build trees of assets (category ->
subcategory ->article/weblink/newsfeed) which inherit the access
informations from their parents upon saving.
This system is a lot more performant than phpGACL, is only a little bit
less flexible, but it would be especially easy to implement for third
party developers. Its downside is a pretty huge complexity in terms of
the handling of inheritence between the assets. If by some mistake the
process of updating those permissions is aborted (Apache crashing, the
page request is cancelled) the whole system could get into an undefined
state and edit-permissions would get lost for a part of content. The
inheritence is handled upon saving to save a lot of hazzle when actually
querying the system for the permission. The idea is, that you wont have
that many save events, but a lot more request events. "Does the user
have permission to edit this article, then show the edit icon" is going
to occur a lot more often than "Save these new permissions".

The new proposal by Andrew
Andrew bases his proposal also on phpGACL, but he wants to leave out the
whole asset table system and instead put all the necessary information
for that specific asset in a multi-dimensional array, JSON encode it and
then store it in the table of the respective component. This has the
benefit, that you don't need another database query to get all access
permissions for an object, which means a pretty big performance gain.
(The system with the assetgroups would stay the same as described in the
previous system.) The downside of this would be, that its more
complicated for a developer to implement. They need to change their
table structure and they need to pay attention to a few details,
especially to inheritence. At this moment, there is nothing that would
create that automatic inheritence as described before. A change to the
access rights to a category would not ripple through the system and
change the permissions on other stages. Last but not least, the probably
biggest problem is, that you can't query the system for example for all
articles that you have edit permissions for. You would have to load each
article, decode the JSON string and see if you are allowed.

The Hannes proposal, which is based on Andrews proposal
(I know, its getting complicated with the names, but bear with me)
I deem the inheritence to be a very important feature, which is why I
proposed to take Andrews approach, but instead of storing the JSON
string in for example the article table, I would store it in its own
table with a nested sets model and a seperate field to store the
difference between the permissions of the current object and the parent.
That way you could have a system very similar to NTFS permissions. The
pros and cons are similar to Andrews proposal except for the inheritence.

The Amy proposal
Amy wants to go a slightly different route. She has a usergroups table,
an action table and an asset table, which are connected via a rules
table. For each combination of usergroup, action and asset, she has one
row in that rules table. You can query that system easily for single
permissions and you can query it also for one action on a whole bunch of
assets at a time. However, if you want to get only those rows from a
table that you have permissions to, you have to add a JOIN into that
query and you have to add a WHERE clause. Caching those results like it
is done with the assetgroups in the three previous proposals is not
possible. The additional join, especially to such a huge table like this
one (remember, 5 groups which should have access to 5.000 articles with
5 actions, could in worst case mean 125.000 rows in that table), is
going to cost performance. The question is: How much? Thats something
that I don't know. Inheritence would be possible with a little bit
additional work. In the end, this solution is less work for the third
party developer to save new permission into than in Andrews proposal,
but it requires more elbow grease to query that system than in the
previous three systems.

Now lets talk a bit about the UI:

While talking to Amy, she made one point about the UI, which has effect
on the system, too, which is the view permissions. In the systems
proposed by me and Andrew, the viewing of an object is seperate from all
the other permissions and it needs special handling. In her opinion
thats a major downside, because it is not intuitive. I would disagree
here, because in my general idea, I have some stupid editors (pardon the
word) which I want them to be able to set the viewing permissions, but
not any other ACL permission. If I unify the UI for all those actions, I
force the editor to learn yet another UI-element in the edit window,
instead of having just one drop down list of pre-defined viewing
permissions.

Still, somehow you've got to set the permissions. At the moment, you can
already see the basics to set permissions in the user manager. In the
user manager you can create users, usergroups, access levels, attach
usergroups to those access levels and set system permissions on groups,
like "manage com_content". In my opinion on this, all other permissions
"basic" permissions (permissions that consist only of usergroup and
action, no asset), should be controlled in a modal window similar to the
window that you get when you click on "Parameters" in the article
manager in 1.5. There you can set all permissions for all groups at once
without a page reload. All asset related permissions (in case of an
article: edit, delete, publish, etc.) should be controlled in a little
widget in the edit window of the asset. But only if you are allowed to
edit permissions, otherwise its inheriting the permissions from its parent.

What I definitely want to prevent is having the word or concept of
"rules" showing up anywhere in the UI. My main concern is, that a list
of rules does not show what actually is possible. If I have a bunch of
checked and unchecked checkboxes, I can see "okay, this is currently
enabled for this group and this isn't", but with a bunch of lines in a
table representing rules, I can't see right away that this special rule
is missing.

Now we need to find the best possible solution from this or come up with
something completely new and revolutionary.

Hannes

Amy Stephen schrieb:

> I hope you've found my comments and ideas helpful. That was my intention.
>
> Thanks!
>
> On Fri, Sep 11, 2009 at 5:17 PM, Andrew Eddie <mamb...@gmail.com
> <mailto:mamb...@gmail.com>> wrote:
>
>
> Hi Amy
>
> A "super matrix" of some hitherto unknown description will be
> required. There are a number of ways to do it but I think that
> happens after "right, all the setting of permissions work nicely -
> what tools do we need to make complex systems easier to
> manage/debug/etc". It's possible a number of different flavours will
> be required - dunno yet - will have to wait and see.
>
> Regards,
> Andrew Eddie
> http://www.theartofjoomla.com - the art of becoming a Joomla developer
>
>
>
>
> 2009/9/12 Amy Stephen <amyst...@gmail.com

> <mailto:amyst...@gmail.com>>:

> >
> > One more thing, Andrew, as a point of clarification - I am *not* in
> > favor of *only* doing all permissioning in one place. It should be
> > done - as you are - within the context of the content, too. And, I
> > agree, for some people, that's all they will be able to access. Not
> > missing that point. But, if we possibly can bring it all
> together as a
> > unified picture - that would be very nice. Very nice.
> >
> > Thanks, again!
> > Amy
> >
> > On Sep 11, 4:54 pm, Andrew Eddie <mambob...@gmail.com

> <mailto:amystep...@gmail.com>>:

[Andrew Eddie]

Hi Hannes.

Would it be possible to change your first use case to include only
core components? If you can cover them it will most likely cover
3PD's but I think keeping it limited what is distributed is more
helping to the current discussion.

Just a suggestion.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/12 Hannes Papenberg <hack...@googlemail.com>:

[geeffland]

Andrew,

On your earlier comment about view permissions and them not changing
much... does that imply that View access will still be limited to
"Public", "Registered", "Special" ? ( I hope not )

Greg

[Amy Stephen]

Very good summary and overview, that helps a lot, Hannes, thank you. And thank you, also, for listening and explaining. You have a rare combination of great people and technical skill.

Just to be clear, my data model was only for my use to help me understand what the application is doing. The phpGACL data structures are built on a solid data model. Sure, it could be simplified and customized for our needs and, Hannes, that might have been better. But overall, it's a good model and it is not the cause for any issues I see.



A good approach to working with performance data is making certain to always continue to maintain normalized data structures. Performance data is not a substitute for primary data, it's best treated like an advanced form of cache. Then, you can build processes to repopulate performance data if there are problems, data imports are simplified, but mainly, preserving 3NF data structures keeps relational benefits in place.

In this case, that means the application could portray the full picture of Group authorization, a task not possible now.

Hannes - unifying the Group ACL information is not for the Editor, it's for the Access Control Manager to organize Group definitions. It's for the Web site Administrator who can't figure out why someone can't see the President's blog. It's for the external accountant who is performing an annual audit, it's for sharing with the department manager who needs to understand what people in the area can see. Maintaining permissions is primary, of course, but the system must also be able to display what permissions it has in place.

Again, if the application populates relational tables and augments with performance data, then things are good, again.

Yes, the downside to maintaining source and performance data is that the system has to make certain to manage both data stores, but isolating those processes to the API should reduce that risk. There is also a performance hit on updates, and a bit more physical storage, but if we can't afford those costs, then we can't afford the performance data, IMO, and should drop back to relational data stores which is primary.



Since you are just starting to lay the code in the Components for Asset access, it would be great if the "Access Level" performance data were tucked away from view and automatically created by the application. That would do wonders to the UI by removing that extra Access Level layer of Interface complication and still provide for that very cool query technique.

Would this work in the Component:

1. For Access Level options, display the Group Names.
2. The User would then select a Group, one at a time, and specify Asset Permissions using that Select List and checkbox XML approach you described.
3. Then, when the User saves the form, the application would create (or update), the Access Level data and associate it with the Asset.
4. When the Asset page is reloaded - the Access Level data associated with the Asset would be used to set the selected Group values, and the Group List would continue to serve as available choices.


If you could tweak what you have in place to do these two things:
1. Populate the relational data store in it's entirety.
2. Hide that Access level in the application code.

Would that work? If so, then you would have that fast View query trick, remove an awkward step in the User Interface, and be in a position to provide the complete access control picture for groups.

Thanks again for listening and welcoming community. Really appreciate it.
Amy

[elin]

@Andrew

I want to explain a little more about the issue I see for
uncategorized articles.

Right now in the sample data we have an actual row in the categories
table for a category called "uncategorized weblinks." On the other
hand in com_content core you are given the option "no category" and
that saves with a 0 in the category field of the content table which
puts it in Root in the categories table with no component assigned
(system in the component field). In other words, Root is serving as an
actual category. These two different approaches to "uncategorized"
data have different implications for ACL among many other things. You
can't use the category manager to assign rights to that clump of
articles if there is no reference component (see my other thread on
the usefulness of a full category manager). So on our list for
com_content we need to either say that access will only be as you
said, only for people with access to all articles, per item or that
we're going to have access to that clump of content in some other way
than using categories directly. This seems to me like a lot of work
for minimal benefit. I also think it does not make sense to say that
uncategorized articles do not have a component.

I think there is an argument for parsimony that says make
uncategorized articles a category in the category table then all the
compents and content in the components are treated the same
(com_content being the only one with this possibility at the moment)
and we don't have to make a separate way of handling them. Well that
and remove
<option value="0">JOption_No_Category</option>
from the article form XML and assign all the sample data content to
categories (including one called uncategorized content if we want) and
then we're set. (There is also an issue in weblinks xml but i think
that is probably just an error.)



Right now in the core sql all we have is
(1, 0, 0, 17, 0, '', 'system', 'ROOT', 'root', '', 1, 0, '0000-00-00
00:00:00', 1, '{}', '', '', '', 0, '2009-06-22 20:25:13', 0,
'0000-00-00 00:00:00', 0, '');

But I think it would make sense (if only for UI reasons) to have a row
for each for front facting core component. The UI benefit being
(besides those listed above) that a brand new user who doesn't install
sample data can just make a contact or weblink without having to
create a category first. A tremendous number of sites only have one
contact and forcing them to make a category adds a bunch clicks.

Sorry if it seems like category handling is off topic, but it
occurred to me while looking at your matrix that categories are
central to ACL.


Elin

[Andrew Eddie]

Hi Greg.

I was referring to not changing what is already built, which is the
ability to add new access levels. I demonstrate a lot of the in-situ
1.6 code here:

http://www.theartofjoomla.com/home/5-commentary/77-lifting-the-lid-on-joomla-16.html

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/9/13 geeffland <gr...@effland.org>:

[Hannes Papenberg]

Hello folks,
a few days ago we had another meeting and we finally made some decisions
on the ACL topic. This is what we came up with.

Also a few days ago, I described the four different proposals that were
made in the last weeks and months on how to handle the asset management
part of ACL in 1.6. Each of the proposals had its strength and
weaknesses, which is why it was really hard to make a decision here.
Specifically we had to decide between speed, functionality, inheritance,
strength of the data integrity and usability for the third party
developers. (The userinterface is not in that equation, because the UI
is practically independent of the underlying system.) The different
approaches were the "original" phpGACL approach (problems with data
integrity, speed and usability for third party developers), Amys
proposal with one row per access tupel (just huge masses of data,
missing implicit inheritance and lacking usability for third party
developers), Andrews approach with saving the information inside each
assets own table (not flexible enough for later versions) and last but
not least the now chosen approach.

In the end we decided on storing all access informations for an asset (=
a content object like a category, weblink or article) in a
multi-dimensional array, encode that to a JSON string and store it in a
central assets table. This will allow you to retrieve all necessary
informations in one query, so its among the fastest solutions there is.
By storing these JSON strings in a seperate table, we are also able to
implement an implicit inheritance. For example an article will inherit
the settings from its category, which again inherits them from its
parent category and so on. This also gives us a lot of room in later
versions for big improvements when tackling com_content in 1.7.

How can a third party developer implement the improved ACL asset
management in his extension? If its just about the viewing permissions,
its about three lines of code that have to be changed. If you want to
add additional control over who can create, edit and delete content (on
a per category/content level) you will have to add an additional field
to your tables and change a little bit more code. All together, with
some elbow grease, it should even be possible to have extensions that
are compatible both with 1.5 and 1.6 in terms of ACL. However they have
to be 1.5 native to begin with. In the end, the transition for the third
party developers should be pretty easy. Extensive HowTos will come with
the release of 1.6.

We still have some areas to work out, for example on the userinterface,
and of course a lot more stuff to code, but we made a huge leap towards
1.6 with these decisions and I am very confident that development will
be fast now that we have the uncertain things figured out. Stay tuned
for more updates on this.

Hannes



Andrew Eddie schrieb: