Allow administrators to administer subscribers of hidden newsletters

This issue really needs to be addressed. At present any newsletters that aren't publicly available for subscription cannot be managed, even by admins. Why even have newsletters that aren't publicly available, since it is impossible to subscribe users to these newsletters?

Anyway, here is a quick fix, in simplenews.module find this function and amend as shown:

function simplenews_category_get_visible() {
  $categories = &drupal_static(__FUNCTION__, NULL);

  if (!isset($categories)) {
    $categories = simplenews_categories_load_multiple(array(), array('show_all' => user_access('administer simplenews subscriptions')));
  }
  return $categories;
}

The change is the addition of user_access('administer simplenews subscriptions'), this was a static value FALSE, which is replaced with the user_access() check to allow any user that has been granted 'administer simplenews subscriptions' permission to be able to edit all subscriptions for the given user.

Hope this helps someone. Ideally this will be added to the module codebase. Granted, I'm using an older version of the module, so maybe it has already been added... and if so, this issue should be closed.

This is also the behavior of the newer versions. I would like to see this adjusted as well.

This is still an issue on 4.x. simplenews_newsletter_get_visible() (via SubscriptionWidget::setAvailableNewsletterIds()) filters out any newsletter with access: hidden unconditionally, with no permission check… so even a user with "Administer simplenews subscriptions" can't manage a subscriber's subscription to a hidden newsletter from /user/{uid}/simplenews or from the subscriber admin add/edit forms (/admin/people/simplenews/create and /edit). All three of those forms share the same SubscriptionWidget field widget on the subscriptions field, so the fix only needs to live in one place.

Rather than reusing "Administer simplenews subscriptions" for this (as originally proposed in #1), I added a new, separate permission: "Manage hidden newsletter subscriptions". Reasoning:

- It keeps this capability opt-in and explicit. Sites that already grant "Administer simplenews subscriptions" broadly (e.g. to support staff) don't automatically get the ability to toggle subscriptions to newsletters that were deliberately hidden from end users, which may include internal/system newsletters.
- It's additive: granting only the existing permission changes nothing. I confirmed the existing testNewsletterSettings test (whose $admin_user only has "Administer simplenews subscriptions") passes unmodified with this patch.

What the patch does:

1. simplenews.permissions.yml -- adds manage simplenews hidden subscriptions.
2. SubscriptionWidget::setAvailableNewsletterIds() -- includes hidden newsletters in the option list when the current user has the new permission (via simplenews_newsletter_get_all() instead of simplenews_newsletter_get_visible()).
3. SubscriptionWidget::getOptions() -- appends "(hidden)" to the label of any newsletter that isn't publicly accessible, so it's obvious in the UI which options are normally invisible to subscribers.
4. Also switched the widget so that it's using DI best pactices because I needed access to the currentUser() object.

Tests: added SimplenewsAdministrationTest::testHiddenNewsletterSubscriptionManagement(), which:

- Confirms an admin without the new permission sees no trace of the hidden newsletter on the account subscriptions page, the subscriber edit form, or the subscriber add form.
- Confirms an admin with the new permission sees it (labeled "(hidden)"), and can subscribe/unsubscribe a user to/from it from both the account subscriptions page and the subscriber admin edit form, with the change persisting.

Ran the full SimplenewsAdministrationTest class locally; this new test and the existing testNewsletterSettings/testAccess all pass. (There are 3 pre-existing failures elsewhere in that class -- testSubscriptionManagement, testContentTypes, testNewsletterIssuesOverview -- unrelated to this change; they reproduce identically without this patch and match failures visible in this issue fork's own CI pipeline, apparently an unrelated text_with_summary/content-type fixture issue against current core.)

Also ran phpcs (module's own standard) and phpstan (this project's default GitLab CI config) against the changed files… both clean.

Thanks

Unfortunately this seems to be breaking from the DI change. The autowiring capability in WidgetBase was only added in D11.4. I raised #3613373: Too few arguments to function Drupal\simplenews\Plugin\Field\FieldWidget\SubscriptionWidget::__construct().