BE invitation dialog 40

[cch5ng]

updates create invitation api route (post)

requirements

at #40 (comment)

to test

used curl to make BE requests, with the jwt auth step commented out

tested the following cases (verifying results in cloud database with mongo shell; I can provide a connection string):

• invite recipients (toEmailAr) includes some users who are registered ([email protected], [email protected]) and some who are not registered. invitations should be created for registered users. sendgrid should send email invites to the non-registered recipients.

• invite recipients include only registered users (multiple and single)

• invite recipients include only non-registered users (multiple and single)

Notes: I didn't test really hard on the multiples. I'm not entirely clear on the error handling like if there are multiple error scenarios, how to gather all those. I'm aware that there is a bit of redundancy in the code (creating invites and making sendgrid requests but I'm not clear how to make it more dry b/c of the nesting.

curl example:

curl -d  '{"toEmailAr": ["[email protected]", "[email protected]", "[email protected]", "[email protected]"], "fromEmail": "[email protected]", "referralId": "test-referral_id"}' -H "Content-Type: application/json" -X POST http://127.0.0.1:3001/invitations

---

(old messages)
@sina-jamshidi I'm a little bit unclear of when I should return a result to the browser. I think the timing is ok for these cases:

• all invitation recipients are registered users

• all invitation recipients are not registered

(update with proposed solution) I suppose I have to check the cases in this order

1 if there are both invite recipients who are registered and who are not registered

• for this case, I suppose, I might nest the requests like first make the local database changes and after completion, make the sendgrid requests; I will try this

2 if there are invite recipients who are all registered

3 if there are invite recipients who are all not registered

[sina-jamshidi]

as per the sendgrid npm package it looks like you can just do sgMail.send(messages). That also means you can probably refactor to only have one sendEmail function.

[cch5ng]

yes, I'll change that. I didn't know if there was a preference so included both.

…

On Wed, May 27, 2020 at 12:29 PM Bonnie Li ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In server/routes/invitation.js <#45 (comment)>: > + } + if (idx === validEmails.length - 1) { + //1 handle case where recipients include registered users and non registered + if (curUserEmails.length && nonCurUserEmails.length) { + let newInvites = []; + console.log('curUserEmails', curUserEmails) + curUserEmails.forEach(to_user_email => { + let newInvite = {to_user_email, from_user_email: fromEmail}; + newInvites.push(newInvite); + }); + Invitation.insertMany(newInvites, function(err) { + if (err) return console.error(err); + inviteRecipients = inviteRecipients.concat(curUserEmails); + if (nonCurUserEmails.length === 1) { + sendEmail({from_email: fromEmail, + to_email: nonCurUserEmails[0], since theres the to_email_ar, and nonCurUserEmails is already an array, is it possible to just send nonCurUserEmails into sendEmailMultiple without worrying about if its length 1 or more? ------------------------------ In server/routes/invitation.js <#45 (comment)>: > + }) + } else if (curUserEmails.length === 1) { + //2 create invites for existing userss + const invite = new Invitation({ + "from_user_email": fromEmail, + "to_user_email": to_email + }); + invite.save(function(err) { + if (err) return console.error(err); + inviteCreatedInternalMessage = `An internal invitation was sent to ${to_email}.` + if (!nonCurUserEmails.length) { + res.json({ type: "success", message: `An invitation was sent to ${to_email}.`}); + } + }); + } else if (curUserEmails.length > 1) { + let newInvites = []; ⬇️ Suggested change - let newInvites = []; +let newInvites = curUserEmails.map(to_user_emails => {return {to_user_email, from_user_email: fromEmail}}; — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#45 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEI72C5EH4SOCU5BV4JFTLRTVSZ3ANCNFSM4NLRBRZA> .

[sina-jamshidi]

(update with proposed solution) I suppose I have to check the cases in this order

1 if there are both invite recipients who are registered and who are not registered

• for this case, I suppose, I might nest the requests like first make the local database changes and after completion, make the sendgrid requests; I will try this

2 if there are invite recipients who are all registered

3 if there are invite recipients who are all not registered

Yup makes sense. This PR looks good to me once you make the commented changes.