-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
Example of PR titles that include pivotal stories:
|
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", |
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 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)
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 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.
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.
Fixed in 988385e
…rvice discrimination
b2e90ed
to
15c1873
Compare
Sorry, I try to explain it better |
b01aa13
to
65430ec
Compare
* A missing Activation is equal to an INACTIVE one. | ||
* | ||
* @param lActivation | ||
* @returns |
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.
that would be nice to describe why we return two lists (left and right part of TaskEither) of BlockedInboxOrChannelEnum
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.
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
)
)
)
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.
a comment was added in 0b1169e
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.
it depends on the usage, if you only use one side returning a Task
would be better (or using never
).
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 prefer the function to return a Task<ReadonlyArray<BlockedInboxOrChannelEnum>>
too
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.
TaskEither
was replaced by a Task
in 06a1b5c
ProcessMessage/handler.ts
Outdated
// 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)({ |
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.
return getActivationForSpecialServices(lActivation)({ | |
return getBlockedInboxesForSpecialService(lActivation)({ |
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.
Fixed in 0b1169e
ProcessMessage/handler.ts
Outdated
return getActivationForSpecialServices(lActivation)({ | ||
blockedInboxOrChannel, | ||
context, | ||
createdMessageEvent, |
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.
it looks like you only need the senderServiceId
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.
Fixed in 0b1169e
Co-authored-by: Danilo Spinelli <gunzip@users.noreply.github.com>
Co-authored-by: Danilo Spinelli <gunzip@users.noreply.github.com>
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.
LGTM
* A missing Activation is equal to an INACTIVE one. | ||
* | ||
* @param lActivation | ||
* @returns |
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 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 |
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.
It's not clear to me how "being admin" is ensured in this 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.
Good point. I've tried to extend the comment in f2482cb
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
List of Changes
Upgrade
io-functions-commons
dependency for SpecialServicesCreateMessage 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