Create drush commands to add and remove alerts.

I like this idea!

Some initial questions/thoughts that come to mind on how we would implement this:

• How would we know which alert to enable/disable/delete? Would we make the UUID of the alert be an argument?
• Which entity fields/parameters would be available/required via the command line?
• Which user would we add to these alert entities created by the drush command?

>Which user would we add to these alert entities created by the drush command?

I think Drush runs as user 1. In the use case I am thinking of, there would be no problem with user 1, but there may be a case where it is worth having a User ID as an argument on the command.

I agree. This would be an acceptable approach for the initial versions of these drush commands.

> How would we know which alert to enable/disable/delete? Would we make the UUID of the alert be an argument?

In our use case, we need Jenkins to create an alert and then later delete it. under a different task, so it would have no idea what the UUID is of the first run. It would need to be more generic. like being able to delete by a label or title of some kind.

Labels are not always unique, so that could cause unintended alerts to be enabled(active)/disabled/deleted. Maybe we provide several options/parameters to identify the alert that needs to be acted on. For example: by label, by uuid, and/or by alert author username/id?

> Which entity fields/parameters would be available/required via the command line?

At first glance, I would think all of the default fields would be available, and requiredness would reflect what is required in the UI.

In order to get something functional working, I am okay with limiting the scope of this. For example, the initial version may not need to support all of the features available in the UI, like translated fields or content moderation workflows. With that in mind, we may want to add this functionality as a submodule and label it "experimental".

Here's a first pass at a patch for this feature. It is based heavily on the site_alert module's implementation of this functionality.

The only equivalent test between the two I couldn't port over easily was a test for creating alerts with a start time but no end date... I dropped that one here for now, as both start and end times are required in this module. If only the end value is being passed in, the start time defaults to 'now'.

Sorry for the noise with the git.drupalcode branch... I pushed my code there, but I'm not seeing where in the interface to create a PR with it.. https://git.drupalcode.org/issue/sitewide_alert-3290964/-/tree/2.x ... I may have gone to the wrong branch?

Attaching the patch file to this comment as well just in case.

@tjh, I added your patch to the issue branch you created.

The "Show commands" link above the issue fork can be helpful in making sure you are committing to the right branch.

Tanner,

Thank you for your work on this! I had some time so I took a first pass and left some comments on the PR.

It looks like the tests are not running. We need to get that fixed.

Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC. Rerolled for 2.1. This also fixed our issue.

I messed up the above patch. Here's the correct one.

Attesting that the proposed feature works as intended. However, I've experienced issues running the supplied functional tests for the patch--in one case, I got a "service 'lock' has a dependency on a non-existent service 'memcache.lock.factory'". And in another, "class 'Drupal\Tests\BrowserTestCase' not found" occurred. This may be due to my ignorance or possibly other factors. The patch works fine for my requirements, although I'd encourage others to review and share their experience.

I had to update the patch to add an accessCheck() to the query for the getAlertsByLabel method. Missed that!

And missed one change for the patch.