@infograf768 works ok here but why we need the Unprotected state? The Protected state is only not used ok. But why we need logical a Unprotected state?

But why we need logical a Unprotected state?

Assuming having the states protected and unprotected, why should one not be able to see just unprotected update sites? For me it is just the same as in the manage view, you can filter protected and unprotected extensions.

But to my opinion, there is a little problem. If I just want to see unprotected update sites it shows me nothing. It should show all because there are no protected update sites yet.

The point here, as I said above, is that we miss a "protected" column in the table. Therefore Protected AND Unprotected will not work until we create such a column.
If desired, we have 2 solutions:
1. take off all related to protected/unprotected in this PR for now
2. also create the new column, and therefore update all our sqls at the same time

The point here, as I said above, is that we miss a "protected" column in the table. Therefore Protected AND Unprotected will not work until we create such a column.

I agree, but the user does not know, that this column does not exist yet and expects to see all update sites when filtering unprotected sites.

So, I would prefer solution 2.

I took off the Protected status for now to simplify this PR and solve only #6292
If judged interesting by PLT/CMS Maintainers, a specific PR can be done.

@Bakual @phproberto @nikosdion
What do you think?

An update site can be published or unpublished. There is no such thing as a "protected" update site. The update site of any extension (be it protected or not) WILL be disabled automatically when Joomla! can't fetch the updates. The sole purpose of the Update Site feature is to let you re-enable these disabled update sites.

I can easily think of legitimate reasons of wanting to disable core update sites (network issues in countries/organisations applying strict connection rules, incompatibility of future versions of core components with an older version of Joomla! in the same release branch, ...) and for wanting to enable core update sites (got disabled unintentionally, reasons for disabling it no longer exist, ...). Therefore we need to be able to control the publish status of protected extensions through the Update Sites feature. Otherwise, you know, we'll end up with people like me forking the whole installer infrastructure to make it manageable by end users who can't be trusted with editing their database directly. This would be a waste of resources.

For this reason I conclude that:

1. Having a published / unpublished feature is a good thing.
2. Showing protected/unprotected filtering options served no purpose.
3. Making the publish status of protected extensions' updates be unmodifiable works against the purpose of having an Update Sites manager, therefore should never be implemented.

Therefore the patch, as it is at the time of me writing this comments, is good. Modifications regarding the protected status must not be made.

Thanks, @nikosdion
One more tester.

The statements and arguments of @nikosdion convinced me.

@test: Works fine, thank you!

RTC based on testing. Thanks!

To merge in 3.4.2 as we are in lang freeze.

Sorry but this PR is completely wrong. The PR is proposing a tooltip that describes what will happen when you click on the button. However in the rest of joomla eg article manager the tooltip is descrbing the current status

JM I have sent you a PR with a small improvement that avoids us to add the JHtml path for each view.

infograf768#15

@brianteeman: Please have a look at the status column of the category manager.

@brianteeman
You are wrong.
This PR implements the same behaviour as what exists for plugins manager, menu items manager, category manager, redirect links manager, etc., i.e. the action to perform when clicking.
As I said in another discussion, we have indeed different kind of tooltips for the item status in some managers (Contacts manager, articles manager.)

Therefore I maintain this PR.

Note: concerning @phproberto PR to my branch, we both agreed that it should be done separately.

Please reset this to RTC

Closing in favour of #7154 where merge conflicts are solved.