Mailspring/internal_packages/participant-profile/lib/clearbit-data-source.coffee

70 lines
2.4 KiB
CoffeeScript
Raw Normal View History

feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
# This file is in coffeescript just to use the existential operator!
{AccountStore, EdgehillAPI} = require 'nylas-exports'
MAX_RETRY = 10
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
module.exports = class ClearbitDataSource
clearbitAPI: ->
return "https://person.clearbit.com/v2/combined"
find: ({email, tryCount}) ->
if (tryCount ? 0) >= MAX_RETRY
return Promise.resolve(null)
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
new Promise (resolve, reject) =>
feat(pro): New Nylas identity provider, onboarding and auth commit 50d0cfb87cd0e3d518ee91984bfac7d0c6782418 Author: Ben Gotow <bengotow@gmail.com> Date: Fri May 27 14:01:49 2016 -0700 IdentityStore conveniene methods for subscription state commit 80c3c7b9564ff79b5727f6812620b9436f35f963 Author: Ben Gotow <bengotow@gmail.com> Date: Fri May 27 12:03:53 2016 -0700 Periodically refresh identity, show expired notice in top bar commit 5dc39efe9829b2e2c14e27486b3163df4157fd17 Merge: 4c4f463 906ea74 Author: Juan Tejada <juans.tejada@gmail.com> Date: Thu May 26 15:17:46 2016 -0700 Merge branch 'bengotow/n1-pro' of github.com:nylas/N1 into bengotow/n1-pro commit 4c4f463f4b20725bc07e5c8906ecba1de54a6bd1 Author: Juan Tejada <juans.tejada@gmail.com> Date: Thu May 26 15:16:48 2016 -0700 Hijack links inside email that go to billing site and add SSO to them commit 906ea74807590e6324839b327ada1943814b17fd Author: Ben Gotow <bengotow@gmail.com> Date: Thu May 26 12:02:29 2016 -0700 Add custom welcome page for upgrading users commit 2ba9aedfe97679d845262a46b70e93d8e787cec1 Author: Juan Tejada <juans.tejada@gmail.com> Date: Wed May 25 17:27:12 2016 -0700 Add styling to Subscription tab in prefs commit 384433a338a6fb90c432d2819afc3eee127dbace Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 16:21:18 2016 -0700 Add better style reset, more IdentityStore changes commit c4f9dfb4e4007ff7e785d6d5d459a58078913e7a Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 15:29:41 2016 -0700 Add subscription tab commit bd4c25405a0edc30a3770ac09ee410f75006d73a Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 14:18:40 2016 -0700 Point to billing-staging for now commit 578e808bfccba22854b880c3dc51e01ac164302b Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 13:30:13 2016 -0700 Rename account helpers > onboarding helpers commit dfea0a98615ebdbe94a77f8a752f543bafa8411d Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 13:26:46 2016 -0700 A few minor fixes commit 7110217fd4b477557a05f2b2cde8fbbd50ced9b3 Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 12:58:21 2016 -0700 feat(onboarding): Nylas Pro onboarding overhaul Summary: Rip out all invite-related code Enable Templates and Translate by default Scrub packages page, unused code in onboarding pkg Remove resizing New onboarding screens IMAP provider list, validation Call success with response object as well Renaming and tweaks Test Plan: No tests yet Reviewers: evan, juan, jackie Differential Revision: https://phab.nylas.com/D2985 commit dc9ea45ca9c7e517732551ab61ac0ab6012263e5 Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 12:52:39 2016 -0700 Renaming and tweaks commit 5ca4cd31ce498f77f21e52c3b1996d7973fff803 Author: Ben Gotow <bengotow@gmail.com> Date: Wed May 25 11:03:57 2016 -0700 Call success with response object as well commit 45f14f9b00415f3575b26b0bde3b829f54a19108 Author: Ben Gotow <bengotow@gmail.com> Date: Tue May 24 18:26:38 2016 -0700 IMAP provider list, validation commit c6ca124e6e94261fc91fe04e284658e0968fc586 Author: Ben Gotow <bengotow@gmail.com> Date: Sat May 21 11:14:44 2016 -0700 New onboarding screens commit dad918d92696e29787c404019e07550b107ec29b Author: Ben Gotow <bengotow@gmail.com> Date: Thu May 19 16:37:31 2016 -0700 Remove resizing commit ecb1a569e29ea81085b2e2740dd273c17bc6cc1c Author: Ben Gotow <bengotow@gmail.com> Date: Thu May 19 16:36:04 2016 -0700 Scrub packages page, unused code in onboarding pkg commit 3e0a44156cec5dab734cb0d4d10fc0281186f590 Author: Ben Gotow <bengotow@gmail.com> Date: Thu May 19 16:33:12 2016 -0700 Enable Templates and Translate by default commit 0d218bc86fe987901efd8e8b36afdb4d8be2b29e Author: Ben Gotow <bengotow@gmail.com> Date: Thu May 19 16:30:47 2016 -0700 Rip out all invite-related code
2016-05-28 05:05:27 +08:00
EdgehillAPI.makeRequest
authWithNylasAPI: true
path: "/proxy/clearbit/#{@clearbitAPI()}/find?email=#{email}",
success: (body, response) =>
@parseResponse(body, response, email, tryCount).then(resolve).catch(reject)
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
error: reject
# The clearbit -> Nylas adapater
parseResponse: (body={}, response, requestedEmail, tryCount=0) =>
new Promise (resolve, reject) =>
# This means it's in the process of fetching. Return null so we don't
# cache and try again.
if response.statusCode is 202
setTimeout =>
@find({email: requestedEmail, tryCount: tryCount+1}).then(resolve).catch(reject)
, 1000
return
else if response.statusCode isnt 200
resolve(null)
return
person = body.person
# This means there was no data about the person available. Return a
# valid, but empty object for us to cache. This can happen when we
# have company data, but no personal data.
if not person
person = {email: requestedEmail}
resolve({
cacheDate: Date.now()
email: requestedEmail # Used as checksum
bio: person.bio ? person.twitter?.bio ? person.aboutme?.bio,
location: person.location ? person.geo?.city
currentTitle: person.employment?.title,
currentEmployer: person.employment?.name,
profilePhotoUrl: person.avatar,
socialProfiles: @_socialProfiles(person)
})
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
_socialProfiles: (person={}) ->
profiles = {}
if (person.twitter?.handle ? "").length > 0
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
profiles.twitter =
handle: person.twitter.handle
url: "https://twitter.com/#{person.twitter.handle}"
if (person.facebook?.handle ? "").length > 0
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
profiles.facebook =
handle: person.facebook.handle
url: "https://facebook.com/#{person.facebook.handle}"
if (person.linkedin?.handle ? "").length > 0
feat(sidebar): Add thread list of currently selected participants Summary: WIP. I added a collection index to make displaying the threads of a currently selected participant on the sidebar easy and fast. The problem is that the `participants` of a thread, while a collection of `Contact` objects, have no "ids" for those contact objects. One idea was to create the join table but access contacts by email instead of id. This required a minor change to the way the data is entered in the join table. This means the sidebar can now simply do: `DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))` While I didn't for this initial test, we could also/instead create the `Message-Contact` join table. The trick about a Message-Contact table is that I believe we'd have to create additional columns further specifying which field we're interested in. The following two queries: `DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))` `DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))` would require additional columns in the `Message-Contact` join table because currently the only columns are `id` and `value`. In the case of the sidebar use case, I think the Thread participants is what you want to see anyway. Unfortunately an email-centric scheme can't distinguish between `noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think this may be a good thing since I think most people think in terms of email address as the unique key anyway and for the use case of showing related emails in the sidebar I'd rather overshow than undershow. This solution seems to be working pretty well in initial testing, but I want to see if you guys can think of anything this may subtly screw up down the line, or if you can think of a simpler way to do this. Test Plan: todo Reviewers: juan, bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2687
2016-03-10 03:33:31 +08:00
profiles.linkedin =
handle: person.linkedin.handle
url: "https://linkedin.com/#{person.linkedin.handle}"
return profiles