What's the value of columns client_id and the menu_type of the menu items in the database table?

For Akeeba Backup and JCE items

client_id is set to 1

Menu_type is set to main

Chris

On 20/09/2017 11:31, Richard Fath wrote:

What's the value of columns client_id and the menu_type of the menu
items in the database table?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#18000 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHxzNx7Tggh3Z9EX9bXUW7GF5kXIm9kvks5skOlvgaJpZM4PdlVm.

Hmm, client_id and menu_type seem to be ok. So I have no idea.

I have the same problem

I also have this problem

Missing components:

• Akeeba Backup
• All RegularLabs components
• Monthly Archive
• ACL Manager
• JCE Editor
• RSForms

...and a 'new item' appeared:

• COM-K2 (never installed it...)

And also upgraded to Joomla 3.8.0 on several other sites, without a 'glitch' having these same components...

Burnardo

I'm experiencing the same problem after updating from Joomla 3.7.5 to 3.8.0 . The user is in an ACL group with full access, but the only components showing under the administrator > components menu are the Joomla default items.

is there any information you need to help solve this issue, as there seem to be others with the issue.

Yes, please. Any information that could lead to solving this would be helpful.
Thanks

Dear all, as far as i read in other similar issues Maintainers are discussing whats best to do.

Here are, for what it's worth, my data for the items that got lost from the Components Menu.

ACL Manager
ID: 10718 (package ID), 10011
Menu Type: Component
Version: 2.5.4

Akeeba Backup
ID: 10535 (package ID), 10009
Menu Type: Component
Version: 5.6.0

Monthly Archive
ID: 10847
Menu Type: Component
Version: 4.2.0

JCE editor
ID: 10705 (package ID), 10317
Menu Type: Component
Version: 2.6.19

Regular Labs Extension Manager
ID: 10483
Menu Type: Component
Version: 7.1.2

RSForms
ID:
Menu Type:
Version:

The 'newly added' item COM_K2 in the components menu list does not even show in the components control list. This one is (most probably) a 'left over' in the database, that has now risen its head...

I hope this is useful information. Here are two screen shots of the #__menu table from two sites
First this site works
https://www.dropbox.com/s/10mybpixgvpg62u/works.png?dl=0
Second - this site does not display the correct items under the Components menu
https://www.dropbox.com/s/cm4g2rg1qc39ya0/doesnot%20work.png?dl=0

If you look at the Akeeba line the only difference I can see is the access field, 1 where it displays ok and 5 where it does not work.

Is it okay to manually update this table.?
Also what does 1 and 5 mean?

They should be access levels. I had 8, and 7 levels of access. In fact I put it to 7 and it works. Maybe you only have 4? It would appear that Joomla now checks the number of levels ... it's just that? O_O

I was wondering what the status of this issue is?
I have 4 sites upgraded to 3.8 which are ok but I also have 12 sites that have been upgraded and have lost menu items off the Components menu.
So we could do with a fix or an idea of when one is likely? Are there other issues where this is being looked at?

@ramblerswebs can you look at #18020 (Comment)?

closing this Issue, please comment at #18020

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18000

How much stuff ... ramblerswebs sorry, I do not know if I can explain to you, with my english. I think the problem is upstream, probably a bug of previous releases. I think it's okay to add component access control. Maybe it had to be done before, they could only tell you, especially since apparently too many extensions follow wild rules in the installation.
When I have time I will try in the PHP core, meanwhile add that greater clarity would not hurt. If there were more attention and less updates we would not have headaches once a month ...

Not sure why you close this as 18020 is a different issue completely.
Web links is one of the m8ssing items. As a core project I assume they follow correct methods

I agree

reopened as stated above.

Sorry Folks didn't get it thats a different issue.

Set to "open" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18000

