Skip to content
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

[#IC-49] Porting SpecialServices to new ProcessMessage flow #172

Merged
merged 12 commits into from
Dec 1, 2021

Conversation

BurnedMarshal
Copy link
Contributor

List of Changes

Upgrade io-functions-commons dependency for SpecialServices
CreateMessage flow now have serviceCategory to handle Standard and Special service preferences check.
Only admin can create and edit SpecialService properties.

Motivation and Context

The io-functions-services should handle Standard and Special services. This PR upgrade specifications and models to do that.
When a message is created for a Special Service to evaluate if INBOX is enabled for a User, Activation model is used to retrieve Special Service activation.

How Has This Been Tested?

unit test

Screenshots (if appropriate):

Types of changes

  • Chore (nothing changes by a user perspective)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

@pagopa-github-bot
Copy link
Contributor

pagopa-github-bot commented Nov 22, 2021

Warnings
⚠️ This PR changes a total of 430 LOCs, that is more than a reasonable size of 250. Consider splitting the pull request into smaller ones.
⚠️ Please include a Pivotal story at the beginning of the PR title (see below).

Example of PR titles that include pivotal stories:

  • single story: [#123456] my PR title
  • multiple stories: [#123456,#123457,#123458] my PR title

Generated by 🚫 dangerJS against f2482cb

ProcessMessage/handler.ts Outdated Show resolved Hide resolved
UpdateService/handler.ts Outdated Show resolved Hide resolved
openapi/index.yaml Show resolved Hide resolved
package.json Outdated
@@ -20,7 +20,7 @@
"generate": "npm-run-all generate:*",
"generate:definitions": "rimraf ./generated/definitions && shx mkdir -p ./generated/definitions && gen-api-models --api-spec ./openapi/index.yaml --no-strict --out-dir ./generated/definitions",
"generate:api-notifications": "rimraf ./generated/notifications && shx mkdir -p ./generated/notifications && gen-api-models --api-spec https://raw.githubusercontent.com/pagopa/io-backend/master/api_notifications.yaml --out-dir ./generated/notifications --response-decoders --request-types",
"generate:api-admin": "rimraf generated/api-admin && shx mkdir -p generated/api-admin && gen-api-models --api-spec https://raw.githubusercontent.com/pagopa/io-functions-admin/master/openapi/index.yaml --no-strict --out-dir generated/api-admin --request-types --response-decoders --client",
"generate:api-admin": "rimraf generated/api-admin && shx mkdir -p generated/api-admin && gen-api-models --api-spec https://raw.githubusercontent.com/pagopa/io-functions-admin/IC-40-special-service-model-upgrade/openapi/index.yaml --no-strict --out-dir generated/api-admin --request-types --response-decoders --client",
Copy link
Contributor

Choose a reason for hiding this comment

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

We won't merge a specific branch. Consider:

  • generate code from master (as it used to be)
  • generate code from a specific version (good)
  • import sdk package (better)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You have right. This should be changed to master when the pagopa/io-functions-admin#172 is merged.
If we want to move to sdk import version I think is better do the refactory on another PR.

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 in 988385e

@BurnedMarshal BurnedMarshal force-pushed the IC-49-special-services-bis branch from b2e90ed to 15c1873 Compare November 22, 2021 14:17
@BurnedMarshal
Copy link
Contributor Author

override with what? (why?) it's not very clear form the comment how this works

Sorry, I try to explain it better

@BurnedMarshal
Copy link
Contributor Author

override with what? (why?) it's not very clear form the comment how this works

Sorry, I try to explain it better

@gunzip I've fixed the comments 2ca3a1a. Tell me if now is more clear.

@BurnedMarshal BurnedMarshal force-pushed the IC-49-special-services-bis branch from b01aa13 to 65430ec Compare November 22, 2021 14:37
* A missing Activation is equal to an INACTIVE one.
*
* @param lActivation
* @returns
Copy link
Contributor

Choose a reason for hiding this comment

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

that would be nice to describe why we return two lists (left and right part of TaskEither) of BlockedInboxOrChannelEnum

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If you think that is more clear we can return a TaskEither<never, ReadonlyArray<BlockedInboxOrChannelEnum>> changing the last part of the chain like this:

TE.chainW(
  TE.fromPredicate(hasActiveActivation => hasActiveActivation, identity)
),
TE.fold(
  () =>
    TE.of(
      blockedInboxOrChannel.includes(BlockedInboxOrChannelEnum.INBOX)
        ? blockedInboxOrChannel
        : [...blockedInboxOrChannel, BlockedInboxOrChannelEnum.INBOX]
    ),
  () =>
    TE.of(
      blockedInboxOrChannel.filter(
        el => el !== BlockedInboxOrChannelEnum.INBOX
      )
   )
)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

a comment was added in 0b1169e

Copy link
Contributor

Choose a reason for hiding this comment

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

it depends on the usage, if you only use one side returning a Task would be better (or using never).

Copy link
Contributor

Choose a reason for hiding this comment

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

I prefer the function to return a Task<ReadonlyArray<BlockedInboxOrChannelEnum>> too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

TaskEither was replaced by a Task in 06a1b5c

ProcessMessage/handler.ts Outdated Show resolved Hide resolved
ProcessMessage/handler.ts Outdated Show resolved Hide resolved
// If the service has category equals to SPECIAL, the INBOX value in blockedInboxOrChannel depends from the Activation
// value. If the SPECIAL service is ACTIVE (exists an activation for couple user/service with ACTIVE status)
// we remove INBOX from blockedInboxOrChannel, otherwise we add the INBOX value.
return getActivationForSpecialServices(lActivation)({
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
return getActivationForSpecialServices(lActivation)({
return getBlockedInboxesForSpecialService(lActivation)({

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 in 0b1169e

return getActivationForSpecialServices(lActivation)({
blockedInboxOrChannel,
context,
createdMessageEvent,
Copy link
Contributor

Choose a reason for hiding this comment

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

it looks like you only need the senderServiceId

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 in 0b1169e

BurnedMarshal and others added 3 commits November 22, 2021 19:37
Co-authored-by: Danilo Spinelli <gunzip@users.noreply.github.com>
Co-authored-by: Danilo Spinelli <gunzip@users.noreply.github.com>
Copy link
Contributor

@gquadrati gquadrati left a comment

Choose a reason for hiding this comment

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

LGTM

* A missing Activation is equal to an INACTIVE one.
*
* @param lActivation
* @returns
Copy link
Contributor

Choose a reason for hiding this comment

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

I prefer the function to return a Task<ReadonlyArray<BlockedInboxOrChannelEnum>> too

...servicePayload.service_metadata,
token_name: adb2cTokenName
}
// Only Admins can change service category and custom_special_flow name
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not clear to me how "being admin" is ensured in this flow

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. I've tried to extend the comment in f2482cb

@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 1, 2021

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@BurnedMarshal BurnedMarshal merged commit 2a71f91 into master Dec 1, 2021
@BurnedMarshal BurnedMarshal deleted the IC-49-special-services-bis branch December 1, 2021 14:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants