menu item access control

[Richard]

The entity I work for has me working on modifying Joomla to add finer grained access control for menu items. Currently, the permissions for editing menu items is either all or none. This is unlike the permissions for articles which can allow for editing only some of the articles. A look at the code explains why.

 

//com_content - Articles

$canCreate = $user->authorise('core.create', 'com_content.category.'.$item->catid);
$canEdit = $user->authorise('core.edit', 'com_content.article.'.$item->id);
$canCheckin = $user->authorise('core.manage', 'com_checkin') || $item->checked_out == $userId || $item->checked_out == 0;
$canEditOwn = $user->authorise('core.edit.own',    'com_content.article.'.$item->id) && $item->created_by == $userId;
$canChange = $user->authorise('core.edit.state', 'com_content.article.'.$item->id) && $canCheckin;

//com_menus - Menu Items

$canCreate = $user->authorise('core.create', 'com_menus');
$canEdit = $user->authorise('core.edit', 'com_menus');
$canCheckin = $user->authorise('core.manage', 'com_checkin') || $item->checked_out==$user->get('id')|| $item->checked_out==0;
$canChange = $user->authorise('core.edit.state', 'com_menus') && $canCheckin;

For the articles, the "core.edit" request includes the id number of the article. For the menu items, the "core.edit" request is always "com_menus". There is no way to grant access based on a particular menu item. Does anyone know if implementing this will be possible as an extension? Is this something that is already planned for a future version of Joomla?

[elin]

Menu items (like modules and menus themselves) are not assets in the current acl implementation and therefore are not in the asset table and do not and cannot have permissions associated with them.  It is just not something that makes sense architecturally in 2.5 although as a practical matter I know exactly why you want to do this.  I can think of some hacky ways to work around that but  it may be that you need to really override most of com_menus e.g. to add an asset column to the menu table. 

Elin

[Stephen Brandon]

Until Joomla has full ACL access for menu items, my approach to the menu item question is to use Chameleon (metamodpro.com) to selectively disable menu items according to whatever sorts of conditions I need to use. So if a certain user group is not allowed to see certain menu items, I can select that group as the "condition", then as the "action" make a selection of menu items that I want to disable.

For your purposes I guess it would be nicer if the interface for this was within the menu item editing screen, but the Chameleon route also allows you to combine the rule with other criteria if you need that. And no core hacks.

I agree that having full ACL on manu items would be great - I'm just suggesting a current feasible approach that could save a lot of hacking.

Best regards,

Stephen

metamodpro.com

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/-pdbYG4lDYEJ.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Richard]

I'm done.

https://github.com/joomla/joomla-cms/pull/210

[Richard]

Forgot to add a file. Here's a second attempt.

https://github.com/joomla/joomla-cms/pull/212

On Wednesday, May 9, 2012 9:58:49 AM UTC-5, Richard wrote:

[Richard]

Now that I've pretty much finished the menu manager ACL, another problem I have to address is users being able to assign modules to menu items they shouldn't be able to. For example, a novice user could publish a broken module on the front page, taking down the entire site, when they only need access to publish modules on a small subsection.

I am thinking of basically tying the module permissions to the menu item permissions so that if they can edit the menu item, they can also assign a module to it. Does that sound like the right way to go?

[Mark Dexter]

Interesting question. Off the top of my head it's not obvious to me
that the menu item's permissions should control assigning a module to
the menu item. I guess we need to decide whether a module's assignment
to a menu item requires edit permission for the menu item, for the
module, or for both. How does it work right now? Do you need component
level permissions for both modules and menu items to assign modules to
menu items? It might make sense to follow the same logic we do now,
except to extend it to the individual menu item and module.

My .02. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/mqfJUFQiTXoJ.

[Richard]

As of 2.5.4, you only need component level access to com_modules to assign a module to any menu item(s).

[Mark Dexter]

In that case, unless we can think of a compelling reason to change
this, I would continue the same behavior and control the assignment of
modules to menu items via the module manager, not the menu item
manager. In my opinion, it is somewhat arbitrary, but I see no reason
to change at this point. In 1.5, you could only assign modules to menu
items in module manager, so I think this point of view makes sense
from an historical perspective. It is probably overkill to control it
both ways.

Again, this is just my opinion. Mark

On Thu, May 24, 2012 at 12:33 PM, Richard <rm0...@uah.edu> wrote:
> As of 2.5.4, you only need component level access to com_modules to assign a
> module to any menu item(s).
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/8W8Ok0ubje4J.

[Richard]

Oh, I'm not suggesting that we change where the admin goes in the backend GUI to assign a module to various menu items. Rather that the permissions for assigning a module to a menu item be based off the menu item edit permissions.

[Richard]

Just to clarify, for example, if you didn't have permission to edit the home menu item then you wouldn't be able to assign a module to it. My rationale is that assigning a module to a menu item can change the content when visiting that menu item which is similar to editing the menu item itself.

[Mark Dexter]

Hi Richard. I think I understand your question, and I tried my best to
give you my opinion and my rationale for it. If we currently base the
ability to assign modules to menu items on the com_modules permissions
(and not com_menus), in my opinion we should continue this as we build
out the ACL to the next level of detail. As I said earlier, you can
look at assigning modules to menu items either from the point of view
of changing the modules, changing the menu items, or both. To me, it
is arbitrary how we do it, but absent a good reason I would opt for
staying consistent with how we have been doing it. If at present we do
not require com_menus permissions to assign modules, I don't think we
should start requiring this now. Does that make sense? Thanks. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/PSyjNUoyiv4J.

[Richard]

What I am suggesting is consistent with how things currently are. The ability to edit a module or change its state (changing the title, position, publishing it, etc) should be based on com_module permissions. In addition, once you have permission to edit a module, you should also require permission to edit a menu item before being allowed to assign a module to it. You are right that you can look at assigning modules to menu items from both ways, the problem is, we need to secure them from both ways. You shouldn't be able to edit a module unless you have access to that module. You also shouldn't be allowed to assign that module to a menu item unless you have access to that menu item.

[Mark Dexter]

That could well make sense, but it sounds like a change from what we
have now. I thought you said that currently we don't check for
com_menus permissions before assigning modules to menu items. If that
is true, what you suggest, though logical, is a change from the
current 2.5 behavior. If so, that is not necessarily bad, but it just
requires more thought and discussion. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/tqynwlx33H4J.

[elin]

This is an example of how complex the whole thing gets when you start trying to do item level controls. We still don't really even have it 100% satisfactory for content, partly because we haven't really implemented the business rules plugin model that Andrew has discussed.
If we don't have that in the meantime I would say that if you have permission to do an action on a menu item you have all the rights that go with that currently, it's just that you are restricted to that particular item.  We can't overthink and successfully anticipate what every webmaster will want and it is a sure thing that they will want different things.

Elin

On Saturday, May 26, 2012 1:45:56 AM UTC-4, Mark Dexter wrote:

That could well make sense, but it sounds like a change from what we
have now. I thought you said that currently we don't check for
com_menus permissions before assigning modules to menu items. If that
is true, what you suggest, though logical, is a change from the
current 2.5 behavior. If so, that is not necessarily bad, but it just
requires more thought and discussion. Mark

On Fri, May 25, 2012 at 9:40 AM, Richard <rm0...@uah.edu> wrote:
> What I am suggesting is consistent with how things currently are. The
> ability to edit a module or change its state (changing the title, position,
> publishing it, etc) should be based on com_module permissions. In addition,
> once you have permission to edit a module, you should also require
> permission to edit a menu item before being allowed to assign a module to
> it. You are right that you can look at assigning modules to menu items from
> both ways, the problem is, we need to secure them from both ways. You
> shouldn't be able to edit a module unless you have access to that module.
> You also shouldn't be allowed to assign that module to a menu item unless
> you have access to that menu item.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-general/-/tqynwlx33H4J.

> To post to this group, send an email to joomla-dev-general@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-general+unsub...@googlegroups.com.

[mikida...@gmail.com]

Hi what xampp new version? Thanks mark
Sent from my AXIS Worry Free BlackBerry® smartphone

[Richard]

I'm adding a new feature. Things are going to be different. The real question is, does the new feature follow the pattern of previous analogous features where they exist?

[Mark Dexter]

OK, maybe we can discuss a specific use case to help focus things.
Let's say I have a type of user who is authorized to use the module
manager in 2.5 but is not authorized to use the Menu Item manager. At
present, if I understand correctly, this user can assign modules to
menu items, even though they cannot access Menu Item manager.

Again, if I understand correctly, we are proposing to change this so
that if I want to restrict this user to certain modules, they won't
necessarily be able to do what they did before -- which is to assign
these modules to menu items. Is that correct? If so, to me this seems
like a change in behavior from the current situation. It seems that we
should use the same rule at the item level that we use at the
component level. At the component level, we allow a user with modules
permission to assign modules to menu items, regardless of their
permission for Menu Item manager. So I think the expected behavior
would be to continue this at the item level and think of module
assignment as an attribute of the module, not the menu item.

Again, maybe I'm missing something, but that's how I'm thinking about it. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/WafpeHBhKB0J.

[Richard]

What about the expected behavior that if a user isn't allowed to edit a menu item, that user shouldn't be able to change the menu item content at all? Allowing a user to assign a module to a menu item can possibly change the content. For example, if a user publishes a broken module to the home menu item, they have effectively broken the front page, even if they had no access to modify the menu item at all. A malicious user could inject whatever they like using a custom HTML module to the front page without having access to edit that menu item or the article it points to. I don't think anyone would expect that.

[Mark Dexter]

We already have in 2.5 the behavior that edit permission in
com_modules allows you to assign modules to menu items, even if you
don't have any permission for com_menus (based on an earlier prior
post and based on a quick look at the code). That has evidently been
in place since 1.6.0 (January 2011). So to me the question is whether
this behavior is reasonable or not.

If we think it is reasonable, then the simplest and least risky course
in my opinion is to extend this behavior to the item level. If we
think the current behavior is not reasonable, then we should propose
changing it at both the item level and the component level. Having one
type of behavior at the component level and a different one at the
item level would seem to me to be very confusing.

So it sounds to me that you are proposing changing the component
behavior to require edit permission both to com_menus and to
com_modules before you can assign a module to a menu item. Is that
correct?

If so, we should state it as such and have a discussion about that
specific proposal as well as the proposal about the item level. Does
that make sense to you?

Thanks. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/9LSO6XIliNsJ.

[Richard]

It's always been two issues. This thread is about com_menus ACL. I haven't moved on to com_modules yet. The way com_modules works is by calling the com_menus MenusHelper class to generate a list of menu items to assign to. That's why it makes sense to talk about com_modules behavior in the content of com_menus ACL. I think we've already agreed that discussion is needed so I'd like to get straight to it.

Do you think that a user without access to a menu item should be allowed to assign a module to that menu item thereby changing the content? My opinion is no. If you disagree, let me know. Otherwise, if you have an alternative solution for preventing users from assigning modules to menu items they shouldn't, I'd be interested in hearing that too. I can't think of one that fits with the way Joomla is currently doing things.

[elin]

One is that remember that we assume pretty strict restriction to both menus and modules in the default acl because that is just like 1.5.  What adding item level acl does is allow webmasters to give more people  permission to edit menu items than is present by default because specific items can be opened up. 

However, this does not have to be the case, a webmaster can open those up to everyone in which case some specific items can be locked down. That is ACL can work either by granting or denying access and it's up to the webmaster to decide which  approach to take. Still webmasters should continue to understand that giving someone access to either the module manager or the menu manager or specific items therein is a major thing and quite different than giving access to articles or contacts.

One thing I would say is that web masters who decide to used advanced ACL do have to take responsibility for using it in a way that is rational and not self-contradictory.  It's very very hard to say what the actual expected behavior is ... expected by whom? I think different webmasters might disagree about what is expected in this case. 

Overall I have to say if you are giving someone edit, edit.state or create access to the module manager that has to be someone you trust to change (or not change) how your site looks.  If you don't trust them to do that you shouldn't give them that access.   

Elin

[Richard]

It's not just about trusting users. Even the most trustworthy person can make a mistake. Why should it be an all or nothing thing? The university I work for has about a dozen different colleges along with different groups such as facilities, student life, health & wellness, alumni, etc. Why does the student life group need to have the ability to take down an entire website by publishing a broken module to "all pages" when all they wanted/needed was to assign an accordion menu to one of their sub-pages? Why does the student life group even need to publish modules to the front page at all? It seems like the ideal solution would be to allow the student life group to only publish modules on their own menu items. That way, if they break something, it's just their section in the third level of the website, not the entire thing.

[Mark Dexter]

Hi Richard. I am a bit puzzled that we seem to be talking at cross
purposes here. Here is a simple use case. It would be great if you
could respond to it. The use case is this: I am using 2.5 and have a
group of users that have add and edit permission for com_modules but
do not have any permissions for com_menus. These users currently can
edit modules and assign them to menu items.

If I understand correctly, your proposal would do one of two things.
(a) Keep the present 2.5 component-level behavior but add item
behavior so a group would require edit permission for both modules and
menu items. (b) Change the current component-level behavior to require
edit permission for both modules and menus and add the same permission
at the item level. Is that correct? If so, which are you proposing?

If that is not correct, what am I missing? Thanks. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/zYVuVCdEbgsJ.

[Richard]

I don't think either (a) or (b) captures what I'm saying quite right.

To put it as plainly as I can, to edit a module, you require edit access to that module. To assign that module to a menu item, you *also* require edit access to the menu item.

The component-level permissions stay the same. Obviously, if you don't have access to the components, any menu item/module level access is irrelevant.

[Mark Dexter]

So you are proposing a change from the current behavior. At present,
we don't check com_menus permissions anywhere in the module manager.
So you can currently assign modules to menu items with only
com_modules permissions. You are proposing option (a), which is
keeping the current component level permissions as they are but
requiring at the item level an additional permission to com_menus. To
me this seems inconsistent, potentially confusing, and unnecessary.
That's just my .02. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/pKUPI0dya2kJ.

[Richard]

How is it inconsistent and what is it inconsistent with? The module/menu item relationship is unique so there's nothing else to compare it to. How is it confusing?

Unnecessary? If you think that then you must think that it's alright for a user to break the entire website simply by assigning modules. I'd be more inclined to agree with you if you could at least give me some alternative as I previously asked other than "if you can access modules, you can assign them anywhere and break the entire website". That's completely unacceptable. If you can't provide an alternative, I'll have no choice but to implement what I've suggested.

[Mark Dexter]

How is it inconsistent and what is it inconsistent with?

We already check permissions at the component level for users to be able to assign modules to menu items. In version 2.5, if a user has component level permissions for com_modules but not com_menus, they can assign modules to menu items. Your proposal would extend the component-level checks down to individual modules and menu items. To me, it would be inconsistent to have the item level permission checks be different from the component level checks (in this case requiring both menu item and module permissions to assign module to menu items). The component level checks only checks module permissions. The proposed item level checks would check module and menu item permissions.

Does that make sense? I'm not trying to be difficult or generate an argument here. I just want to make sure we are doing this in a way that makes sense and won't cause other issues. It is quite possible that I am missing something here or not explaining it as clearly as I could. I also want to emphasize that I think extending the permission checks in this way would be a good feature, so i don't want to discourage you or make it overly difficult.

Perhaps we should do a voice meeting if we can't sort it out on list? I am traveling for the next 2 days but them am home. Thanks. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/gkXsITx4wxYJ.

[elin]

I think if you have these complex concerns you need to use a plugin the way Andrew described.  Remember that many many sites perhaps the vast majority are really just working with a couple of people in the back end. 

Now I will say that I personally disagree with having the whole module edit layout display in the menu UI precisely because we are not testing the module permissions. But that was (yet another) argument that went the other way pre 1.6.  Still the assumption of the ACL models for menus and modules is that they would be restricted to people like admins and super admins, which is to say people who you trust. In extending the acl down to menu items and modules you are essentially opening up opportunities for groups you don't trust as much to make changes. Yes, this is complicated because you are basically giving access to the other manager.

What I would     suggest is that you have edit.state control completely the display of the module slider in the menu item UI. This means that those users with edit or create rights but without edit.state would be restricted to displaying those modules that display on all pages and I think that is fair enough given that we are giving access they did not have before.  Yes they won't be all powerful but they have a lot more and that's good.

Then I would suggest that edit state be used to restrict access to the menu assignments section in the menu manager. Again we are opening up module editing to new groups, it's true they won't be all powerful but they still have a lot more power than they did before.

The alternative is to add new custom actions (moduleassign) but we must remember that complexity increases geometrically so adding a new permission is like adding a new number in factorial (from say 6! to 7!) and that's way more possible combinations.

Elin

On Monday, May 28, 2012 4:06:41 AM UTC-4, Mark Dexter wrote:

How is it inconsistent and what is it inconsistent with?

We already check permissions at the component level for users to be able to assign modules to menu items. In version 2.5, if a user has component level permissions for com_modules but not com_menus, they can assign modules to menu items. Your proposal would extend the component-level checks down to individual modules and menu items. To me, it would be inconsistent to have the item level permission checks be different from the component level checks (in this case requiring both menu item and module permissions to assign module to menu items). The component level checks only checks module permissions. The proposed item level checks would check module and menu item permissions.

Does that make sense? I'm not trying to be difficult or generate an argument here. I just want to make sure we are doing this in a way that makes sense and won't cause other issues. It is quite possible that I am missing something here or not explaining it as clearly as I could. I also want to emphasize that I think extending the permission checks in this way would be a good feature, so i don't want to discourage you or make it overly difficult.

Perhaps we should do a voice meeting if we can't sort it out on list? I am traveling for the next 2 days but them am home. Thanks. Mark

On Sun, May 27, 2012 at 6:59 AM, Richard <rm0...@uah.edu> wrote:
> How is it inconsistent and what is it inconsistent with? The module/menu
> item relationship is unique so there's nothing else to compare it to. How is
> it confusing?
>
> Unnecessary? If you think that then you must think that it's alright for a
> user to break the entire website simply by assigning modules. I'd be more
> inclined to agree with you if you could at least give me some alternative as
> I previously asked other than "if you can access modules, you can assign
> them anywhere and break the entire website". That's completely unacceptable.
> If you can't provide an alternative, I'll have no choice but to implement
> what I've suggested.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-general/-/gkXsITx4wxYJ.

> To post to this group, send an email to joomla-dev-general@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-general+unsub...@googlegroups.com.

[Jim Fisher]

Hi Mark,

First, thanks a lot for having this discussion with Richard we have a lot to learn about Joomla and we are trying our best to contribute back to the open source community with this feature.

I'm Richard's manager on this project and we want to make sure we approaching this problem correctly.