It is different in that the 3.8 install works without any error messages. Then some Components are not displayed in the menu of that name, otherwise all looks fine.
You may be right that this was a bug in a previous version which caused the #__menu access field to be set to >1 for some components (including Web Links)
I have just installed 3.7.2 from scratch and the access field is set to 1 for the components I then installed.
I then upgraded to 3.8 and access remained at 1 and the components were still displayed in the menu of that name.
I have set access to 1 in one of my sites that was failing and now the components menu displays correctly.
This leaves me with the questions:
How did access end up at > 1 on some site but not others.
Why 3.8 does not display these components with access>1 were as 3.7.3 and before did display them.

Should 3.8 display them or should access be reset to 1 for these items?

It seems confused: I repeat, but, for example, if you set 2 appear? and how many total accesses have you in the acl? For me it is important and before you did not answer me.

Sorry I don't understand what you are saying.
What do you mean by set 2 appear?
What is the cal, and what do you mean by accesses.
I just use Joomla so you need very simple questions.

Sent from my iPad

On 22 Sep 2017, at 16:33, CristianoSias notifications@github.com wrote:

It seems confused: I repeat, but, for example, if you set 2 appear? and how many total accesses have you in the acl? For me it is important and before you did not answer me.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

As previously stated, after update from joomla 3.7.5. tot 3.8.0. (and only on 1 domain...) the non-standard components form the admin menu 'Components' were invisible. Standard Joomla components remained visible in this menu.

It appears to be caused by the 'access level' in these components items (database table: '_menu'). I am using 9 different defined levels of access on this domain. (access level 1 = public, acces level 5 = superuser)

The installed components had (in 3.7.5.) access level 5. This did not change after upgrade to 3.8.0. But after the upgrade only these items were invisible for superuser, while they kept the same access level.

By changing the acces level of these invisible items to '1' (in my domain used for 'public access level') they appear again and are also fully usable from admin side.

Now I still would appreciate to diversify these levels as I use also different levels of admin-accounts. I am not sure yet if that is possible without a problem, or that I am only able to use 'public access level' for all admin logins.

@izharaazmi Please check this issue. This is related to admin mod_mrnu changes..

I'd be glad to look into the matter. It would make my efforts more efficient if someone can provide me a backup copy (ZIP file format, not Akeeba backup please if possible) of website before the 3.8 upgrade.

Make sure that all your confidential data has been removed when you provide your site backup for testing.

Sorry I don't have any zip file format backups, all ours are Akeeba jpa file which have both the files and sql data.
If you want zip format how would you want the database copy?

sorry clicked on wrong button and closed issue by mistake. Reopened.
@izharaazmi tell me how you want the sql database and I'll try and get you a site prior to 3.8

You can provide the database as yoursite.sql using mysqldump or phpmyadmin export

@ramblerswebs If you find it too much of work making it a zip format. I can try using jpa to make it easy for you.

@izharaazmi Thanks for that. I was going to install the site and then zip it and take an sql copy.
In the link below are two file kickstart-core-5.3.1.zip and a jpa file

To install, just copy files to web server, Unzip kickstart and then run kickstart.php and select the jpa file.
This unpacks the jpa file and then asks you to install the site

Let me know when you have downloaded files and I will delete this post.

@ramblerswebs I have downloaded the files and the jpa file is 25.5MB size. If this is correct, you can edit and remove the link from the post above. Do not delete the post please.

As a precaution you may also want to move the file outside of this shared dropbox folder as this post has reached to the emails of several people who follow.

That sounds fine. To log in as an admin use newuser/pleasechange as username and password.
Let me know if you can install the jpa or not

@ramblerswebs Great! I'm in.

So far I can see all your menu items are set to guest access level thats why they are not shown. As of the CMS this is the correct behaviour. However the issue still remains and now we need to investigate how and what caused this access level to be set for admin menus.

I have verified that the core or Akeeba/FOF never sets the access value on these menu items so they cannot be blamed as of now.

If you have any backup before even 3.7, can you look into that and see if this existed before it or occurred after 3.7 upgrade?

