Skip to content

[Notifier] Change notifier recipient handling #35773

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

Merged
merged 1 commit into from
Aug 7, 2020

Conversation

jschaedl
Copy link
Contributor

@jschaedl jschaedl commented Feb 18, 2020

Q A
Branch? master
Bug fix? no
New feature? yes
Deprecations? no
Tickets Fix #35558
License MIT
Doc PR tbd.

According to @wouterj's reasoning in #35558 I did the following to merge the AdminRecipient with the Recipient class:

  • introduced a EmailRecipientInterface with getEmail(): string methods
  • introduced a RecipientInterface that is extended by EmailRecipientInterface and SmsRecipientInterface
  • changed Recipient class which now holds an email and a phone number property and implements the EmailRecipientInterface and the SmsRecipientInterface
  • changed NoRecipient class which now implements the RecipientInterface
  • removed the AdminRecipient and fixed all related type-hints
  • introduced an EmailRecipient and SmsRecipient
  • changed the type-hint of the $recipient argument in NotifierInterface::send(), Notifier::getChannels(), ChannelInterface::notifiy() and ChannelInterface::supports() to RecipientInterface
  • changed the type hint of the $recipient argument in the as*Message() of the EmailNotificationInterface and SmsNotificationInterface which now uses the introduced interfaces
  • changed the type hint of the $recipient argument in the static fromNotification() factory methods in EmailMessage and SmsMessage which now uses the introduced interfaces
  • changed EmailChannel to only support recipients which implement the EmailRecipientInterface
  • changed SmsChannel only supports recipients which implement the SmsRecipientInterface

Copy link
Member

@wouterj wouterj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

I think we should mention the changed things (the added methods + interfaces and the removed AdminRecipient class) in the UPGRADE guide. Experimental means we are allowed to break stuff, but we the breaks have to be documented afaik.

Copy link
Contributor

@OskarStark OskarStark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you check the current bridge implementations if there are some changes needed?

@jschaedl
Copy link
Contributor Author

@OskarStark

Did you check the current bridge implementations if there are some changes needed?

Yes I checked the bridges too. All should be good there.

@nicolas-grekas nicolas-grekas added this to the next milestone Feb 20, 2020
@jschaedl jschaedl requested a review from fabpot February 23, 2020 15:14
@jschaedl jschaedl mentioned this pull request Feb 24, 2020
6 tasks
Copy link
Member

@xabbuh xabbuh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having hasEmail() and hasPhone() methods does not look right to me. I'd prefer dedicated classes that only implement EmailRecipientInterface and/or SmsRecipientInterface when the required data is actually present.

@jschaedl jschaedl force-pushed the notifier-recipient branch 2 times, most recently from 21bbb8d to 72cb155 Compare February 28, 2020 12:20
@jschaedl
Copy link
Contributor Author

jschaedl commented Feb 28, 2020

According to @xabbuh comment

Having hasEmail() and hasPhone() methods does not look right to me. I'd prefer dedicated classes that only implement EmailRecipientInterface and/or SmsRecipientInterface when the required data is actually present.

I gave it a try and introduced EmailRecipient and SmsRecipient in addition to the Recipient class: 7df6936

I also made sure that the different Recipient objects are always in a valid state to be able to remove the check for a non empty email and phone in the EmailChannel and SmsChannel.

Some tests were added as well: f45f246

I think this solution could be the way to go. WDYT?

P.S.: No idea why the AppVeyor build is failing.

@jschaedl jschaedl requested a review from xabbuh March 1, 2020 21:59
@jschaedl jschaedl force-pushed the notifier-recipient branch 2 times, most recently from 5dfc57b to fd0b2d5 Compare March 6, 2020 17:01
@jschaedl jschaedl force-pushed the notifier-recipient branch 2 times, most recently from f718a5f to d66a235 Compare March 8, 2020 09:51
fabpot added a commit that referenced this pull request Mar 16, 2020
This PR was merged into the 5.0 branch.

Discussion
----------

[Notifier] Add unit tests

| Q             | A
| ------------- | ---
| Branch?       | 5.0
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | - <!-- prefix each issue number with "Fix #", if any -->
| License       | MIT
| Doc PR        | - <!-- required for new features -->

