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=TrackerItemEd... 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.
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).
> 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=TrackerItemEd... > 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.
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.
> 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).
> 2009/9/5 Hannes Papenberg <hackwa...@googlemail.com>:
>> 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=TrackerItemEd... >> 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.
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.
> 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:
>> 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).
>> 2009/9/5 Hannes Papenberg <hackwa...@googlemail.com>:
>>> 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
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.
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.
> 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<mambob...@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).
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
On Sep 4, 8:36 pm, Sam Moffatt <pasa...@gmail.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<mambob...@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).
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:
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.
> 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
> On Sep 4, 8:36 pm, Sam Moffatt <pasa...@gmail.com> wrote:
>> Hi all,
>> > 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<mambob...@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).
On Sat, Sep 5, 2009 at 12:03 PM, Amy Stephen<amystep...@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*.
* 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.
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.
On Sat, Sep 5, 2009 at 12:51 AM, Sam Moffatt <pasa...@gmail.com> wrote:
> On Sat, Sep 5, 2009 at 12:03 PM, Amy Stephen<amystep...@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*.
> * 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.
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 (Isnt 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.)
§ *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
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 its 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
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)
> 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.
> On Sat, Sep 5, 2009 at 12:51 AM, Sam Moffatt <pasa...@gmail.com
> <mailto:pasa...@gmail.com>> wrote:
> On Sat, Sep 5, 2009 at 12:03 PM, Amy Stephen<amystep...@gmail.com
> <mailto:amystep...@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*.
> * 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.
On Sat, Sep 5, 2009 at 7:39 PM, Amy Stephen<amystep...@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.
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. ;-)
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.
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:
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").
> 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. ;-)
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<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.
> 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).
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.
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
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.
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.
> 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
> 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.
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.
On Sat, Sep 5, 2009 at 8:01 PM, Andrew Eddie <mambob...@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.
> > 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
