ACL UI Ideas

[Amy Stephen]

I assume this is how ACL will work (right now, I can't create a new
group.)

- Create a new "Human Resources" group created with "Publisher"
authority.
- Add Users to that Group in the User Manager for each User (in the
Assigned Groups section).
- Create an Article Category and assign the "Human Resources" Group to
that Category.
- Then, all "Human Resources" users can publish Articles to that
Category.

If that is all correct, then life is very good. Perfect.

++++

I also assume "Manager and above" enables that User full Content
Access in Frontend? If so, good.

++++

UI suggestions:

1. Default ACL (or System-wide Permissions)

It appears to me that users need to still have a default ACL option
(Public-thru-Super Admin). It might just be registered but system-
wide, every user still needs a blanket option.

If that's true, I recommend continuing with the existing UI listbox
option that enables one, and only one choice for this setting. A
checkbox option is probably not a good UI choice since it wouldn't
make sense that some could have both a system-wide "Editor" and
"Publisher" permissions.

I would call that setting "Default ACL" or "System-wide Permissions"
to "Default Site-Wide Permission" to show this setting to be a) site-
wide and b) the default setting if nothing else is specified.

2. Custom ACL (or Custom Permissions or Group Permissions or Site
Permissions)

For the additional ACL options, I recommend using a double-listbox
(select an option on left and press "select" to move it to the right;
select an option on the right and press "remove" to move it from the
selected list)

Or a single Listbox to select the Group, press "Assign", and an
assigned list of groups. To remove, press the "x" on an item in the
selected list.

http://www.ryancramer.com/projects/asmselect/examples/example1.html

I cannot find these UI objects at http://jxlib.org/ or http://mochaui.com/demo/
that are Mootools related, I'll try to look later.

[g s]

Is an user supposed to be part of more than one group ?
If yes, is there any cross group's policy consistency check in
procedure, before moving user group/rites ?

regards

Gabriele Sabadini

------

The information contained in this message as well as the attached
file(s) is confidential and is only intended for the person to whom it
is addressed (675/96 - D.lgs 196/03 - Direttiva 2002/58/CE)

This message has been processed against viruses.

[Amy Stephen]

Yes, from what I understand, a User can indeed be in more than one "site defined" Groups.

What is a "cross group policy consistency check?"

There are plugin events that can be used to customize the ACL for organizational needs.

[g s]

>What is a "cross group policy consistency check?"

permission override checks

Gabriele Sabadini

------

The information contained in this message as well as the attached
file(s) is confidential and is only intended for the person to whom it
is addressed (675/96 - D.lgs 196/03 - Direttiva 2002/58/CE)

This message has been processed against viruses.

[Amy Stephen]

I'm afraid that still doesn't mean anything to me. Again, though, we can customize the ACL using triggers, so if workflow needs to take place, or if the changes must be validated in some manner, that logic can be added using triggers.

[Ian MacLennan]

I think what he was referring to was cascade rules.

i.e. do permissions get more restrictive or less restrictive?  i.e. if one group is specifically allowed to do something and another group is specifically not allowed (if you can define that).  What happens?

Ian

[Amy Stephen]

Thanks Ian. That is a good question.

If I understand correctly, the ACL is a permission-granting system. Meaning, there isn't a mechanism (or need) to restrict someone, except by not granting permission.

So, if two groups are authorized to publish to a specific category, then both groups presumably have business need to do so. If any individual is removed from one group, he/she would continue to have business need if they continue as a member of another group.

Now, someone could add a trigger that did something (sent an alert or removed another group membership) if group access was removed - and business rules called for the removal of other access. I think that's beyond what core should attempt, though, since it starts to get into

That's the same type of confirmation I am asking for with my questions and a need to be clear about the system-wide setting per user.

• If someone is defined as a "Publisher" in their default system settings, then I believe they would be "Publisher" of all. It would make little difference adding them to additional groups (assuming only core components, of course).
• If someone is "Registered", then Groups would be required to provide specific permission to publish for a certain Category (or Menu Item or Component, whatever).

I hope this is the way it works. I like permission-based ACL. It's simple and I think a natural way of looking at content. I think adding Restrictions would complicate matters without adding value. And, triggers can be used to kick off organizational business rules that will vary greatly. Maybe in time, we'll see patterns there that can be added as workflow.

Maybe I am completely wrong on this, though. Hannes?

[g s]

Yes i was talking about what is called "consistency"
meaning that one rule is not breaking another one, if it is not supposed to

Gabriele Sabadini

------

The information contained in this message as well as the attached
file(s) is confidential and is only intended for the person to whom it
is addressed (675/96 - D.lgs 196/03 - Direttiva 2002/58/CE)

This message has been processed against viruses.

[Amy Stephen]

Gabriele -

It appears to be a very simple system of creating groups, assigning users to groups, and then granting the group with permissions for specific content.

In that type of system, a user would be granted permission to do something because they have membership in a group or because of their system wide default enabled the permission.