- [x] `AbstractChannel`
- [x] `ChannelPolicy`
- [x] `RecipientTest` (done in PR #35773)
- [x] `EmailRecipientTest` (done in PR #35773)
- [x] `SmsRecipientTest` (done in PR #35773)
- [x] `Transports` (see PR #35834)

Commits
-------

022c170 [Notifier] Add tests for AbstractChannel and ChannelPolicy
@jschaedl
Copy link
Contributor Author

@fabpot Thanks for your review. I hope I addressed all of your comments :-) See: 9368554


public function __construct(string $email = '')
public function __construct(string $email = '', string $phone = '')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When setting the phone to an empty string, it will be passed anyway to SMS transports as it implements the interface. Before, we checked for a non-empty phone, which I think must be kept.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think keeping the non-empty phone check would mean if I forgot to set a phone number even though I would like to send a SmsMessage, the SmsChannel would be skipped and I don't get any information why my notification was not sent as sms.

I would suggest a different approach: We could make the creation of SmsMessage more strict and throw an InvalidArgumentException with a proper exception message in case the $phone argument is empty. We could apply the same to EmailMessage

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fabpot WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you forgot to enforce a non-empty phone on SmsMessage (and the same for the other messages), right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh no 🙈 thats true. On it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed: d11567f

@jschaedl jschaedl force-pushed the notifier-recipient branch from 7c45d7b to ca644f9 Compare June 12, 2020 13:20
Copy link
Member

@fabpot fabpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay.

@@ -4,11 +4,24 @@ CHANGELOG
5.1.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5.2

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved: 1dab3f5

`RecipientInterface`.
* Changed `EmailChannel` to only support recipients which implement the `EmailRecipientInterface`.
* Changed `SmsChannel` to only support recipients which implement the `SmsRecipientInterface`.
* Added the Mattermost notifier bridge.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not related

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will revert it.

{
if (empty(trim($email)) && empty(trim($phone))) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We try to avoid empty in Symfony. Also, I would not trim the value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjusted: 1dab3f5

@@ -35,8 +44,13 @@ public function email(string $email): self
return $this;
}

public function getEmail(): string
/**
* @return $this
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep the comment that was part of the interface: Sets the phone number (no spaces, international code like in +3312345678).

Copy link
Contributor Author

@jschaedl jschaedl Aug 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment added: 1dab3f5


public function __construct(string $email = '')
public function __construct(string $email = '', string $phone = '')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me.

@jschaedl jschaedl force-pushed the notifier-recipient branch 2 times, most recently from a31b649 to 1dab3f5 Compare August 7, 2020 05:54
@jschaedl
Copy link
Contributor Author

jschaedl commented Aug 7, 2020

Hi @fabpot thanks for your review :-)

I made the requested changes and rebased the branch on master. fabbot.io is complaining though, but it looks like a false positive again.

@@ -17,7 +17,8 @@
],
"require": {
"php": ">=7.2.5",
"symfony/polyfill-php80": "^1.15"
"symfony/polyfill-php80": "^1.15",
"psr/log": "~1.0"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recognized this was missing, because the EmailMessageTest failed locally while using the Notification class that depends on psr/log.

@@ -0,0 +1,24 @@
<?php

declare(strict_types=1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be removed everywhere, we're using that in Symfony.

@fabpot
Copy link
Member

fabpot commented Aug 7, 2020

Thank you @jschaedl.

@fabpot fabpot force-pushed the notifier-recipient branch from d11567f to 588607b Compare August 7, 2020 08:44
@fabpot fabpot merged commit 7520884 into symfony:master Aug 7, 2020
jschaedl added a commit to jschaedl/symfony-docs that referenced this pull request Aug 7, 2020
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.2 Oct 5, 2020
@fabpot fabpot mentioned this pull request Oct 5, 2020
@nicolas-grekas
Copy link
Member

This PR is missing corresponding entries in UPGRADE-5.2.md
@jschaedl would you mind sending a PR to fix this, please?

@jschaedl
Copy link
Contributor Author

@nicolas-grekas here you go: #38691

fabpot added a commit that referenced this pull request Oct 24, 2020
…og (jschaedl)

This PR was merged into the 5.x branch.

Discussion
----------

[Notifier] Add missing upgrade entries and fixed changelog

| Q             | A
| ------------- | ---
| Branch?       | 5.x
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       |  <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License       | MIT
| Doc PR        | <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.

Additionally (see https://symfony.com/releases):
 - Always add tests and ensure they pass.
 - Never break backward compatibility (see https://symfony.com/bc).
 - Bug fixes must be submitted against the lowest maintained branch where they apply
   (lowest branches are regularly merged to upper ones so they get the fixes too.)
 - Features and deprecations must be submitted against branch 5.x.
-->

Follow-up of #35773

Commits
-------

c6b32cd add missing upgrade entries and fixed changelog
@jschaedl jschaedl deleted the notifier-recipient branch June 2, 2021 20:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Notifier] Rename/Change AdminRecipient class
7 participants