Hi, what sort of date would J3.7 have been introduced? I will then look for a backup prior to that.
Also which field are you looking at to say the items are guest access level?

Joomla 3.7 was released on April 25, 2017 - See Release

The menu items in #__menu table has access = 5. Access level id 5 is Guest in your site, see #__viewlevels table.

Good morning izharaazmi
In that case here is a backup file from the 20 March, again, let me know that you have downloaded it and I will then delete the link

Obviously Guest is wrong, should they be Public or Super User?

I have downloaded it, size = 23.1 MB. Access level Public should be fine.

I can see the issue was coming along even before 3.7 upgrade on your site. Therefore the conclusion as until now is that some bug (3PD or Joomla) may have set those values to guest access level way back in time.

Since this bug no longer exists and was caused even before the admin menu manager was introduced, there is nothing much we can do here.

Run this query to see the access levels of your admin menu items on any of your backups.

SELECT `id`, `menutype`, `title`, `link`, `access`, `client_id` FROM `jpa2`.`jos_menu` WHERE client_id > 0 ORDER BY `jos_menu`.`id` ASC

@ramblerswebs please ask further help on the forums as this repository concerns Joomla coding. For this Reason i close this Issue, thanks.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18000

@izharaazmi Case of was the sInple one. I mentioned you because of case described by here.

@wojsmol Yes! we can (and should) use the appropriate desired access level for menu items. And the menu items will be shown only to the users with that access level. If that is super user then it should be visible to super users. In my case study it was guest so it was not visible as none of the backend users are guest.

This is the whole point of being able to make multiple menus for backend menu manager so that we can show different set of items to different types of users.

I think this issue was caused by the Joomla installer as I have also had a couple of modules appear in the Components menu, I believe this must have been the Installer as the module has no install code.

The question I would ask before you close this is how a USER of Joomla who knows little/nothing of how Joomla works fix this issue? I assume there is no admin way of editing the main menu and changing access levels.
If that is correct how would a user change the access level?

Now updated (again) the only problem-joomla3.7.5-site to joomla 3.8.0.|
Then manually adjusting the respective database items ( in table *_menu ) 'access level' ( becoming invisible with the setting '5') to '1'.
All seems OK and all components can now be handled by admin from the component menu.

As a test, installing a newer version of a component.
It then appears that the 'access level' again is turned back to value '5' making this component again invisble.

So it looks that from now on, on this and only this website, I will have to go back into the database, each time a component is installed or updated, in order to adjust the access level. Otherwise the component will not be visible in the admin component menu.

Sad, but true...

This is a pretty good test case. I'd like to investigate on it if you could
provide me the site backup and the extension which you install. If this is
a core bug, I'd be happy to fix it.

Further update...
On my 'main version' of this site, (and after update to joomla 3.8.0. with all components set to access level '1', public to make them visible).
I, now first set the acces level of the component I am about to update, to level '6', which in my case is 'super-user' level. Just to see if that will also be overwritten to 'guest level' '5' when updating this component.

And... yes... also a specific 'super-user level 6' is simply overwritten when installing a component update. After the update the acces level is '5' again.

I will provide a backup of the Joomla 3.8.0. with the component 'not-updated-yet'.
Attached also the newer version of this component, so you can see for yourself how the component update wrongly overwrites the acces level to a level for guests (in stead of keeping it at original level or at least public level to prevent hiding it in a admin coponent menu)

@Burnardo Check value of $access in configuration.php. I bet this is 5. Change to 1 and update or install any component.

@izharaazmi I'm right then postinstall message with script and issue fixed IMHO
cc @Webdongle @mbabker

@wojsmol Yeah, right. That must be the case. The JTableMenu constructor uses that value directly.

@Burnardo Please confirm.

I will get back later and try your suggestion @wojsmol.
Hope we will have succes...

@izharaazmi In PR wee shod handle also case when the access level set in $access don't exist.

Which PR?

@izharaazmi I'm so sure the future comment from @Burnardo :)

sorry folks can someone share what "component" update are you talking about ?

Updating 'any' component should not result in the loss of this component's
menu item in admin side under main menu: 'Components'.

That is the 'short' for what is examined.

However, coming from updating Joomla to 3.8.0. and then losing 'most' of
those same mentioned menu items, is the 'broad' background of this problem.

Hope this description is clear enough.
... and hoping to see if the suggested solution works (when I get home...)

Op 27 sep. 2017 14:16 schreef "Nicola Galgano" notifications@github.com:

sorry folks can someone share what "component" update are you talking
about =

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18000 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADM3i0GCLD1-fZOArVolz45se97xx0xmks5smjyngaJpZM4PdlVm
.

@alikon See also issue description in fist post.

so to be clear:
it seems that after upgrading to 3.8.0 if you upgrade a prevoiusly installed component
that component is no more visible in component menu item ?
i've understand correctly?

@alikon Yes, for some sites. Not everyone is facing this issue.

I can confirm that reinstalling Akeeba Backup removes it from the Components menu.
I have tried this with the value of $access in configuration.php set to 1 or 5 (guest) and each time Akeeba is removed from the menu, its #__menu value is set to 5 each time.
Not sure why $access in configuration.php is raised as that should have nothing to do with the admin area surely.

@ramblerswebs did you experience the same issue with other component's ?

Not tried other components BUT have just found that the value of Global Config > Default Access Level
was set to guest.
If I set it to Public and then reinstall Akeeba it remains in the Component menu.
If I put it back to Guest and reinstall Akeeba is removed
Set it Public and reinstall and guess what Akeeba is back

Checked two sites that did not have the issue and Global Config > Default Access Level is set to Public

@wojsmol is the champion here ? I checked bind, check, store methods, and never thought of looking at the constructor ?

Now what do you suggest as the solution @wojsmol?

@izharaazmi See #18000 (comment) but wait for @mbabker or @Webdongle confirmation.

Hello all,

Back home again and eager to check for verification...
In my 'configuration.php' file it states:

       public $access = '5';

After setting this to:

            public $access = '1';

(In this site I use:
public level = 1
guest level = 5
super user level = 6)