Now Richard was kind enough to share with me this discussion and let me see if I can clarify things enough to allow the discussion to go forward in a way that is productive and beneficial to everyone.

Let me give you a little background, we use Joomla at the university here. I have well over 100 users and growing with all sorts of various level of access. They all have "subsites" (sections of the site usually denoted by a new menu set) and some users have access to modules and menus. For every subsite, I tend to have 1 to 2 users that have access to menu's so that they can build out or change their menu items and modules so that they can set up news and event section. This has lead to some issues, because they also have access to edit menus and modules of sites that don't belong to them. "Admissions" can edit "student life" and the frontpage menus. This isn't a good situation to have, even among a small set of trusted users, because in an organziation of our size, keeping that set small is difficult and even with all the training in the world mistakes happen.

Now to correct this, I thought, let's make it to where only a specific group will have access to a menu set, or even individual menu items (in case we have a subsite inside of a subsite). So Richard threw together what he submitted earlier.

Now, the second issue we had is that users would go into there modules (these are the same users that have access to menu items) and would then begin to assign a new (sometimes broken) module to "All pages", this isn't a good situation either. So we brainstormed and thought, if we only allow the list of menu sets that a given group has access too to to show up, that they couldn't break the whole website, but rather just their allowed portions (mitigate the damage). 

I thought this was a reasonable compromise and solves our two major access concerns with Joomla at this time.

I told Richard to get on the forum and get more information from the community at large, cause obviously our edits are major to the way Joomla menu's and modules currently function. We would love for it to be a core feature as it would only add value to the two separate components. Obviously we understand that different people have different needs, but that shouldn't preclude the features being available to those who need them, even if the defaults for the feature mimic the current behavior.

If you feel a voice conversation would help to clarify further we are open too it. We only seek to give back to the larger community. 

I would encourage everyone with an interest to review Richard's code and give us feedback as to what needs improvement or whether we are going in the right direction. I believe coding is just as important as talking, if we can produce the code then everyone has something to scrutinize and improve. Richards code is still very young, and their will be a lot of work to do to get it to the point of being used in production, I'm sure, but we are taking these steps to secure our site further and hope that everyone else will see the value in doing so in their own joomla sites.

Thanks again for the help in guiding us in the right direction Mark.

[Mark Dexter]

First of all, sorry about the long delay in responding.

I think you make a very good case for changing the way we have
traditionally viewed the assignment of modules to menu items. In 1.5
(and maybe before), the only UI for assigning modules to menu items
was in Module Manager. In 1.6, we added (almost as an afterthought) a
way to assign modules in Menu Manager:Edit Menu Item. But I think most
Joomla users are still accustomed to thinking about this task from the
module manager point of view, not the menu item point of view.

However, if we think about it, when we assign a module we don't really
change the module, we change the page or menu item. Thinking about it
that way, it seems to make more sense (at least to me) to require
core.edit permission on menu items in order to assign modules to a
menu item, along the lines that you have proposed.

As I think about the issue of assigning modules to All menu items,
things get a bit trickier. One possible approach would be to only
allow the "All" option if someone has core.edit permission for all
menu items. Otherwise, do not give this option to the user and only
show them the menu items to which they have core.edit permission.

Because this is a change from the current behavior, even if we decided
to do it, I wonder if it would make more sense to implement it for
version 3.0 instead of 2.5.

I'm interested to hear what others think about this. Thanks. Mark

> ...
>
> read more »

[elin]

I think that's very insightful. If we moved taking care of  page assignments to the menu manager that would eliminate a lot of clicks for people and also would really help with understanding the idea that you put a page together via the menus. 

This kind of reminds me of the two separate ways we have ACL for the media manager. One is for access to the full media manager and one is for access to the image button.  Basically there are two separate views for the media manager that look almost the same and yet are very different. The vast majority of users even back end users have all they need with the image button UI. 

I  strongly agree with the idea of restricting access to the "all", "all except" and "none" options.  As I said earlier, I'd really say restrict the choices in the menu item module assignment UI to: show on this menu item, don't show on this menu item and only give options for those modules that are not set to "all" or "none." This is really like assigning a template style. Just because you can assign a template style to a menu item does not mean you get to change the default template or unpublish a style.

That also makes me think that the all/all except/none settings are really configuration-like and should also be handled in the menu manager. Maybe we could have some kind of toolbar button for that or we could figure out a way to add it to the menu configuration options (maybe a modules field like the rules field). it's really just a list of all of the module instances and then a field or clickable icon for changing their setting.

Elin

[Richard]

Mark,

Thanks for the reply. Regarding the "All Pages" menu item assignment, that is one detail that Jim and I have talked about in our meetings. It definitely needs some thought. One issue would be, if a superuser assigns a module to all pages, what should a regular user with edit access be able to do?

