-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Slack notifications #730
Conversation
} | ||
|
||
// Set up the payload | ||
$payload = array( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suuuper minor nit, but can we use array literal notation [
/]
in new code instead of the array()
syntax?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I've mentioned in another comment, I've opted to stick to current conventions in existing code to make it more consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Def will echo what Alec said - our goal should not be consistency, but modernizing the code that we touch to the new 2024 standards. It's going to mean discrepancy between files until we finish our work, but the end result will be a slow march to modernization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm looks like our phpcs settings are not allowing the array literal notation: Short array syntax is not allowed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might need to update that to be similar to the governance plugin here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying we should override the existing WordPress-VIP-Go ruleset to support short array syntax?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's what I'm saying. Adding that exclusion rule that I linked will allow you to use the short array syntax
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in 34906df
So it turns out I had to refactor the entire file anyway because my initial changes triggered some indentation errors in the phpcs diff checks. Simply fixing the indentation on a few select lines obviously wouldn't work so I had to fix the indent of the entire class which then increased the size of the diff so I had to fix everything. Now the only things remaining are some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of the below points have to be done in this PR, they are for follow up PRs.
Some notes I noted while testing the UI:
- The UI is tuned towards sending email notifications to a user or group. If none of those are to checked then there is a default message of "no one will be notified" that's to be displayed. In the follow up PRs this is something we should address if send to webhook is enabled.
- For cleaning up the email UI, I'm thinking we introduce a checkbox that says email enabled whose default value is true. If you want, you can flip it to false and that will hide that meta box entirely.
We can make the webhook functionality a bit more robust with the following:
- We should have some sort of disabling functionality for the webhook, in the event that it fails more than once. That way, we don't need to retry it and they'd need to go in and fix the URL or the problem instead.
- We should also introduce a retry functionality
- Right now it's a synchronous call if I'm correct. Could we consider switching to an async call so it's not blocking?
$user = get_userdata( $user )->user_login; | ||
} | ||
|
||
$post_args = array( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hitting save on VSCode for me changes the formatting slightly for this block of code. Running PHPCS doesn't bring up anything though, so I think this might be prettify doing that?
$args = array( | ||
'title' => __( 'Notifications', 'edit-flow' ), | ||
'short_description' => __( 'Update your team of important changes to your content.', 'edit-flow' ), | ||
'extended_description' => __( 'With email notifications, you can keep everyone updated about what’s happening with a given content. Each status change or editorial comment sends out an email notification to users subscribed to a post. User groups can be used to manage who receives notifications on what. With webhook notifications, all notifications will also be sent to the specified webhook URL(i.e.: Slack incoming webhooks).', 'edit-flow' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This description should be tweaked a touch to reflect that notifications is the purpose of this module and that's done in two ways:
- Email to a group or a batch of users
- Webhook which isn't piped to a specific group or a batch
Right now that's slightly confusing, since webhook flow doesn't support users/groups.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed in 69676fd
// Calendar and Story Budget | ||
add_filter( 'ef_calendar_item_actions', array( $this, 'filter_post_row_actions' ), 10, 2 ); | ||
add_filter( 'ef_story_budget_item_actions', array( $this, 'filter_post_row_actions' ), 10, 2 ); | ||
'settings_help_sidebar' => __( '<p><strong>For more information:</strong></p><p><a href="http://editflow.org/features/notifications/">Notifications Documentation</a></p><p><a href="http://wordpress.org/tags/edit-flow?forum_id=10">Edit Flow Forum</a></p><p><a href="https://github.com/danielbachhuber/Edit-Flow">Edit Flow on Github</a></p>', 'edit-flow' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: We should change the danielbachhuber to automattic here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed in 69676fd
'headers' => array( 'Content-Type' => 'application/json' ), | ||
) | ||
); | ||
if ( is_wp_error( $response ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to test the error pathway by giving an invalid webhook url, and the commenting system just hangs as a result. It seems like it's not able to parse the ajax response, and as a result it just gets stuck on an endless spinner. This seems like it's happening in the editorial-comments.js.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition, should we print the ajax response? Wondering if that would reveal some sensitive info, and instead if we should just say that "Sending to webhook failed" and instead send some extra debugging info to the error logs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've fixed the error handling to not hang the UI in 57a6806 but the error display is kinda terrible. I've tried to style it as best as I can but I'm still no happy with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we ran a check when the webhook was saved, so we could show the error message then and there? That way, it's easy to prevent a save if the webhook is invalid and we could change this to something like "Unable to send notification to webhook provided"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean by that @ingeniumed, can you give an example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what I'm suggesting is two fold:
- When the slack webhook url is provided, and the save button is pressed we run a test on that url. We post a test message that says "Integrated successfully with EditFlow". If this doesn't happen, the save fails then and there. This will reduce the chances of failures happening down the line (doesn't eliminate it but sure helps).
- When a notification fails to be sent in the block editor, we change the error that's shown to be more specific i.e. "Unable to send notification to webhook provided".
Hope that clears up what I mean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha. I get it now 👍
Added and additional filter to filter URL if necessary and added some contextual objects to make the filters more useful.
Changed to be more inline with the VIP governance plugin
<div id="ef-post_following_box"> | ||
<a name="subscriptions"></a> | ||
|
||
<p><?php _e( 'Select the users and user groups that should receive notifications when the status of this post is updated or when an editorial comment is added.', 'edit-flow' ); ?></p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add email notifications here so it's clear that webhook doesn't count.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed in 902bc04
This reverts commit 81fa03c.
Specifically mention that users and user groups are for email notfications
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢
Description
This PR adds support for Slack notifications on top of EditFlow's existing email notifications. Currently we're only planning to support Slack's incoming webhook API.
Steps to Test
You would need to create a Slack app on your own workspace and enable Incoming Webhooks for that app.
Send to Webhook
and add in the webhook URL.