Then updating the respective component (does not matter which one...)
the components link in the admin menu under 'Components' remains visible (which was not the
case before with the other setting in configuration.php.

Thanks for the correct hint in this matter.

@franz-wohlkoenig Please reopen for better visibility.

re-opened as requested

@wojsmol
Don't wait for me to confirm ... I'm still waiting for a clear set of instructions on how to replicate.

I can confirm the "problem":
set Global Config > Default Access Level --> Guest
and install a new component, not show it in the component admin menu.

Don't know if this is useful to fixing issue, but I tried updating another site to 3.8.
Firstly I set Global Config > Default Access Level to Public
After the update it had lost some components (set to 5/Guest)
I then updated some of the components and they reappeared.

@AlexRed
Now go to Users >>> Viewing Access Levels >>> Guest ... select Super Users. It comes back in the menu.

In another old version (I used 3.7.0)

1. Set Global Config > Default Access Level --> Guest
2. Install a 3rd party extension
3. Go to Users >>> Viewing Access Levels >>> Guest ... select Super Users
4. Install another 3rd party extension
5. Update to 3.8.0

Both 3rd party extensions show in the menu

Here is the twist
Go to Users >>> Viewing Access Levels >>> Guest ... deselect Super Users
The 3rd party extension that was installed before step 3 ... is no longer seen in the menu. But the 3rd party extension that was installed at step 4 ... can still be seen in the menu

Hope that gives a clue to the mechanism behind this bug

Addendum
After comparing various Tables and entries in 3.7.5 and 3.8.0 ... I have not spotted anything amiss. Suspect that the problem is somewhere in \administrator\modules\mod_menu of 380. Joomla appears to use two sets of criteria for view levels. Display (in admin menus) of 3rd party Components menu items appears to follow the same rules as viewing from the front end.

Further testing
Replaced
\mod_menu folder of \administrator\modules\mod_menu J3.8.0
with the one from J3.7.5
Full SUCCESS !!!

\administrator\modules\mod_menu\menu.php lines 293-302 check for $authLevels.

  	// Exclude if menu item set access level is not met

		if ($item->access && !in_array($item->access, $authLevels))
		{
			continue;
		}

Removing it fixes the problem. Have removed it ... set a test user as Administrator and the test user can see the 3rd party menu item. Set the Permissions for Administrator (for the 3rd party component) as 'Denied' ... result the test user can not now see the 3rd party menu item.

$authLevels = $user->getAuthorisedViewLevels(); (line 238) is incorrect because display of the menu items in Admin is controlled by Permissions not User Group View level. It is the Menu itself (Not the items) that uses User Group View level.

I am not Git savvy ... can someone please produce a PR patch based on these findings ?

Go to https://github.com/joomla/joomla-cms/blob/staging/administrator/modules/mod_menu/menu.php and click the pencil icon in the toolbar. Change the file. At the bottom of the page you'll be able to briefly describe your changes. When you hit save, you'll be taken to a screen to propose the PR for it.

@mbabker there we fixing symptom not root course. See my discussion about the root cause above -#18000 (comment) and next comments.
@izharaazmi Please assist with explain this from a code perspective.

@mbabker
That is only part of the problem. There will be other code for $authLevels = $user->getAuthorisedViewLevels();

There are other related issues
Before I updated I installed two 3rd party Components one with Global default Public and one with the setting in global 'Guest'. After updating ... the first 3rd party component (installed when global setting was Public) menu item could be seen ... so obviously was not using the check code. But the 3rd party component (installed when global setting was Guest) menu item could Not be seen ... so obviously the check code was being applied to it.

This raises questions as to what is happening to the 3rd party components when installed while Guest level is set in global. IMHO this poses security questions. Somewhere deeper down the Default Access Level (user groups view/access) setting is being confused with Admin Permissions access when Guest is set as default in Global config.

So just on the admin menu alone, we have a problem. There are two forms of access control checks from two different systems:

• core.manage ACL permission check as that is the minimum permission to give read access from the CRUD group to the component
• Viewing Access Level check using that system

I still think we need a way to make viewing access levels part of the ACL system and not its own beast. View/Read is an access control permission. I honestly believe our current setup which basically creates two ACL systems causes more issues than it solves, this being one of them.

Menu insertion/update will have to have special handling I believe. But, because we don't have a non-deletable view access level entity, it gets tricky, because it needs to default to Public and access levels not be involved in admin menu building IMO (or if it is we introduce config options for this).

Either way it's not an issue with an easy fix simply because of how the system is engineered.

Those two systems are in retrospective a mistake. Chris and I spent days trying to unravel it all to even rename things correctly but we gave up. Each time we thought we were close we hit another hurdle.

But try this
Install 3.7.5
With Global config Default Access Level Public install a 3rd party Component
Set Global config Default Access Level 'Guest' and install another 3rd party Component
Update
The result is that the first 3rd party Component menu item can be seen the other cant
Therefore there is a difference with the 3rd party component install when Default Access Level 'Guest' and Default Access Level 'Public'

The code is treating 3rd party component (that is installed when Default Access Level 'Public') is being treated the same as the core Components because the view level check code is being ignored. But The code is treating 3rd party component (that is installed when Default Access Level 'Guest') differently.

The code is recognising 3rd party components that have been installed when Default Access Level is set to 'Guest'. This means that a setting somewhere is different when a component is installed with Default Access Level is set to 'Guest'.

@izharaazmi Was munitioning one of the constructors.
Ref #18000 (comment)

The constructor may read the config value to set a default, but it just exposes the underlying problem; it's not the source of it.

View access levels don't have the notion of a super user, or inheritance, or really anything the ACL system has. It doesn't care if you're logged in as a site's lone super user or if you're a guest, if your super user isn't part of the right viewing access level(s) then it will be missing content. And therein lies the problem.

There are places in the code that check super admin access and bypass view access level checks, those just bypass a broken system.

@mbabker

The 'penny' has dropped. Menu items (front and back) are (when created) given a view/access level according to the global config setting. So when a component is installed while global config Default Access Level 'Guest' ... then when the Components admin menu item is created it is set 'Guest' view access level.

@mbabker @AlexRed @wojsmol
I created a PR

What I understand about the viewing access levels that they are essentially a shorthand to mention the set of one or more user groups. Thats all.

Example:

So when we check specific permissions (permissions are assigned to user groups), it should not require checking viewing access levels.

Please correct me if I am wrong.

Second thing, which I am not very sure of, is that I guess viewing access levels were actually meant for frontend usage only and may not be applicable to backend completely. However, before we dismiss/approve this assumption we need a second thought.

The other big thing that access levels affect in the backend is modules, that all behaves the same as frontend and right now there really isn't an alternate way to manage that.

Indeed, even more since for example using multiple admin menu modules will display depending on access.

Shouldn't be there separate viewing access levels for back-end and front-end?

@izharaazmi
There is because the 'Special' Viewing/Access level is only used for the Admin modules (like the Admin Menu module). Only User Groups that have access to admin (i.e. User Groups that have 'Administrator Login' set 'Allowed') should be selected in the 'Special' Viewing Access level.

Although the Viewing Access level is used to display the admin menu module it is not used to control the display of the menu items in admin menus. It's the 'Access Administration Interface 'Permissions' setting that controls Access to the Component's interface (cp) and their menu item.

The problem here is that because the Viewing/Access level is used to control the display of the menu module ... someone (mistakenly) added code that checked the Viewing/Access level before menu items were included in the rendering of the menu items to the browser. When a Component is installed the menu item for it (in the admin component menu) is set at the 'Default Access Level' (which sets the default viewing/access for menu items). As a result when the 'Default Access Level' is set to 'Guest' then the menu item (of the admin component menu) is not rendered to the browser because Super User is not in the 'Guest' Viewing/Access level.

Removing the code that checks the Viewing/Access level of the admin components menu Item is correct and safe because ... Access to the admin components menu Item is already controlled by the 'Access Administration Interface 'Permissions' setting.

@Webdongle
@izharaazmi and myself were responding to @mbabker about backend modules as your PR concerning admin menus is fine afaik

There is because the 'Special' Viewing/Access level is only used for the Admin modules (like the Admin Menu module). Only User Groups that have access to admin (i.e. User Groups that have 'Administrator Login' set 'Allowed') should be selected in the 'Special' Viewing Access level.

In fact, to optimize the new feature of creating various admin menus with their modules, we are not anymore limited to special access.
For example, we can create a variety of usergroups which will not use the special access, but any other specific access and set their admin menu modules to that access (as well as other admin modules).
This means imho that a well thought site would have to duplicate some admin modules in order for them to be also displayed to these user groups.
An improvement and simplification to the access levels for these modules could be the possibility to define multiple accesses per module.

A small consideration: you do not have to consider the user groups you have, but the levels of access you really use. Let me explain: if you have 9 groups and you use 7, here is the value 8 does not show menus. If you use only 4, it's normal that 5 does not show them. This is why I asked to try not to go from 5 to 1 but 5-4 or 3 ... and see if it works.

@franz-wohlkoenig Should this be closed and do troubleshooting in Joomla Forums?

as @Quy suggest: please ask help on the forums. This repository concerns in first Place Joomla coding. For this Reason closing this Issue, thanks.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18000