[Mark Dexter]

This does get a bit sticky. From a user point of view, I would guess that we need to continue to support the concept of assigning modules to All menu items. It is very handy. However, having that option does seem to argue against making the module assignment action an attribute of the menu item. It rather argues for maintaining the status quo of having the module assignment be an attribute of the module (as it currently is).

I guess another possibility would be to create a new action for modules called core.assign. That way you could have users who can edit a module without being able to assign it to menu items. If you had users who should be able to assign modules to some menu items and not others, I guess you could have a group of modules for each group of menu items and set the core.assign permission for the different groups.

Mark

On Wed, Jun 13, 2012 at 2:25 PM, Richard <rm0...@uah.edu> wrote:

Mark,

Thanks for the reply. Regarding the "All Pages" menu item assignment, that is one detail that Jim and I have talked about in our meetings. It definitely needs some thought. One issue would be, if a superuser assigns a module to all pages, what should a regular user with edit access be able to do?

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/u8xaRUkJXRgJ.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

[Richard]

From my review of the code, the "all pages" feature looks to be just a bit of client side script that checks all the boxes. That would still work but it would be more like "all pages that I have access to" and only for super users or users with universal access would it really be "all pages".

[Mark Dexter]

I haven't looked at the code, but I am pretty sure this is deeper than just checking all the boxes. Specifically, assigning a module to All menu items has two very important implications for the web admin: (1) any menu item added later will also show this module; (2) when a page is displayed that does not correspond to an existing menu item (for example, an article with no article or category menu item), the module will also show on that page.

This is one reason why we added the "All except" assignment option as well. With that, you can take advantage of the ALL method and still exclude certain menu items (for example, the Home page).

Mark

On Thu, Jun 14, 2012 at 8:17 AM, Richard <rm0...@uah.edu> wrote:

From my review of the code, the "all pages" feature looks to be just a bit of client side script that checks all the boxes. That would still work but it would be more like "all pages that I have access to" and only for super users or users with universal access would it really be "all pages".

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/rO9LYarhKO8J.

[Richard]

I see. Then wouldn't it make sense to only display the "all" options for super users that necessarily will have access to assign modules to any and all future items?

[Mark Dexter]

No, I think it does make sense to only show the ALL and ALL EXCEPT options to users with permission for ALL menu items. However,  the "super user" concept is a bit trickier than it might first appear. We do have super users, defined as any user with core.admin permissions. However, other users can also have full privileges for com_menus, so we can't really restrict it only to super users.

Unfortunately, the ACL as it currently stands is not great at finding all assets that a user has a given privilege for. In this case, I guess we could just loop through all of the menu items and test that a user has edit permission for them all. Then we would show the ALL and ALL EXCEPT options for super users and any user with edit permission for all menu items. As long as a site has a reasonable number of menu items, it shouldn't be too slow. 

So I think using the core.edit permission for menu items to determine whether a user can assign a module to a menu item makes sense.

Does anyone else have any opinion about this? It is a change from what we have now. 

Mark

On Thu, Jun 14, 2012 at 8:53 AM, Richard <rm0...@uah.edu> wrote:

I see. Then wouldn't it make sense to only display the "all" options for super users that necessarily will have access to assign modules to any and all future items?

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/G6gMb_D_YmQJ.

[elin]

There are two separate things.

There is basically a UI javascript feature that displays checks when ALL is selected but that has nothing at all to with anything in terms of how the module data is stored, it's just so the UI makes visual sense to the user. 

I feel strongly that if we are going to say that com_menu is the controlling component then we should only let those with admin rights for com_menus do all or none or all except.  

I think if you have access to edit the menu item you should only be allowed to change the non default display of modules for that specific menu item. That is you should be able to add a menu item to the list of selected or list of excluded for a specific module. 

Elin

On Thursday, June 14, 2012 2:22:25 PM UTC-4, Mark Dexter wrote:

No, I think it does make sense to only show the ALL and ALL EXCEPT options to users with permission for ALL menu items. However,  the "super user" concept is a bit trickier than it might first appear. We do have super users, defined as any user with core.admin permissions. However, other users can also have full privileges for com_menus, so we can't really restrict it only to super users.

Unfortunately, the ACL as it currently stands is not great at finding all assets that a user has a given privilege for. In this case, I guess we could just loop through all of the menu items and test that a user has edit permission for them all. Then we would show the ALL and ALL EXCEPT options for super users and any user with edit permission for all menu items. As long as a site has a reasonable number of menu items, it shouldn't be too slow. 

So I think using the core.edit permission for menu items to determine whether a user can assign a module to a menu item makes sense.

Does anyone else have any opinion about this? It is a change from what we have now. 

Mark

On Thu, Jun 14, 2012 at 8:53 AM, Richard <rm0...@uah.edu> wrote:

