Add dblog-specific permissions to control access to dblog routes

Adding a patch for 10.3.x (that's our current branch) in case anyone else can use it.

Updated the patch as I missed a couple uses of the 'access site reports' permission.

One more new version of the patch. I forgot to add dblog.permissions.yml to the previous versions.

So I wonder if we will need an upgrade hook for the view change, maybe not though since we aren't removing a permission.

The update hook will need test coverage though.

Probably need to expand on the existing tests too that if I have 'access site reports' then I can't access the logs
And other side if I have 'access dblogs reports' then I can still get to the "Reports" tab but it only contains the one link

Appears to have test failures also.

@smustgrave Thank you for the suggestions and I apologize it took me so long to circle back to this.

Here's a summary of the latest changes:

• Added an update hook to update the Watchdog view if it uses the default permissions (I assume we want to leave it alone if the site owner has customized it).
• Added test coverage for the update hook (the test coverage checks the permission on the Watchdog view before and after the update).
• Added test coverage to check if a user with the 'access site reports' permission can see the Reports menu item in the admin toolbar.
• Added test coverage to check if a user with the 'access dblog reports' permission can access the Recent log messages page.

This is the first time I've written these types of tests, so please double-check them and let me know if anything is missing or incorrect.

Also, I haven't addressed the test failures yet. I hope to do so within the next couple days.

@smustgrave I finally got the tests completed and all are now passing. Would you take another look at it and let me know if any other changes need to be made?

@jsutta Thanks for the patch!

There are a few files that are outside dblog but will need an upgrade as well:

Here are a bunch of patters to check:

rg 'dblog' | rg 'access site reports'

modules/update/update.report.inc:  if (\Drupal::moduleHandler()->moduleExists('dblog') && \Drupal::currentUser()->hasPermission('access site reports')) {
modules/system/system.theme.inc:  if (\Drupal::moduleHandler()->moduleExists('dblog') && \Drupal::currentUser()->hasPermission('access site reports')) {
modules/ckeditor5/src/SmartDefaultSettings.php:      $can_access_dblog = ($this->currentUser->hasPermission('access site reports') && $this->moduleHandler->moduleExists('dblog'));
modules/locale/locale.batch.inc:      if (\Drupal::moduleHandler()->moduleExists('dblog') && \Drupal::currentUser()->hasPermission('access site reports')) {
modules/locale/locale.bulk.inc:        if (\Drupal::moduleHandler()->moduleExists('dblog') && \Drupal::currentUser()->hasPermission('access site reports')) {

And the following files reference the dblog routing as well, so it may be worth to check the permissions there:

lib/Drupal/Core/Routing/routing.api.php:1
modules/system/tests/src/Functional/Menu/BreadcrumbTest.php:1
modules/system/tests/src/Functional/File/FileSaveHtaccessLoggingTest.php:1
modules/system/tests/src/Functional/Pager/PagerTest.php:4
modules/migrate_drupal/tests/fixtures/drupal7.php:4
modules/search/tests/src/Functional/SearchNumberMatchingTest.php:1
modules/search/tests/src/Functional/SearchNumbersTest.php:1
modules/search/tests/src/Functional/SearchConfigSettingsFormTest.php:2
modules/user/tests/src/Functional/UserPermissionsTest.php:1
modules/filter/tests/src/Functional/FilterAdminTest.php:2
modules/contact/tests/src/Functional/ContactPersonalTest.php:1
modules/contact/tests/src/Functional/ContactSitewideTest.php:1
tests/fixtures/config_install/multilingual/views.view.watchdog.yml:2
modules/migrate_drupal_ui/tests/src/Functional/MigrateUpgradeExecuteTestBase.php:1
modules/file/tests/src/Functional/SaveUploadTest.php:1
modules/file/tests/src/Functional/SaveUploadFormTest.php:1
tests/Drupal/FunctionalTests/Theme/ClaroTest.php:1

@dagmar Thank you for the catches! I've added the access dblog reports permission in the other locations where the access site reports was already being used, with one exception:

In modules/migrate_drupal_ui/tests/src/Functional/MigrateUpgradeExecuteTestBase.php: The user in this test is the root user (uid 1), so should implicitly have all permissions. With that in mind there's no need to set the specific permission.

Thanks @jsutta Please take a look to the rest of the failing tests in https://git.drupalcode.org/issue/drupal-3493583/-/pipelines/461051

@dagmar Thank you for pointing these out. I believe I've fixed all of the failed tests at this point, but please review the results and let me know if I missed anything.

Upgrade path tests seem to be added so removing that tag

Still appears to need a CR so moving to NW for that.

Will let @dagmar do the final review before RTBC as he seems to have more knowledge with this code already.

It seems there is a missing change to do to fix the Nighwatch related tests.

Been picking away at this and I'm at the point where I need some help with the tests.

The only remaining PHPUnit test issues are related to the issue below. I checked the default config for the Watchdog table in views.view.watchdog.yml and found that there's no default class provided. At this point I think fixing this is outside the scope of this issue, but I'm more than happy to fix it if anyone feels it should be included.

The update to add a default table CSS class for view "watchdog" is deprecated in drupal:11.2.0 and is removed from drupal:12.0.0. Profile, module and theme provided configuration should be updated. See <a href="https://www.drupal.org/node/3499943">https://www.drupal.org/node/3499943</a>.

The PHPUnit Functional JavaScript errors are also unrelated:

Behat\Mink\Exception\ExpectationException: The string "Added text format ckeditor5." was not found anywhere in the HTML response of the current page.

As for Nightwatch, the error is below. I don't believe it's related to the changes in this issue:

An error occurred while running .click() command on <input[name="i5byg6bay[administer modules]"]>: element click intercepted: Element <input class="rid-i5byg6bay js-rid-i5byg6bay form-checkbox" data-drupal-selector="edit-i5byg6bay-administer-modules" type="checkbox" id="edit-i5byg6bay-administer-modules" name="i5byg6bay[administer modules]" value="1"> is not clickable at point (674, 52). Other element would receive the click: <th class="checkbox">...</th>

I'm happy to continue digging into the test results, but at this point I don't feel like there's much more I can do.

@jsutta I think the problem here is the way we are updating the Watchdog table. Potentially any other view could be be using the access dblog reports permission and we want to make sure those views are updated as well.

The way this is done is via the ViewsConfigUpdater. See for example this function

Converting the code from dblog_update_112002 into the ViewsConfigUpdater should point you in the right direction.