-
Notifications
You must be signed in to change notification settings - Fork 825
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
feat: in app messaging notification #11067
Conversation
This pull request introduces 7 alerts when merging eb3c10e into 6f287b1 - view on LGTM.com new alerts:
|
This pull request introduces 7 alerts when merging de2a2d7 into 6f287b1 - view on LGTM.com new alerts:
|
This pull request introduces 4 alerts when merging de5d49b into f06c821 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging a77f14c into f06c821 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging addef6b into f06c821 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 46a1675 into f06c821 - view on LGTM.com new alerts:
|
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 didn't go through this in depth enough to really get the bigger picture so most of my comments are relatively localized
"logs:CreateLogStream", | ||
"logs:PutLogEvents" | ||
], | ||
"Resource": "arn:aws: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.
we should scope this policy better
packages/amplify-category-analytics/src/plugin-client-api-auth.ts
Outdated
Show resolved
Hide resolved
packages/amplify-category-analytics/src/commands/analytics/remove.ts
Outdated
Show resolved
Hide resolved
packages/amplify-category-notifications/src/notifications-amplify-meta-api.ts
Outdated
Show resolved
Hide resolved
packages/amplify-category-notifications/src/notifications-backend-cfg-api.ts
Outdated
Show resolved
Hide resolved
packages/amplify-category-notifications/src/notifications-backend-cfg-channel-api.ts
Outdated
Show resolved
Hide resolved
packages/amplify-cli/src/extensions/amplify-helpers/get-resource-outputs.ts
Outdated
Show resolved
Hide resolved
packages/amplify-category-notifications/src/legacy-pinpoint-helper.ts
Outdated
Show resolved
Hide resolved
@@ -29,7 +29,8 @@ | |||
"inquirer": "^7.3.3", | |||
"lodash": "^4.17.21", | |||
"ora": "^4.0.3", | |||
"promise-sequential": "^1.1.1" | |||
"promise-sequential": "^1.1.1", | |||
"chalk": "^4.1.1" | |||
}, | |||
"devDependencies": { | |||
"mockirer": "^2.0.1" |
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.
nit: see if we can replace this : https://www.npmjs.com/package/mockirer . package seems not maintained
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 probably should have a separate task to get rid of all inquirer references, this will allow us to remove the mockirer in the same step
packages/amplify-category-notifications/src/legacy-pinpoint-helper.ts
Outdated
Show resolved
Hide resolved
import { | ||
addSMSNotification, |
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.
Is this the only e2e test we have for notifications? if so, what concepts do you think should be verified (what's a good e2e test for this 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.
this is the only one, it used to test just SMS channel and now was changed to do a push/pull for SMS and In-App Messaging channels.
not sure what can we do with a e2e test, but we should test that creating resources with older version and then upgrading to the new implementation and updating/adding new channels work as expected. One of the main changes in this PR is that notifications and analytics no longer create 2 distinct pinpoint resources but whoever will share the same resource, also pinpont resource is always managed by the analytics category so adding a notification category will also add a analytics category with the pinpoint resource.
For the above we should test various combinations for when adding/updating analytics/notifications channgels are mixed and matched with old and new implementation
Other things that could be tested are update and delete for the notifications channels (this tests only tests add)
This pull request introduces 2 alerts when merging 915acd1 into e4593c4 - view on LGTM.com new alerts:
|
packages/amplify-category-notifications/src/multi-env-manager.ts
Outdated
Show resolved
Hide resolved
packages/amplify-category-notifications/src/multi-env-manager.ts
Outdated
Show resolved
Hide resolved
This pull request introduces 2 alerts when merging 50fa878 into e4593c4 - view on LGTM.com new alerts:
|
Codecov Report
@@ Coverage Diff @@
## dev #11067 +/- ##
==========================================
- Coverage 49.64% 49.32% -0.32%
==========================================
Files 666 676 +10
Lines 31923 32628 +705
Branches 6500 6664 +164
==========================================
+ Hits 15848 16094 +246
- Misses 14595 15051 +456
- Partials 1480 1483 +3
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
This pull request introduces 1 alert when merging 104a409 into e4593c4 - view on LGTM.com new alerts:
|
* feat: in app messaging initial commit
… in-app-messaging
This pull request introduces 3 alerts when merging 6c65379 into 85696bd - view on LGTM.com new alerts:
|
This pull request introduces 3 alerts when merging c6a1ac6 into c454ae7 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 6cf7029 into c09e541 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 95c47e3 into 9f3bba7 - view on LGTM.com new alerts:
|
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 some comments but I don't think any of them are merge blockers
* @returns push command response | ||
*/ | ||
export const authPush = async (context: $TSContext): Promise<$TSAny> => { | ||
const { run } = await import(path.join('.', name, 'push')); |
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.
could we turn this into a normal import?
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.
addressed in follow-up PR: #11158
* Execute auth Push command with force yes | ||
* @param {Object} context - The amplify context. | ||
*/ | ||
const authPush = async context => { |
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.
rename to authPushYes
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.
addressed in follow-up PR: #11158
const commandPath = path.normalize(path.join(__dirname, 'commands', category, 'push')); | ||
const commandModule = await import(commandPath); |
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.
static import?
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.
addressed in follow-up PR: #11158
const commandModule = await import(commandPath); | ||
context.exeInfo = (context.exeInfo) || {}; | ||
context.exeInfo.inputParams = (context.exeInfo.inputParams) || {}; | ||
context.exeInfo.inputParams.yes = true; // force yes to avoid prompts |
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.
will this have any downstream impact on other prompts in the original flow? It could also lead to some inconsistencies because amplify-prompter
looks for the --yes
flag in process.argv not in context
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.
not in this particular case, but it is injecting side-effects that could affect future implementation that look at this parameters after this call
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.
addressed restoring the original value after push
export const run = async (context: $TSContext): Promise<$TSAny> => { | ||
try { | ||
const { run } = await import(path.join('.', name, context.parameters.first)); | ||
return run(context); | ||
const { run: authRun } = await import(path.join('.', name, context.parameters.first)); | ||
return authRun(context); |
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 about leaving this as the only function exported by this file and add an optional second parameter to override the action:
export const run = async (context: $TSContext, actionOverride?: 'push'): Promise<$TSAny> => {
try {
const { run: authRun } = await import(path.join('.', name, actionOverride ?? context.parameters.first));
return authRun(context);
updateApnsChannel: jest.fn(() => ({ | ||
promise: () => new Promise((resolve, __) => { | ||
resolve(mockPinpointResponseData); | ||
}), |
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.
nit all of these could simplify to:
updateApnsChannel: jest.fn(() => ({ | |
promise: () => new Promise((resolve, __) => { | |
resolve(mockPinpointResponseData); | |
}), | |
updateApnsChannel: jest.fn().mockReturnValue({ | |
promise: jest.fn().mockResolvedValue(mockPinpointResponseData), | |
}), |
const mockInquirer = (answers : $TSAny): $TSAny => { | ||
(inquirer as any).prompt = async (prompts:$TSAny):Promise<$TSAny> => { | ||
[].concat(prompts).forEach(prompt => { | ||
if (!((prompt as unknown as any).name in answers) && typeof (prompt as unknown as any).default !== 'undefined') { | ||
// eslint-disable-next-line no-param-reassign | ||
answers[(prompt as unknown as any).name] = (prompt as unknown as any).default; | ||
} | ||
}); | ||
return answers; | ||
}; | ||
}; |
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.
can we use jest mocks instead of all this reassigning and type asserting?
* Display status that Auth and Pinpoint resources are being deployed to the cloud | ||
*/ | ||
export const viewShowInlineModeInstructionsStart = async (channelName: string): Promise<void> => { | ||
spinner.start(`Channel ${channelName} requires a Pinpoint resource in the cloud. Proceeding to deploy Auth and Pinpoint resources...`); |
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 probably not worth a bunch of rework at this point but maybe a TODO or backlog item is appropriate
return buildPinpointChannelResponseSuccess(ChannelAction.ENABLE, deploymentType, channelName, data.SMSChannelResponse); | ||
} catch (e) { | ||
spinner.stop(); | ||
throw amplifyFaultWithTroubleshootingLink('NotificationsChannelEmailFault', { |
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 pass the underlying stack into the amplfiy fault as well (applies to lots of places). Not sure how feasible it is to update all of them
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.
Some nits otherwise LGTM!!
Region: pinpointMeta.Region, | ||
} | ||
: undefined; | ||
stateManager.setTeamProviderInfo(projectPath, teamProviderInfo); |
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.
Can use envManager here to populate tpi data
break; | ||
} | ||
default: { | ||
throw Error(`Channel ${notificationChannel} is not supported on Analytics resource`); |
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.
throw Error(`Channel ${notificationChannel} is not supported on Analytics resource`); | |
throw new AmplifyError('ConfigurationError', { | |
message: `Channel ${notificationChannel} is not supported on Analytics resource`, | |
resolution: 'Use one of the supported channels', |
@@ -79,7 +88,7 @@ export const getPermissionPolicies = async (context: $TSContext, resourceOpsMapp | |||
printer.warn(`Could not get policies for ${category}: ${resourceName}`); | |||
throw e; |
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.
nit: We can throw Amplify Error here
* @returns Resource in Notifications category (IAmplifyResource type) | ||
*/ | ||
export const invokeAuthPush = async (context: $TSContext): Promise<void> => { | ||
await context.amplify.invokePluginMethod(context, AmplifyCategories.AUTH, undefined, 'authPluginAPIPush', [context]); |
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.
nit: I think we can directly call context.amplify directly
context.exeInfo.amplifyMeta = await toggleNotificationsChannelAppMeta(channelAPIResponse.channel, false, | ||
context.exeInfo.amplifyMeta); | ||
break; | ||
case ChannelAction.CONFIGURE: |
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.
nit: we can remove the case if the operation is noop
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 should break out instead of printing an error
try { | ||
deployedBackendConfig = (stateManager.getCurrentBackendConfig()) || undefined; | ||
} catch (e) { | ||
appInitialized = false; |
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.
Do we have to throw error here if file operation fails ?
@@ -445,6 +447,13 @@ export const run = async (context: $TSContext, resourceDefinition: $TSObject, re | |||
await context.amplify.updateamplifyMetaAfterPush(resources); | |||
} | |||
|
|||
// Generate frontend resources for any notifications channels enabled on analytics resources. | |||
const analyticsResources = resourcesToBeCreated.filter((r: { category: string; }) => r.category === AmplifyCategories.ANALYTICS); |
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.
const analyticsResources = resourcesToBeCreated.filter((r: { category: string; }) => r.category === AmplifyCategories.ANALYTICS); | |
const analyticsResources = resourcesToBeCreated.filter((resource: { category: string; }) => r.category === AmplifyCategories.ANALYTICS); |
going to address the remaining nits as part of the analytics migration PR: #11158 |
Description of changes
-- adds a new channel for in app messaging
-- changes the place for pinpoint resource to always stay in the analytics category
-- ensures auth and analytics are added as a pre-requirement for the notifications channels
-- notification channels re-use the pinpoint resource from the analytics category
Description of how you validated changes
Checklist
yarn test
passesBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.