Let maintainer know that the repo was forked by the assigned user

[alexanmtz]

When someone forks a repo from an issue from Gitpay, notify the user who imported that issue to Gitpay that the assigned user started a fork.

The email will have the following content: Subject: The user you assigned to an issue on Gitpay forked your project Content:

The user {{username}} forked your project to start to work on the issue {{title}} - {{url}}.

Why

We will start to provide ways to show the progress of a task based on events from Github.

Level

Beginner

How to reproduce the user scenario

• Create a user
• Import an issue
• Create another user
• Apply to work on the issue
• Log with the first user
• Assign user
• Fork project
• The user should be notified that the assigned user started a project

What you will need to complete this issue

You will need the Sendgrid keys in order to test the emails and you will receive once you're assigned.

Tips

Use Github events from our App.

[iamjoross]

Hello, Im interested to work on this issue!

[alexanmtz]

Hello @iamjoross, that's great, this one is really challenging. How do you think you will be able to notify from Github forked to Gitpay? Let me know if you have any questions.

You're now assigned and you can start to work on this 🙏

[iamjoross]

@alexanmtz I got some few questions on reproducing the issue. Should the users be real accounts?

[alexanmtz]

@iamjoross locally there's no confirmation for e-mails, so you can create test emails and log in using the credentials you signed up.

[iamjoross]

@alexanmtz From what I understand, you fork from github. How can we notify from Github without a physical account in github?

[alexanmtz]

@iamjoross

One solution maybe if we check for assignment the source repo from that issue, and the forks, and check if correspond with some user.

This assignment should have Github account associated with Gitpay, so to check this you should look on provider row on the user table.

Once the user assigned has Github and the issue he was assigned have a fork which corresponds to the Github user.

But this would require CronJobs in order to work, and this will go to the Github API as many times we define the Cron.

Another solution would be Github webhooks and events. This will require change on Settings, or install dependencies to Github apps to send Webhook events. I think we will end in this second solution.

Let me know what you think.

[iamjoross]

@alexanmtz Efficiency wise, webhooks is the way to go. Im already at it.

[iamjoross]

Need advice @alexanmtz . The template for the email's body should be The user {{username}} forked your project to start to work on the issue {{title}} - {{url}}. Being said, is it possible that a user/conrtibuter is working on two tasks for the same repo? If so, it will be hard pointing to which issue the contributor is going to fix for the fork he just did. Any thoughts?

[alexanmtz]

@iamjoross good point, this may happen, but for now, let's consider one task at a time.

We could alternatively change to The user {{username}} forked your project {{repoName}} - {{repoUrl}} with issues imported to Gitpay

[iamjoross]

@alexanmtz Digging deeper, I have a couple of roadblocks that I have to discuss with.

1. The fork event webhook payload contains the forkee's github username which we can easily map out to the User model that we have. However, I don't know which field from the User model maps out the git provider username (if there is one). Having a field in the User model that maps to the git provider username will make it easier identifying which {{username}} has just forked.

2. The only way for us to know who owns the repo based on who imported it to GitPay is currently available from the Tasks Model under the field userId. Being said, there is no way for us to trace the recipient of the email based on the WebHook's payload alone. I suggest having a model called Repositories that will have fields like its git repository name and the importer's userId to name a few.

3. I have a feature suggestion that will allow users to fork the repository where the issue comes from by pressing a button from GitPay once the task owner successfully approved them to the issue. There is a Create Fork method under repositories GitHub api that we can use. In this way, it will make it efficient by not using the fork webhook event and GitPay will just email as soon as the fork is successful.

Let me know your thoughts.

[alexanmtz]

Hey @iamjoross, I think the option 3 would be a good solution, so when a user is assigned, we can have a link on the email body to take him (and he needs to login cause it's a private route) to provide authorization to create a fork on behalf of him and start the project, great catch 👍

I think the way we think initially will generate dependency by using the hooks, so let's change the approach :-)