Can confirm it with current 3.10-dev updating to latest nightly 4.0-dev build.

Added release blocker tag

This is due to the Admin Submenu module.

DELETE FROM #__modules WHERE id = 13
DELETE FROM #__assets WHERE id = 47

would delete the old entry but maybe depends on the previous joomla versions.

Yes, IDs might be different depending on the update history.

Admin Submenu which is not in J4 is the same as System Dashboard. How about deleting it based on position submenu and respective asset_id?

Could a user have own modules on position submenu in older Joomla installations?

I'd prefer to delete this < div:
https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_config/tmpl/application/default.php#L39

I cannot imagine that it makes sense to render modules in the sidebar.

@chmst wasnt this where integrators could out their own information - like on the login page?

Yes. This is position sidebar. in the login page.
We are speking here of the sidebar in the componente com_config.

Yes I realise that but wouldnt an integrator also want to put their information there as well

Of course you could simply rename the position in j4

If we keep both positions, we must rename one of them. But does it make sense to have a position here in the component sidebar?

In J3 the sidebar was the left panel, this was a better place for additional module.

In any case: the sidebar module from 3.9 may not appear in the submenu of con_config.
We could:
delete any module sidebar from j3 database during migration and / or
remove the whole position from the com_config sidebar or
rename the position in com_config sidebar in j4

oops i must have been tired last night I thought this was the area below the mainmenu. sorry

you're right there is no sense in having a module there

I've made a PR so that the module is not rederen on com_config.

This does not solve that the old module remains in the database after migration. So pleas do not close this issue until we have a decision for this.

I've made a PR so that the module is not reder on com_config.

Thanks

This does not solve that the old module remains in the database after migration. So pleas do not close this issue until we have a decision for this.

That would be just the same as when you change site templates with different position names

Admin Submenu which is not in J4 is the same as System Dashboard. How about deleting it based on position submenu and respective asset_id?

I'll have a look tomorrow if there is a way.

On installations with a longer update history we might not really know the ID's of these modules, and for the asset ID it's the same.

We have to find a combination of columns, maybe with a join of columns from another table, so that we are able to identify the records to be deleted in a WHERE clause in an update sql script safe enough to make sure it doesn't cause collateral damage on any other modules people might have in whatever template's position. I am not 100 % sure yet if we can grant this.

It would be easier if we had unique constraints in the database for things (columns or combinations of multiple columns) which our PHP code expects to be unique.

Can we close this? The issue itself is resolved.

It will be better to make an issue for other problems which are not so obvious.

Can we close this? The issue itself is resolved.

Depends on @Quy , I think.

@richard67 I thought you were researching on this when upgrading. See your previous comment.

@Quy Well I have had only a brief look up to now, and I haven't seen a solution yet.

No longer reproducible.