well this only need a more fine grained review.....
can you provide a full list of wrongly protected / unprotected items
i'm quite sure we can solve all before beta

Sorry I didnt test the original PR. It's really fubar.

As well as the issue @infograf768 correctly points out there is an additional problem - but I guess you have to actually use Joomla in the real world to see it.

From a UI perspective it is impossible to guess what the difference is between locked and protected. Having not read the original PR - like all our users I have not been able to guess.

Just don’t forget that it needs also to be changed in the update SQL script, too. If you have a list of what is wrong and how it should be right, I can make the PR if nobody else wants.

One of the problems is the use of the lock icon for protected stuff...
At reading the original PR:

    protected indicates an extension which cannot be disabled

    locked indicates an extension which cannot be uninstalled

But it looks like the lock icon is used for protected...

EDIT: This means that my original comments may be wrong but we still have a mess there.

folks please calm down
the only things that we need is a full detailed list
of what needs to be locked and what to be protected
in theory that pr is moving us forward in a good direction
so we only need the last mile IMHO

I am quite calm but this pr is really wrong. You cant tell what protected or locked means or what the difference is. Think about it. The only way you can really tell is by trying to uninstall something and then seeing what the error is. Thats really dangerous

But it looks like the lock icon is used for protected...

yeah - that's crazy for obvious reasons

Yes, there are some errors in https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_admin/sql/updates/mysql/4.0.0-2020-03-25.sql

The same with several other extesnions, e.g. modules, that should be only set to protected but not locked locked but not protected.

I corrected my #28527 (comment)

Yes, there are some errors in https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_admin/sql/updates/mysql/4.0.0-2020-03-25.sql

The update sql shall result in the same values for locked and protected as the joomla.sql does. So if there is something wrong in the update sql, it is also wrong in joomla.sql

Yes, I just wanted to give a starting point for discussions and corrections because the latter file is not so easy to read for me ;-)

You are right. During my test, I also found it confusing that you could not tell whether an extension was deleted before it was deleted. you can see whether you can deactivate them (protected). I also noted that in the test.
And I only took a random sample to see if the states were correct applied.
There are four states:

Edit: State 3 does not exist in reality.

But I still think that #28462 is moving us forward in a good direction.

My first idea was to change the color of the name to red in states 1 and 2 and to add a note in the text that is inserted when the mouse is moved.

I have not yet considered this to the end. What is your opinion on this idea?

And of course the list in which the states are all recorded would be good. I find it difficult to check this in the program code. Should we create a google doc for it?

I have deleted my last 2 comments. Nice idea but bad idea.

See draft #28560 (where I forgot to click "draft").

Make suggestions for changes there.

Gnaaaah. Sorry! My interpretation above seems to be wrong!

There are extensions that are protected AND locked. That's wrong.
protected indicates an extension which cannot be disabled (and/or uninstalled).
locked indicates an extension which cannot be uninstalled (but can be disabled)

When I read the specification of pr then it's meant like this:

There can be extensions that are protected AND locked.

protected indicates an extension which cannot be disabled
locked indicates an extension which cannot be uninstalled (but can be disabled if protected=0)

At least these lines have not been adapted correctly(???)

https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Installer/InstallerAdapter.php#L1154-L1160

Give me some time to mess around with the code before I come back with the next brilliant idea ;-)

@ReLater
When I read the specification of pr then it's meant like this:

There can be extensions that are protected AND locked.

protected indicates an extension which cannot be disabled
locked indicates an extension which cannot be uninstalled (but can be disabled if protected=0)

At least these lines have not been adapted correctly(???)

https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Installer/InstallerAdapter.php#L1154-L1160

Give me some time to mess around with the code before I come back with the next brilliant idea ;-)

I think this is because there is no extension that is protected AND NOT locked. If you should not disable implies that you should not delete it.

So: State 3 in my table does not exist in reality.
Is this correct?

So: State 3 in my table does not exist in reality.
Is this correct?

Yes for core extensions.

My "mental to-do path":

• First lock them all and enable them all; and make them unprotected (temporarily protected=0).
• Then think about possibility or necessity to disable them (protected=0 or 1 ?).
• Then think about enabled for extensions that can be disabled (protected=0 !).

Can I get an OK for the "Summary of Changes" at #28563 ? Before I go on.

The list shows all extensions that can now be disabled in contrast to the current state of pr #28462 where they all were protected.

New list with all extensions that can now be disabled at #28563 (comment)

I messed around a while in the backend and wherever it seems stupid to disable extensions (e.g. all core installer plugins) one gets (as far as I see) a clear message from Joomla like

I think this is because there is no extension that is protected AND NOT locked. If you should not disable implies that you should not delete it.

Not exactly. You can disable com_banners and everything works OK. You can't uninstall com_banners because of the manner in which Joomla is packaged and eventually having done so will cause errors during the update process. Hence, the requirement to be able to differentiate between an extension which must always be enabled and an extension which should not be uninstalled. BTW, this is a useless distinction with plugins because com_plugins does not take protected and now locked into consideration when offering to change the status on those.

The entire point of the original proposal was to add a protection layer to keep users from doing potentially damaging actions. Uninstalling core extensions is a potentially damaging action. Sure, the quick fix with the 3.x architecture is to mark them all protected, but that means every single core extension must always be enabled. Hence the requirement for a flag differentiating between "this is so important that it must always be active" and "this is so important that it cannot be uninstalled".

Since people seem to love writing Joomla in a way where first party code is given preferential treatment over third party code, the other option is to remove protected (and now locked) from the database and use that helper class that lists all the core extensions and hardcode protected/locked states into that, then only core Joomla extensions can be given this level of protection and third parties if they wanted to use these capabilities are basically SOL. But I prefer that first party and third party be given an equal playing field so I am not advocating for that solution at all.

Exactly that is why I wanna have both, the hard-coded core extensions - I know, it could have been done better - and the new locked field in database, because the latter can be used by non-core, too.

Please test and/or review pr #28563 for part 1 of this issue (Some extensions are protected and should not).

Part 2:
@infograf768

But it looks like the lock icon is used for protected...

Yes, it's irritating somehow.

Maybe we should think about new icons and/or filter options for states

Icons:
locked and protected (padlock would be fine I think)
locked but not protected (can disable)
only protected (3rd party extensions could use it e.g. for template supporting plugins or things)

and additionally disable the checkboxes if locked and protected.

and additionally disable the checkboxes if locked and protected.

See PR #28545. Refresh Cache button prevents this.