People could make a mistakes by assigning people to the wrong group or empowering groups with incorrect permissions, but to me, that's a user error, rather than a system design issue.

I might be missing something but I can't see how this very simple approach could create a situation of inconsistency. Do you have an example of how this could happen? It might be helpful to consider a scenario.

Thanks,
Amy

[G. D. Speer]

I think what she is driving at is that more complex ACL systems have both addative and subtractive permission systems when it comes to inheritance.  My understanding of the 1.6 system is that it is addative only.

If any of a user's group memberships grant edit permission for process Y, then the user has the edit permission

regardless of more limited restrictions imposed on members of other groups that user is also a part of.

If permissions are always additive, you don't have to deal with conflicts.

 

I think the issue that is being anticipated is for the enhanced publishing workflow where a user may be both an author and an editor and the intention is that the author group be setup so that an author cannot self-edit.  The question is whether the self-editing restriction is being accomplished by the author group having a subtractive permission concerning editing when working in a category that they author in, or whether it's done at the article level with AuthorID mismatch filtering.  I expect something like the later, which is no issue.  Having not looked at the code, I have no idea other than anecdotally how 1.6 is actually doing this and therefore whether Gabriele is raising a relevant issue.

 

 

---

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.87/2195 - Release Date: 06/22/09 06:54:00

[g s]

defining consistency of users permissions on role based system is
always done - as it's more than a software pattern, it's a logic
procedure - so i'm sure that there is a document (pdf, hand written or
only present in the mind of some core developers) that specify how the
system works on managing cross group permissions.
such a document would describe what happens in case of permission
raisings/excaling and group conflicts.

@Amy

just think about a VERY simple scenario that can take place using
core-only joomla components

a website which reports news.
A group takes care of SPORT and WORLDWIDE NEWS. A group owns all perms
upon these categories/tags [1]
B group takes care of EVENTS and LOCAL NEWS. B group owns all perms
upon these categories/tags [1]
MARK is an "editor" member of A. He is moved to B.

What happens to the article he's written in SPORT ? Can he edit them ?
Or does he need to be part of a C group who owns A and B permissions ?
Does the core "Editor" works for all the categories, so an editor is
not really limited to a category ?




@Speer Thanks for appreciation
Author/Editor/Publisher seems to a be a matter of role.
Related to content versioning improvements
(http://community.joomla.org/blogs/community/844-version-control-main-features-and-modifications.html),
i suppose that only editor can take advantage of this kind of feature.

[1] i speak about tags as taxonomy is improving too
http://community.joomla.org/blogs/community/919-taxonomy-library-implementation.html



my best regards!

Gabriele Sabadini

------

The information contained in this message as well as the attached
file(s) is confidential and is only intended for the person to whom it
is addressed (675/96 - D.lgs 196/03 - Direttiva 2002/58/CE)

This message has been processed against viruses.

[Amy Stephen]

On Mon, Jun 22, 2009 at 4:37 PM, g s <gabriele...@gmail.com> wrote:

defining consistency of users permissions on role based system is
always done - as it's more than a software pattern, it's a logic
procedure - so i'm sure that there is a document (pdf, hand written or
only present in the mind of some core developers) that specify how the
system works on managing cross group permissions.
such a document would describe what happens in case of permission
raisings/excaling and group conflicts.

@Amy

just think about a VERY simple scenario that can take place using
core-only joomla components

a website which reports news.
A group takes care of SPORT and WORLDWIDE NEWS. A group owns all perms
upon these categories/tags [1]
B group takes care of EVENTS and LOCAL NEWS. B group owns all perms
upon these categories/tags [1]
MARK is an "editor" member of A. He is moved to B.

What happens to the article he's written in SPORT ? Can he edit them ? 

Or does he need to be part of a C group who owns A and B permissions ?

To me that is not a Group conflict. It is, however, a good question as to author permissions with this new ACL.

I hope it works like this:

When "Mark" is removed from Group A, those Group permissions are gone. When he is authorized for B, he shas Group B's permissions.

He continues to have authority to update articles for which his User ID is present in the Author ID column.

If the organization doesn't want that authority to continue, the User ID value in the Author ID column must be changed to indicate the Author does not have authority to update his work.

This does not prevent the ability to credit an author for their work since the real Author's name can still be provided in the Author Alias and printed with the work.

Does the core "Editor" works for all the categories, so an editor is
not really limited to a category ?

That is one of my questions:

I hope that we are able to continue to set the default ACL for each user. Those who do not require anything more sophisticated than what Joomla! does now can continue doing what they do now - and give each user one ACL setting which works site wide, as it does now.

That also means those who want to use group-specific access must be mindful of default settings. In many cases, users would initially be defined as "registered" users who can then create/edit/publish content based solely on group permissions.

But, that's my assumption and the question I am also asking for confirmation on.

I agree with your previous post explaining how an "additive" permissions system should prevent conflicts. I still can't think of any "group" conflicts that might occur. Glad you raised the issue of the Author, that's another good confirmation to have.