New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inheritable menu item property (take 2) #13817
Inheritable menu item property (take 2) #13817
Conversation
… Administrator management at the Menus:Edit Item level.
… Administrator management at the Menus:Items level.
Wow! Travis has had a change of mind. |
Testing InstructionsSetup
Test 1: Visibility of the Menu Item to users.Test 1.1
Test 1.2
Test 2: Managing the Inheritable as an AdministratorTest 2.1
Test 2.2
Test 2.3
Note I have not implemented this check at the Menu:Item Edit screen level. If necessary, I will do that. Test 3: Language settingsChange the text of the following language dependent variables according to your requirements. You will need to add these for languages other than en-GB. In administrator/language/en-GB/en-GB.com_menus.ini
In _ administrator/language/en-GB/en-GB.ini_
In _ administrator/language/en-GB/en-GB.lib_joomla.ini_
In _ language/en-GB/en-GB.lib_joomla.ini_
|
@infograf768: I have changed the wording of
Feedback on improvements are welcome. |
@Napoleon-BlownApart is your PR a Solution for #12010? |
The example is a bit badly chosen as there is a "Guest" user group exactly for that purpose. So you can show things for visitors that are not logged in and hide it for logged in users. Maybe you should choose another example which can't be solved with the current ACL possibilities already. |
@franz-wohlkoenig: no, it is not. I came up with this idea while I was trying to figure out the current ACL, which I consider very hard to learn to understand and inefficient for the kind of use cases I had in mind. The main ideas are far easier learning curve, improved likelyhood that the configured ACL will reflect the intended ACL, easier to modify settings. Without sacrificing any of Joomla's ACL features. I have an open thread in the Joomla Extension forum which I need to wrap up, where, thanks to WebDongle, Per Yngve Berg, and toivo, I finally understood what was happening under the ACL hood. In that thread, I will draw a comparison between the standard configuration and how it would be achieved using the Inheritable property. I will link to it from here. |
thanks for Info, @Napoleon-BlownApart |
Only for menus as I understand it, all other cases (item visibility, module visibility, ACL in general) would still need it. Personally I wouldn't allow to break up ACL inheritance. But that's a personal opinion. Looking forward for a more helpful example which doesn't involve the guest group. |
I am preparing a scenario to draw comparisons. I'm considering using Akeeba backup to provide demos, as well as screenshots and explanatory text. Any suggestions on how to make the presentation are welcome. |
(I will fix up the merge conficts next.) I've prepared two implementations of the same scenario. Before I continue, I need to qualify that I am not an expert in Joomla ACL, let alone Joomla in general. I just cleared a path through a dense jungle. So I may not be the best person to argue the benefits of this feature, but here goes.... Feedback concerning my scenario set up are most welcome. Justification1 The current technique to provide non-inheritable User Group specific content (I will use the group extension -exclusive for this) requires the creation of additional child User Groups. Thus, up to twice as many User Groups need to be set up to facilitate this. In addition, up to twice the number of View Access Level needs to be set up to allow exclusive access. 2 Content assigned to the -exclusive is outside the normal hierarchical structure of the User Group inheritance, and thus needs to be configured separately. This is particularly relevant to Category access and permission granting. Category Lists do not show content that is separated out for exclusive access. 3 Since ACL is so important, the Inheritable attribute makes the task of organising and checking access and permissions much easier. The small and relatively simple scenario I set up was very complicated to achieve (and I would like feedback from those more familiar with Joomla ACL configuration) because of the dual User Group/Access Level problem. Using the Inheritable property, the task was greatly simplified, which ensured the quality of the outcome. 4 With fewer User Groups and Access Levels, there is a significant saving in the size of the database. You will notice that the Inheritable version of the Akeeba backup is more than 10MB smaller than the standard version. And this is for a very simple scenario. 5 The feature is transparent and has no effect on the Joomla configuration when the default setting of YES is used. Thus you can export/import the sql from one site to another and it will work after you add the Inheritable column to #__menu table. I used this property to simplify the populate of the Inheritable scenario, inside a basic Joomla installation. 6 I believe that Wordpress has won the website publishing (blog) race. I have been a supporter, advocate, and user of Joomla since around 2006. I have never used Wordpress but I see it in use all over the place when I google. I have studied the architecture of Drupal but never implemented a site with it. I think Joomla is a terrific CMS, but I think it's time Joomla moves beyond the author/editor/publisher paradigm. I believe Joomla filling the gap between Wordpress and Drupal. Joomla has a nice framework and is a lot easier to work with than Drupal, but much more sophisticated than Wordpress, as demonstrated by the large number of off-the-shelf applications that can be installed into Joomla (eg Virtumart). An object molded into shape is stronger than an object beaten into shape. Scenario DetailsI have prepared two Akeeba backups, one that implements the scenario using standard Joomla, and the other with the Inheritable modification. I have used Joomla 3.6.5 for this as I had some issues with the staging version. The scenario is of a company with the following user types: public, registered customers, general employees, a sales department, and a warehousing department. Each of these groups has access to appropriate content (which sometimes overlaps). Image follow at the end below. A detailed scenario description (text file) can be downloaded from https://www.abms.net.au/public/inheritable_comparison_scenario.txt Sample images comparing the scenarios: |
@sanderpotjer Can you have a look at this proposal? You know the ACL system better than I do 😄 |
@Bakual: I fixed the merge conflicts, but it's not working. When I pull the staging branch in my local repo it tells me I'm already up to date. However, I'm not getting the code that either caused the merge conflict, nor my resolution. How can I update my local staging branch so I can merge the changes and debug the resolution? Cheers. |
What I usually do is that I have added the joomla/joomla-cms as a "Upstream" remote repo. Then I can merge the upstream staging into my local staging (fast forwarding) and then push to that to my origin. This way your own origin is in sync with the one from here. |
Travis and I are, again, in disagreement. Travis reports the following error, which I cannot replicate.
Could someone please help me with this? Not a fix, but an indication on how to replicate the problem or otherwise. Cheers. PS.. I have no idea how to interpret Appveyor's results, they don't seem to tell my anything. |
I think it is failing some test, but I can't workout which one, nor where the tests are. |
Looking at the output of Travis Job #33609 and expanding line 189, reveals that the |
@infograf768 : I have a feeling we are working with different builds. Here is the I merged
Then I made the required changes and pushed back to |
@infograf768: When I merged With the |
@infograf768: I have fixed the erroneous Search Tools -> |
TRAVIS..... You're FIRED! |
But seriously, could someone please help me identify the problem Travis is complaining about. I believe it may have something to do with my local repo being messed up? Otherwise, how could the tests be creating the database without the required field. All the SQL files have been updated. |
@Napoleon-BlownApart it looks like there is a fatal error:
After this change? |
@zero-24 fair enough, and I could see that in the Travis report. But on my install here, I don't get that error, and others who've tested my proposal have not had that problem either. How do I fix a problem I can't replicate? Which test is failing? What is the call stack that lead to the error? |
build/build.php
Outdated
@@ -55,7 +55,8 @@ | |||
|
|||
echo "Copy the files from the git repository.\n"; | |||
chdir($repo); | |||
system($systemGit . ' archive ' . $fullVersion . ' | tar -x -C ' . $fullpath); | |||
//system($systemGit . ' archive ' . $fullVersion . ' | tar -x -C ' . $fullpath); | |||
system($systemGit . ' archive inheritable | tar -x -C ' . $fullpath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason you pushed your changes in the build.php?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yvesh: because without it I cannot build the inheritable branch. and it is polluting my git status output. I take it from your question that this is not the right thing to do, so I will revert it back.
libraries/joomla/table/nested.php
Outdated
$this->inheritable = $state; | ||
} | ||
|
||
$this->setError(''); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you set it empty here? Shouldn't be filled? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yvesh: I used function publish()
, which is just above function setInheritable()
, as a template and it too sets it to an empty string.
…anged excpet file ownership on some from root to my user id. I have installed composer and phpunit since the last commit and attempted to run the command 'phpunit . --debug --testdox'. I think git got confused somehow.
This is all getting too complicated for someone new to the process and now I'm responsible for fixing merge conflicts in shockwave files (I'm blown away). I'm going to delete my fork and start again. I've learned a lot going through these steps and I think this will lead to a much cleaner proposal that will make it a lot easier for those interested/responsible to evaluate. |
Merge remote-tracking branch 'upstream/master'
If you delete your fork, it may be a good idea to do a fully new PR and close this one. |
@infograf768 : Cheers. That's what I had in mind, but wasn't sure if that was a good idea. I have already backed up everything here. |
@infograf768 : Cheers. That's what I had in mind, but wasn't sure if that was a good idea. I have already backed up everything here. I have created a new fork now, so I'm closing this PR. I'll create a new PR once I fix all the Travis issues. |
I have implemented an Inheritable property for menu items. The property determines if higher access levels inherit the menu item. An inheritable menu item will display in the menu for all user groups who inherit visibility of the menu item's set access level. A menu item set to un-inheritable will only be seen by users who belong to the access level group that is set in the menu item.
For example:
With a "Register" menu link (whose access is set to Public with Inheritable NO), a public visitor to the site will be able to register, but once they have activated their account and been upgraded to the Registered user group, they will not see the "Register" link while they remain logged in (assuming the user is not assigned to the Public User Group on the User:Edit-Assigned User Groups screen).
Had the Inheritable property been left ON (default), the menu item's behaviour would have been standard Joomla behaviour, and the Registered user would still be able to see the "Register" link (unless a separte menu was created for registered users or some other hack was implemented).
This is a continuation of PR #13766