Update notification messages as an option in settings

+++ b/core/modules/update/lib/Drupal/update/UpdateSettingsForm.phpundefined
@@ -44,6 +44,12 @@ public function buildForm(array $form, array &$form_state) {
+      '#title' => t('Enable Update module system notifications'),
+      '#default_value' => $config->get('check.update_system_notifications'),

Do you think we could do with a description here too? Maybe this is a question for the UX guys.

+++ b/core/modules/update/update.moduleundefined
@@ -99,7 +99,7 @@ function update_help($path, $arg) {
+  if (arg(0) == 'admin' && user_access('administer site configuration') && config('update.settings')->get('check.update_system_notifications')) {

Can we use the method on the Drupal class instead please. i.e. Drupal::config('update.settings')

@@ -145,6 +145,7 @@ function _update_requirement_check($project, $type) {
+    'update_system_notifications' => 'check.update_system_notifications',

This should be removed and re-added in a follow-up when/if backport is committed to D7.

This patch might have security implications. I can imagine site admins that would permanently uncheck this, which could result in their site using without necessary security upgrades. I would add a warning into description that would suggest admins to have this enabled at all times.

I agree with @alesr. People will try to disable those warnings one way or another if they decide to. It is much better to introduce sane way to do it.

Description could be something like this:

Messages about available updates will not be displayed if this checkbox is unchecked. Disabling it may have security implications.

I really dislike the system message especially when demonstrating a system to clients. I want to retain the Update Manger for installing module directly but does NOT want the system message to appear prompting the users from time to time. The clients thought of having system problems during demonstration. It's totally annoying without a way to disable it. Thanks

Will this be updated into D7 Core ? Now keeping a log of all patched modules coz always having to re-apply the same patches after upgrading to a newer version. Thanks

reroll

+++ b/core/modules/update/src/UpdateSettingsForm.php
@@ -52,6 +52,13 @@ public function buildForm(array $form, FormStateInterface $form_state) {
+      '#description' => t('Messages about available updates will not be displayed if this checkbox is unchecked. Checked by default.'),

I think we could probably use a more stern warning here and lose the message about the default value.

- Reroll for 8.2.x.
- URL of settings page added to issue summary.
- Probably needs tests.

Cannot reproduce in 8.3.x/8.4.x, it is not an issue anymore (the warning message is not displayed on all config pages, just on the status report page and the Update Manager's list of available updates).

Security patches still show a warning message so I'm reopening and adding rerolled patch for 8.4.x.

We must not have the warning message disabled by default, so we must add an update path to set that option to TRUE.

...or you can re-label and repurpose the checkbox, and make it "Hide system notifications about security updates" instead.

Addressed #27. Added the hook_update_N implementation to keep showing messages for existing projects.
#31 In my opinion, for that reason, we need to add a more descriptive message for the user to be sure what action will be performed and how this action affects the site functionality.
Updated title and description for the checkbox. Added test case to be sure that description is built correctly.

Messages are showed, checkbox checked

Messages are hided, checkbox unchecked

Of course, immutable configs. Changed to editable.

+++ b/core/modules/update/update.install
@@ -163,3 +163,13 @@ function update_update_8001() {
+function update_update_8801() {
+  \Drupal::configFactory()
+    ->getEditable('update.settings')

Better move it to post update hook

We're having a conflict with the hook update number in some of our sites. As this patch hasn't received updates recently and most of the people that are using to stop showing the notifications on their sites, I'm removing that hook update in order to stop the conflict.

Sorry, the right patch is this one.

Patch in #41 didn't apply; also, all patches need to go to D9 first and apply to the dev branch, currently 9.2.x.

Addressed #37

Attached interdiff between the commit in MR and #35 after reroll against core 9.2.x

Updated the test

As these messeges are the number 1 reason why update module is disabled, it is critical to resolve this issue.
https://twitter.com/webchick/status/1362569962695446530

This does not meet the criterial for a critical issue.

Apply 23.patch working fine and added Show Update module system notifications in update setting sharing the screenshot

RTBC+1 for MR!73. It works great and is a really important improvement for many clients / users as I wrote in my comment #47 in #332796: Add permissions to the update.module to hide warnings already!

Completely agree with @Pasqualle in #47:

As these messeges are the number 1 reason why update module is disabled

This is IMPORTANT for site owners / clients as they are frightened by this message - but as @xjm correctly said, it's not a critical issue in the Drupal.org definition ... ;)

So please, could we have Core Maintainer feedback here on how to proceed? Do we need a UX review or something like that? We should also finally discuss what to do with #332796: Add permissions to the update.module to hide warnings and if the approach taken here is the right one or if the message should instead be tied to the "Administer software updates" permission as a more simple solution.

Thank you!

Agreed. MR looks good to me.

Rerolled against 9.3.x
Looks good to go

Thanks for all the work here!

I don't want to hold this up indefinitely, but I'd love to take a closer look at both this and #332796: Add permissions to the update.module to hide warnings before either one is committed. We almost certainly don't want both. I don't think we should add a setting for this if we're going to tie it to permissions, anyway. I think we should assess before we proceed. Tagging for myself (or @tedbow) to take another look and weigh in before commit.

Thanks/sorry,
-Derek

Thanks for the comment. I reviewed the issue #332796: Add permissions to the update.module to hide warnings and agreed that it is important for handling update messages.
Adding commit with rerolled patch from #332796: Add permissions to the update.module to hide warnings makes it easy to test in scope to configure notification and introduce permissions simultaneously.

My 51% vote for
a) adding a permission
or
b) alternatively simply tying this to the "administer software updates" permission instead of "administer site configuration" ... (my favorite as it's simple and 99% use-case)

instead of my 49% for an additional setting ;)

but I think it's better to choose any of the options than to wait more years ;) @dww your word has enough weight here to finally decide it :)

Ok, I reverted the last 2 commit to keep the original scope. Turned back the previous issue name.
Cherry-picked permission-related commits to #332796: Add permissions to the update.module to hide warnings fork branch.
So we have two approaches to review.

Thank you very much @voleger for your great work on this. I've created a third - simpler - approach to be discussed: #3239970: Show update notifications only with permission "administer software updates" and added all three to the issue summary.

We now need feedback from the core maintainers which way they'd like to go. I like all three, the problem with THIS issue is, from my perspective, that it introduces a further setting which is possibly not even needed when using the "administer software updates" permission to show or not show the update notifications.

If core maintainers would like to keep this split, adding this setting is a good way and I'd vote for this (RTBC+1). Otherwise, I'd vote for the more simple #3239970: Show update notifications only with permission "administer software updates"

Usability review

We discussed this issue at #3239070: Drupal Usability Meeting 2021-10-01. That issue has a link to a recording of the meeting.

We also reviewed the related issues listed in the issue description. A majority of the usability group preferred the solution in #332796: Add permissions to the update.module to hide warnings, and we had consensus that this behavior should be tied to a permission, not a single option.

We recommend closing this issue as a duplicate, but I leave that to the people who have been working on the three issues.

Thank you @benjifisher,

if it's ok for @voleger I'll now close this issue as duplicate as suggested. We'll have to chose one of the three options and if there's consensus that another is better, let's proceed there :)

Sorry for the delays here. Circling back around. Upon further review/reflection, I agree with the UX team that #332796: Add permissions to the update.module to hide warnings is the best solution to this family of issues. That's the only one still open, so let's concentrate our effort there. Thanks!