[APB-11045][APB-APB-11015] Success and FailedNonFixable emails#63
[APB-11045][APB-APB-11015] Success and FailedNonFixable emails#63gitwojciech wants to merge 47 commits intomainfrom
Conversation
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
# Conflicts: # app/uk/gov/hmrc/agentregistration/shared/risking/IndividualRiskingResponse.scala # app/uk/gov/hmrc/agentregistrationrisking/model/IndividualForRisking.scala # test/uk/gov/hmrc/agentregistrationrisking/testsupport/testdata/TdApplicationForRisking.scala # test/uk/gov/hmrc/agentregistrationrisking/testsupport/testdata/TdIndividualForRisking.scala
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
# Conflicts: # app/uk/gov/hmrc/agentregistrationrisking/controllers/SubmitForRiskingController.scala # app/uk/gov/hmrc/agentregistrationrisking/testOnly/controllers/controllers/TestRiskingController.scala # test/uk/gov/hmrc/agentregistrationrisking/testsupport/testdata/TdSdesProxy.scala
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
# Conflicts: # app/uk/gov/hmrc/agentregistrationrisking/controllers/SdesNotificationController.scala # app/uk/gov/hmrc/agentregistrationrisking/services/ApplicationStatusService.scala
…merge with 11100WIP testing failing
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
# Conflicts: # app/uk/gov/hmrc/agentregistrationrisking/testOnly/controllers/controllers/TestRiskingController.scala
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
# Conflicts: # test/uk/gov/hmrc/agentregistrationrisking/controllers/SdesNotificationControllerSpec.scala # test/uk/gov/hmrc/agentregistrationrisking/repository/ApplicationForRiskingRepoSpec.scala # test/uk/gov/hmrc/agentregistrationrisking/scheduler/RiskingSchedulerInitializerSpec.scala # test/uk/gov/hmrc/agentregistrationrisking/services/SubscriptionServiceSpec.scala # test/uk/gov/hmrc/agentregistrationrisking/testsupport/testdata/TdAll.scala
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
Signed-off-by: pav <173694350+paweldigital@users.noreply.github.com>
# Conflicts: # app/uk/gov/hmrc/agentregistrationrisking/controllers/SdesNotificationController.scala # app/uk/gov/hmrc/agentregistrationrisking/repository/ApplicationForRiskingRepo.scala # app/uk/gov/hmrc/agentregistrationrisking/services/ApplicationStatusService.scala # app/uk/gov/hmrc/agentregistrationrisking/services/SubscriptionService.scala
# Conflicts: # app/uk/gov/hmrc/agentregistrationrisking/controllers/SdesNotificationController.scala
|
| ) | ||
| ).toFuture() | ||
|
|
||
| // def findReadyForSubscription(): Future[Seq[ApplicationForRisking]] = collection |
There was a problem hiding this comment.
I was wondering what the purpose of this commented-out code is.
| * limitations under the License. | ||
| */ | ||
|
|
||
| ///* |
There was a problem hiding this comment.
I was wondering if there’s any value in keeping these commented-out files, as they don’t seem to serve a purpose, or am I missing something? I have a small suggestion to consider removing them, and perhaps we could also avoid including similar unused or commented-out files in the future, if that’s not an issue of course.
| )(using ExecutionContext) | ||
| extends RequestAwareLogging: | ||
|
|
||
| def sendEmail(emailInformation: EmailInformation)(using RequestHeader): Future[Unit] = emailConnector.sendEmail(emailInformation) |
There was a problem hiding this comment.
I was wondering if there’s any particular reason this method is exposed in the service. It seems to be used only internally, so I was thinking it might be worth considering whether it could be made private or inlined, especially since it relies on an underlying private connector to send emails. From an encapsulation perspective, it might help improve the structure of the code if we clean this up a bit, if that makes sense.
| import play.api.libs.json.Json | ||
| import play.api.libs.json.OFormat | ||
|
|
||
| final case class EmailInformation( |
There was a problem hiding this comment.
Could we consider renaming EmailInformation to SendEmailRequest to better reflect that it represents the actual HTTP request used when calling the email microservice? It seems we already follow this naming convention in other connectors, so it might be good to stay consistent with that.
| import play.api.libs.json.OFormat | ||
|
|
||
| final case class EmailInformation( | ||
| to: Seq[String], |
There was a problem hiding this comment.
I was wondering if it might be worth using a dedicated type for the email address, such as EmailAddress, instead of a plain String. It already seems to handle the necessary JSON serialization, and it could make the code more type-safe overall.
to: Seq[String] feels a bit unclear compared to to: Seq[EmailAddress], does it?
|
|
||
| final case class EmailInformation( | ||
| to: Seq[String], | ||
| templateId: String, |
There was a problem hiding this comment.
Could we consider using a dedicated type for this as well? Since we only have a small set of email template values, it might make sense to model them as an enum. That way, we could reduce the risk of passing incompatible or unsupported values.
| eventUrl: Option[String] = None, | ||
| onSendUrl: Option[String] = None |
There was a problem hiding this comment.
I was wondering if those fields are still needed, as they don’t seem to be used anywhere. Maybe it would make sense to remove them to avoid maintaining code that isn’t actually in use?
| Filters.eq("isSubscribed", true), | ||
| Filters.eq("isEmailSent", false) |
There was a problem hiding this comment.
Could we consider using a FieldNames object to define these fields? It makes them easier to manage and help avoid typos in queries, especially since this has already happened in the project before.
No description provided.