Feat #63 accounts language email #5171

jmaver-plume · 2019-05-09T08:34:20Z

Resolves #63
Impact: minor
Type: feature

Issue

Currently all emails are sent based on language (field in mongodb) of the shop account belongs to. This means users cannot specify which language emails they want to receive. Similar for anonymous purchases.

Solution

With this solution:

Users can set their profile language
All emails which are sent to accounts (not anonymous) are in language of their profile
Anonymous Orders can accept optional field language and then emails are sent based on this order email

Overview

If user / order does not have specified account it still looks at shop language to find template.

Added language field in Accounts.profile document
Added language field in Order document
Add graphQL query, mutation, resolvers to set and get language of account
Modify getTemplate and getSubject to accept additional parameter language
Modify functions where getTemplate and getSubject are used to get language for the email

Breaking changes

There are no breaking changes.

Testing

TBD

Signed-off-by: Jaka Maver <[email protected]>

…eter Signed-off-by: Jaka Maver <[email protected]>

…meter Signed-off-by: Jaka Maver <[email protected]>

Signed-off-by: Jaka Maver <[email protected]>

…include language Signed-off-by: Jaka Maver <[email protected]>

Signed-off-by: Jaka Maver <[email protected]>

…ing language Signed-off-by: Jaka Maver <[email protected]>

…before setting it in orders Signed-off-by: Jaka Maver <[email protected]>

Signed-off-by: Jaka Maver <[email protected]>

…anguages Signed-off-by: Jaka Maver <[email protected]>

Signed-off-by: Jaka Maver <[email protected]>

…account shop Signed-off-by: Jaka Maver <[email protected]>

Signed-off-by: Jaka Maver <[email protected]>

…or languages Signed-off-by: Jaka Maver <[email protected]>

aldeed

Good work here. I haven't tested yet, but I reviewed the code and the approach seems solid. There are a few changes necessary for style reasons, but we should be able to test and merge this after that.

aldeed · 2019-06-24T19:41:38Z

