ExchangeBC / devex

This was the original Mean app for the BC Developers' Exchange. It has been superseded by two products, github.com/bcgov/digital_marketplace and github.com/bcgov/bcdevexchange.
Apache License 2.0
26 stars 41 forks source link

CWU Opportunity Notifications Sent From Incorrect Account #222

Closed kelpisland closed 6 years ago

kelpisland commented 6 years ago

FROM S CURRAN: Catching up on some overdue things on my to do list and wanted to make sure you were aware of this issue with BC Dev Exchange. When the opportunities for the Pathfinder Blockchain/VON Project were released, I received emails on both my work and personal accounts. The one that came to my work email address (this account) the email came from BC Dev Exchange - good. However the one that came to my personal account (swcurran@gmail.com) - which is linked to my github account - came from Chris Coldwell - bad. Pretty sure it shouldn't be working that way :-).

It looks to me like there are two (at least) paths where notifications are triggered, and one is using the wrong address. I looked and it's not a hard coded value in the code, so I'm guessing it's in a database or a non-versioned config file.

amanji commented 6 years ago

Could you please provide more context into this? Is the exact same email received in both accounts?

mark-a-wilson commented 6 years ago

Hi @amanji . Sorry for the delay. I just talked to @swcurran to make sure I understood the issue correctly. Here it is:

When a new opportunity is published for the first time from bcdevexchange.org 2 things happen:

  1. Users who are registered in the app and have the "Notify me about new opportunities" checkbox selected in their profile receive an email notification from noreply@bcdevexchange.org that looks like this: screen shot 2018-03-21 at 12 00 59 pm

  2. Whatever magic code @ccoldwell has created (it's way above my understanding) causes a new GitHub Issue (in the GitHub repository that is defined in the opportunity) to be created. The Issue shows up as being created by the GitHub user @ccoldwell, and the content of the comment is a replication of the content that is found on the opportunity's detail page on bcdevexchange.org.

Why are we putting the opportunity content in two places?

So what's the issue?

The confusion arises for people when they are a watcher of the repo, and they get a GitHub email notification showing that @ccoldwell has posted an Issue that's an opportunity. (Who's @ccoldwell ?!)

Potential solutions to this issue

I don't know what's possible, but here are two things I can think of that would be better:

Hope this helps.

amanji commented 6 years ago

Thanks @mark-a-wilson for the well documented response. This confirms, my observations with my local testing environment.

The issue has to do with the GitHub OAuth token that is passed with POST requests for creating GitHub issues (via the GitHub API) when opportunities are added and updated in the BCDevExchange application. I presumed it was @ccoldwell who initially created the token which is being passed into, and used in the production application. The GitHub issues are created on behalf of the user the OAuth token corresponds to, hence why all the automatically generated issues are tagged with @ccoldwell GitHub ID.

You are correct about point 1. Anyone who is an owner or contributor of the repo is notified of any GitHub issues created in that repo unless they otherwise change their notification settings. In this case, @swcurran gets notified about the GitHub issue via their GitHub linked email (personal one) when the issue is generated. In this case the email is sent on behalf of the user that created the GitHub issue which is @ccoldwell since that is the user associated with the OAuth token that is used to POST the issue via the GitHub API. Since @swcurran has also provided their work email on the BCDevExchange application to receive notifications, they also recieve an email from the BCDevExchange email account that is registered in the application.

With that said, the first approach is probable the easiest to implement, which is to create a generic BCDevExchange user and an associated OAuth token for that account that is passed to the application to POST new GitHub issues when opportunities are created. The second approach would require that each user generate an OAuth token and have that stored in the application somehow. While it may be feasible, there could be security concerns with passing a users private token into a client side application in addition to having to implement logic to deal with revoked tokens.

Thank you for enduring my long response. What are your thoughts on this?

mark-a-wilson commented 6 years ago

In my opinion, the first approach (The Issue gets posted by a GitHub user called "BCDevExchange") would be a good improvement.

@scchapma , @paulroberts68 , @ccoldwell , @agehlers - would you mind piping in here?

mark-a-wilson commented 6 years ago

@amanji - I just checked in with @scchapma and if you could proceed with pursuing the first approach that would be great.

I just invited you to our Slack where you can connect with the team, especially @agehlers who will be able to assist with getting you any access you need and creating a generic BCDevExchange user.

scchapma commented 6 years ago

This issue has been corrected as of today (July 24, 2018). Closing this issue.