I see. Then wouldn't it make sense to only display the "all" options for super users that necessarily will have access to assign modules to any and all future items?

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/G6gMb_D_YmQJ.

To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-general+unsub...@googlegroups.com.

[Richard]

Another consideration is setting the home page. A user mistakenly set one of their pages as the front page (during lunch of course), which is little too easy to do by accident.

[subtextproductions]

I have to say that I am pretty disturbed by the path this discussion has taken. What is the purpose of the Joomla Platform? Is Joomla meant to be a tool that appeals to the technically incompetent? Are we all building blog sites for our Grannies with Joomla? Isn't that what WordPress is for? If a user is not educated enough to make the right decision, then it seems to me that is their burden to bear, and they should better learn to use the Joomla system.

Certainly we should attempt to create an interface that is clear and easy to use, but there is an awful lot of discussion regarding foolish decisions that might "break" a Joomla site. I simply don't think it is the best use of our resources to fret over whether or not someone cannot take the time to learn how to set the default page or to properly assign modules. We simply cannot control the mistakes that users make, and they will make many, many mistakes. But, mistakes are how one learns. The solution, to me, seems to involve educating the users as to how and why the system works the way it does, as opposed to fallaciously attempting to code some kind of solution that confuses no one. It is not possible. Set the default to "all pages", and someone will complain that it doesn't work for them. Set the default to "none" and another person will complain. It's kind of a no win situation.

[Keith Mountifield]

HI All,

 

Blog sites for grannies? Actually, in some respects that’s exactly what we do in a lot of sites that are
doing. I’ve just completed a Joomla site for a school. The teachers (there are about 10 or so) will have
access to their own section of the site. Some are fairly IT literate and comfortable learning the new
system, others are much more nervous about breaking the site and consequently won’t go clicking
buttons, but certainly they would come under the same skill classification as ‘Grannies’.

 

Joomla is a great blogging tool when other more powerful functionality is required in the same site.

 

I also think that these discussions are useful I guiding where contributors choose to put their
development efforts to help make the whole platform and CMS better.

 

On the default module assignment issue, I would suggest that the best way to handle it would be as an
additional parameter in the global config. That way us developers could choose the best assignment
for each project…

 

If the ability to assign the default page could easily be added to the site-wide ACL then that would also
make sense.

 

JMHO

 

Cheers

 

Keith

 

 

--

You received this message because you are subscribed to the Google Groups "Joomla! General
Development" group.
To view this discussion on the web, visit

https://groups.google.com/d/msg/joomla-dev-general/-
/vbT4dmkf2r4J.
To post to this group, send an email to joomla-de...@googlegroups.com.

To unsubscribe from this group, send email to

joomla-dev-
general+u...@googlegroups.com.

[Jim Fisher]

I Agree with Keith that a global configuration for this option could make sense. I don't think better usability should be something to steer clear from. If wordpress does usability better, then why can't Joomla? As for how developer resources are spent, I think that is up to the individual developer, in this case no one is asking any core devs to work on it. This is a request for guidance, which like Keith, I think is an important reason for having the conversation.

To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

--
Jim Fisher

UAHuntsville

I.t. Solutions

Web Services Coordinator

phone: (256) 824-6458

[subtextproductions]

I'm not suggesting that we steer clear from better usability. I think good usability is about striking a balance. I simply question if you are doing these "nervous" teachers a disservice by unintentionally feeding in to an environment of learned helplessness. I have the same kind of issues with my clients. Like your teachers, they are smart, educated people who sometimes just don't embrace new technology, or are "nervous" about making a mistake. I feel that stripping away layers of complexity can sometimes reduce usability or flexibility in the name of simplicity. Some times an overly simple interface allows the end user to eschew learning how to use the system at all.

I feel that the better an end user understands how the Joomla CMS works as a whole, the more they understand just how powerful the Joomla CMS is and how they can use it to shape their website dynamically over time. Sometimes they just need to be forced to learn it.

All that being said, I really like your solution. It preserves the balance of flexibility and usability and leaves the power in the hands of the developer which is exactly where I think it belongs.

[brian teeman]

There is clearly no single preferred option by the people replying here or a mass call for this behaviour (present since the beginning of joomla) to change - dont think I have heard anyone asking for this before in over 5 years (but I could be wrong)

I would be very against this being a configurable option as it would mean that the default expected behaviour woud not be the same on all sites and would create problems with documentation (both on joomla and extensions).

[Aaron Wood]

+1

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/e6fRFtHnFOEJ.

To post to this group, send an email to joomla-de...@googlegroups.com.

To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

[Keith Mountifield]

Hi Brian, and everyone,

 

 

There is clearly no single preferred option by the people replying here or a mass call for this behaviour (present since the beginning of joomla) to change - dont think I have heard anyone asking for this before in over 5 years (but I could be wrong)

Quite possibly, I haven’t been heavily involved in Joomla for that long…

 

I would be very against this being a configurable option as it would mean that the default expected behaviour woud not be the same on all sites and would create problems with documentation (both on joomla and extensions).

I have to say that I disagree with your reasoning here. As a community, we shouldn’t ever say that something shouldn’t be changed because ‘it’s always been done like that’.

 

I also don’t understand how changing a default behaviour in the core is going to affect documentation for 3^rd party extensions in this case (of course there are many cases where it would). Surely what we’re talking about here are two fairly isolated options, what is the default option when you create a new module in the module manager (I wouldn’t envisage this affecting the auto created modules as part of the installation process) and managing the ability to change the default menu item for the site. If I’ve missed something in the ramifications please tell me, I’m still learning here :o)

 

Cheers

 

Keith

.

[Janich]

Mark, you asked for input...

Some time ago I found myself in the same situation as Richard - I wanted to to make internal departments in control of their own "sections" of a global site.

It would have been a truly nice feature, but I never really found any solution to do it with core Joomla!, so we skipped it and gave the responsibility for maintenance to a central group of "super admin". (speaking of trust)

It wasnt a school, but it sounds more or less like the same situation where you want a setup with multiple admin groups, isolated from ones anothers areas.

After reading this whole thread on the train home, Im really in favor for either a core.edit pr asset in the menues or a special core.assign.

Of course the interface should reflect it with "greyed out" checkboxes - or perhaps those shouldnt even be visible...

[Richard]

I'm kind of confused here. This thread is about menu ACL but everyone seems to be talking about the "no pages" default that I suggested in another thread. Can we move the discussion back over there so we don't get even more people confused? I'll be posting my replies to relevant posts in this thread over there in order to steer things that way.

[Richard]

Where do we stand on this feature? We'd really like to have this implemented in version 3.0 if not sooner. What needs to be done? How can I help move this along? Thanks!

[Nick Savov]

Hi Richard,

I see that you guys had a long discussion on this already:
https://groups.google.com/forum/?fromgroups#!topic/joomla-dev-general/-xFWT722jTk

Could I suggest that you guys close this discussion and start fresh at
https://groups.google.com/forum/?fromgroups#!forum/joomla-dev-cms ? The
CMS group is the best place for discussion of adding new features to the
CMS and the discussion should be going on in there.

There are several advantages to that:
1) That group is designed for those types of discussions so you're more
likely to get the right attention from the right people (although some
people follow both groups)
2) Starting fresh gives everyone an opportunity to look at things from a
fresh perspective rather than going through the same thought process while
re-reading the old discussion.
3) Starting fresh gives you an opportunity to clarify everything concisely
and simply from the start, rather than from mid-way in the discussion.

Kind regards,
Nick

> Where do we stand on this feature? We'd really like to have this
> implemented in version 3.0 if not sooner. What needs to be done? How can I
> help move this along? Thanks!
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/PX4dppL1j60J.

> To post to this group, send an email to
> joomla-de...@googlegroups.com.
> To unsubscribe from this group, send email to

> joomla-dev-gene...@googlegroups.com.

[Mark Dexter]

I think we sorted some of this out. I'm happy using menu.edit
permission to control assigning modules to menu items. I think we
agreed that All and All Except require component level edit permission
for menu items.

I would ignore the sidetrack about changing the defaults, since this
was not related to your proposal.

What is the status of the pull request in the tracker issue? Is it up
to date? Does it need tweaking to add the ACL we discussed?

If you can get this up to date, then I would post in the CMS list for
people to test and comment on the feature issue.

Does that make sense? Mark

[elin]

3.0 is where new features will go and features need to be coded. So "where we stand" is ... waiting to see code and  looking at extremely extenisve testing given the performance impact of corruption in the assets table. Also this would need to be incorporated into migration scripts so  your team shouldbe working with the people working on that as well. 

Elin

> joomla-dev-general@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-general+unsub...@googlegroups.com.

[Richard]

What is the status of the pull request in the tracker issue? Is it up to date? Does it need tweaking to add the ACL we discussed?

Mark, as far as I know, yes. I'll do a merge to make sure there aren't any new conflicts.

So "where we stand" is ... waiting to see code and  looking at extremely extenisve testing given the performance impact of corruption in the assets table. Also this would need to be incorporated into migration scripts so  your team shouldbe working with the people working on that as well.

Elin, I already have the code up on GitHub as a pull request. I linked to it near the top of this thread back in May. As far as I can tell, it works. There definitely needs to be more testing. I've only been testing locally. I think the migration scripts are what's next. Is there any documentation on how those work? Is there anyone else working on ACL so we can coordinate?

Nick, I'll make a thread on the other group.

Thanks for the help everyone. I really appreciate it.