imports/plugins/core/orders/server/no-meteor/schemas/schema.graphql

  """
  shopId: String!
+
+  language: String


All fields must have a description and should be alphabetized

aldeed · 2019-06-24T19:41:45Z

imports/plugins/core/orders/server/no-meteor/schemas/schema.graphql

  "The date and time at which this order was last updated"
  updatedAt: DateTime!
+
+  language: String


All fields must have a description and should be alphabetized

aldeed · 2019-06-24T19:43:47Z

imports/plugins/core/orders/server/no-meteor/mutations/placeOrder.js

@@ -1,4 +1,5 @@
 import SimpleSchema from "simpl-schema";
+import R from "ramda";


Single character variables are not allowed by Reaction style rules. I'd recommend just using the standard array .find in this case, though.

aldeed · 2019-06-24T19:45:15Z

imports/plugins/core/orders/server/no-meteor/mutations/placeOrder.js

+
+  // set to undefined value so order language will not be set
+  if (!shopLanguage) {
+    language = undefined;


Throwing a helpful error would be better so they aren't confused why the language they specified isn't set.

aldeed · 2019-06-24T19:54:30Z

imports/plugins/core/accounts/server/methods/setProfileLanguage.js

+ * @summary Sets users profile language
+ * @returns {Object} Account document
+ */
+export default function setProfileLanguage(languageCode, accountId) {


Move this to a non-Meteor mutation function in /imports/plugins/core/accounts/server/no-meteor/mutations/setProfileLanguage.js and call it as const updatedAccount = await context.mutations.setProfileLanguage(context, languageCode, dbAccountId); in the resolver. Using callMeteorMethod is deprecated and soon going away.

aldeed · 2019-06-24T19:57:02Z

imports/collections/schemas/orders.js

    optional: true
  },
  "history.$": History,
+  "language": {


I think this should be more specifically named, maybe ordererPreferredLanguage?

janus-reith · 2019-08-03T20:31:41Z

Sending the current language per order seems to be a resonable solution to me.

In a typical scenario I'd expect the storefront to offer multiple languages - The currently used language would then be part of the order, regardless if it was placed anonymously or by an existing account.

Storing a language field on the account makes sense to me aswell, although I wouldn't treat that as specific for emails, but also to set defaults for whatever i18n provider is used in the frontend, if that account language might differ from the one requested by the browser.

First I was unsure about the part where the account language is used to determine the email language, as we can send it only with the order, regardless if we have an account or anonymous users.
But after rethinking this, it probably makes sense to use the account. A user might place an order in one language, later change the language and expect follow ups to that order like a shipping notice to also use that new language setting.

The last things missing for me:

Where would an account get its inital language from?

We could make the storefront determine the language and send it over to the idp register form as part of the url query. The Login IDP shouldn't check language on its own, as the user might have set a different language in the storefront than the browser default.

How would the currently used storefront language affect the account language?

One option would be to just to give the user the choice like a dropdown for the current display language. Now every time the user selects a language here that differs from the account language a dialog could be shown asking if the default should be changed. The profile page could still have a seperate language preference field regardless of that, or do the same thing vice versa and ask if the current display language should be changed accordingly to avoid any confusion for users.

aldeed · 2019-08-05T21:55:38Z

@janus-reith Reaction 1.x had such a language select which would set profile.language on Account. So the field is technically already supported, but it hasn't been ported over to GraphQL. If this PR is merged, setting the account language would once again be possible, so you could add back a language select to your storefront UI.

It would be nice to eventually tie it in with IDP and new account registration, but that can be done later, and it's a separate concern since the goal is to eventually make IDP+auth a third-party component.

aldeed · 2019-08-05T21:56:13Z

@jm18457 Will you have time to address the comments?

jmaver-plume · 2019-08-06T04:06:48Z

@jm18457 Will you have time to address the comments?

I will be busy for a certain period of time right now, but I will see if I can address them over the weekend or next weekend.

janus-reith · 2019-08-10T15:08:43Z

It would probably be easier to redo this PR from scratch with the new meteor-free sendEmail function on context that is used now.

jmaver-plume · 2019-09-15T12:19:15Z

Hello, I will close this pull request and create a new pull request, since updated changes are in different repository.
I will also create a new issue in this repository with type feature so they are linked.

Jaka Maver added 30 commits May 9, 2019 10:27

(feat): add language field to profile schema

84ec3e7

Signed-off-by: Jaka Maver <[email protected]>

(feat): update graphql to make use of profile.language field in accounts

1542e76

Signed-off-by: Jaka Maver <[email protected]>

(feat): update getSubject to accept language as optional second param…

e37c469

…eter Signed-off-by: Jaka Maver <[email protected]>

(feat): update getTemplate to accept language as optional second para…

82562cf

…meter Signed-off-by: Jaka Maver <[email protected]>

(feat): update functions to properly handle optional language param

0157736

Signed-off-by: Jaka Maver <[email protected]>

(feat): update locations where getTemplate or getSubject are used to …

0f6b0b5

…include language Signed-off-by: Jaka Maver <[email protected]>

(fix): add missing import statement for Accounts collection

62a4ae5

Signed-off-by: Jaka Maver <[email protected]>

(fix): remove leftover jsdoc parameter that is not used in function

766f321

Signed-off-by: Jaka Maver <[email protected]>

(style): reformat code to follow eslint

7d1abbc

Signed-off-by: Jaka Maver <[email protected]>

(fix): type error template to subject

47a38af

Signed-off-by: Jaka Maver <[email protected]>

(fix): mongodb query search for account based on email

45010d1

Signed-off-by: Jaka Maver <[email protected]>

(feat): add language field to order document schema

9140167

Signed-off-by: Jaka Maver <[email protected]>

(feat): Move language field from OrderItem to Order

43b9c75

Signed-off-by: Jaka Maver <[email protected]>

(feat): add language field orderInputSchema

3706674

Signed-off-by: Jaka Maver <[email protected]>

(feat(): add language field to graphql type Order and input OrderInput

30ba9c7

Signed-off-by: Jaka Maver <[email protected]>

(feat): use newly added language field in placeOrder

e56e3f3

Signed-off-by: Jaka Maver <[email protected]>

(feat): modify account findOne query to look at _id instead of emails

5e322e8

Signed-off-by: Jaka Maver <[email protected]>

(fix): change language field schema from default to optional

e285900

Signed-off-by: Jaka Maver <[email protected]>

Add field enabled true to template search

1a845f6

Signed-off-by: Jaka Maver <[email protected]>

(fix): add enabled requirement for shopLanguage when search for match…

5fb7bea

…ing language Signed-off-by: Jaka Maver <[email protected]>

(fix): add functionality to check if language is correct and enabled …

1635406

…before setting it in orders Signed-off-by: Jaka Maver <[email protected]>

(fix): fix eslint and tests

3dd2e46

Signed-off-by: Jaka Maver <[email protected]>

(feat): add function to receive array of languages from primaryShop

9faa6b3

Signed-off-by: Jaka Maver <[email protected]>

Modify account to use primaryShopLanguages instead of shop specific l…

75c1977

…anguages Signed-off-by: Jaka Maver <[email protected]>

Update comment

cd04f12

Signed-off-by: Jaka Maver <[email protected]>

(fix): properly search for language in array of primary shop languages

6230e58

Signed-off-by: Jaka Maver <[email protected]>

(feat): modify function to get language from primary shop instead of …

db7c60b

…account shop Signed-off-by: Jaka Maver <[email protected]>

Fix eslint errors

5ec0d7d

Signed-off-by: Jaka Maver <[email protected]>

Remove core/server/Reaction import and use collection find to pass tests

916d7b2

Signed-off-by: Jaka Maver <[email protected]>

Fix eslint error

2fdf126

Signed-off-by: Jaka Maver <[email protected]>

Jaka Maver and others added 3 commits May 9, 2019 10:27

Remove not needed function which was added in previous commits

cca2c5b

Signed-off-by: Jaka Maver <[email protected]>

Modify functions to first check user shop and secondly primary shop f…

10bf8a6

…or languages Signed-off-by: Jaka Maver <[email protected]>

Merge branch 'master' into feat-#63-accounts-language-email

9cddfb6

aldeed requested changes Jun 24, 2019

View reviewed changes

aldeed mentioned this pull request Jul 9, 2019

Add Languages Email Template #2256

Closed

machikoyasuda added the i18n + l10n label Jul 31, 2019

aldeed changed the base branch from master to develop August 5, 2019 21:56

jmaver-plume closed this Sep 15, 2019

jmaver-plume mentioned this pull request Sep 15, 2019

feat: add support for multilingual email #5556

Merged

		@@ -1,4 +1,5 @@
		import SimpleSchema from "simpl-schema";
		import R from "ramda";

Feat #63 accounts language email #5171

Feat #63 accounts language email #5171

Uh oh!

Conversation

jmaver-plume commented May 9, 2019

Issue

Solution

Overview

Breaking changes

Testing

Uh oh!

aldeed left a comment

Choose a reason for hiding this comment

Uh oh!

aldeed Jun 24, 2019

Choose a reason for hiding this comment

Uh oh!

aldeed Jun 24, 2019

Choose a reason for hiding this comment

Uh oh!

aldeed Jun 24, 2019

Choose a reason for hiding this comment

Uh oh!

aldeed Jun 24, 2019

Choose a reason for hiding this comment

Uh oh!

aldeed Jun 24, 2019

Choose a reason for hiding this comment

Uh oh!

aldeed Jun 24, 2019

Choose a reason for hiding this comment

Uh oh!

janus-reith commented Aug 3, 2019

Uh oh!

aldeed commented Aug 5, 2019

Uh oh!

aldeed commented Aug 5, 2019

Uh oh!

jmaver-plume commented Aug 6, 2019

Uh oh!

janus-reith commented Aug 10, 2019

Uh oh!

jmaver-plume commented Sep 15, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants