At the time of sending the msg to anyone,I did not get any confirmation link mail. <img alt="Screen_Shot_2019-02-20_at_1.13.05_PM.png" src="/fedora-commops/fedora-happiness-packets/issue/raw/files/3f0bb02bb307ecb42ee1f18421bbd74f61764d075e26ed45b25613dff39c61f1-Screen_Shot_2019-02-20_at_1.13.05_PM.png" />
Metadata Update from @tushar100: - Issue private status set to: True
thanks for the report @tushar100 - we are aware of this problem and we will fix it.
Metadata Update from @jonatoni: - Issue assigned to jonatoni
@jonatoni I would like to solve the issue.If you allow
sure :) I will assign it to you
Metadata Update from @jonatoni: - Issue assigned to tushar100 (was: jonatoni)
Thanks.Will solve this issue for sure.Will contact you if i need help
Metadata Update from @jflory7: - Issue private status set to: False (was: True)
Metadata Update from @jflory7: - Issue priority set to: waiting on assignee (was: awaiting triage) - Issue tagged with: PASSED, difficulty - medium, help wanted, improvement, type - backend, type - summer coding
I was able to reproduce this on the production site. I sent a Happiness Packet to an alternate email and I never received either my confirmation email or my Happiness Packet. A good next step here is to reproduce this issue locally. I'm not sure if it's a bug or a misconfiguration in the production environment.
@tushar100 Are you still working on this? If not, I would like to take over.
Metadata Update from @jflory7: - Issue untagged with: help wanted, improvement - Issue tagged with: bug
In the local development environment, the emails are send in the console, justified by CELERY_EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend" setting in dev.py. I have been successfully able to send and receive happinesspackets through the console.
CELERY_EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend"
dev.py
Hi @tushar100, we haven't heard any updates back from you yet. Are you still interested in working on this? Please let us know by the end of today if you are. I'd like to discuss how to fix this bug.
I have been successfully able to send and receive happinesspackets through the console.
This is how I have been managing email in my local development environment too.
I think this is a high priority bug fix. Before we roll out a new update to the production environment, I think this ticket should be solved first before we try pushing an update.
I'm opening this ticket up for someone else to work on. This is a high-priority bug and it would be helpful to figure this one out before we push an update to the staging site.
Metadata Update from @jflory7: - Assignee reset - Issue tagged with: good first issue, help wanted
@jflory7 I'd like to work on this :)
@shraddhaag Sure! Do you have any thoughts on what is happening here?
I think it's best to focus on reproducing this locally first. I'm not sure how the production environment is set up today as it relates to this bug. I haven't had a chance to debug this locally.
If you are on a Linux system, I think you can use a local mailbox on your machine to test email functionality (i.e. not sending test emails out on the public Internet from your laptop). You can send email to your system username on localhost. For me, this would be jflory@localhost for the email address. If I remember right, the email content should be found at /var/spool/mail/$USER. I did try this on my machine but did not receive an email.
localhost
jflory@localhost
/var/spool/mail/$USER
Metadata Update from @jflory7: - Issue untagged with: help wanted - Issue assigned to shraddhaag
Sorry about the delayed response! I configured the mail to be sent on the local mailbox but the messages aren't being sent there. I also tried configuring it to send the mails using the gmail SMTP server but that didn't work out either. In both the cases though, no errors were logged. I'm trying to figure out a solution for this.
I'll be sure to post my findings here :)
@jflory7 I have been successfully able to send emails using Gmail SMTP server. The changes to the code base made are:
In settings/dev.py:
settings/dev.py
CELERY_EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend" EMAIL_BACKEND = 'djcelery_email.backends.CeleryEmailBackend' EMAIL_HOST = "smtp.gmail.com" EMAIL_USE_TLS = True EMAIL_PORT = 587 EMAIL_HOST_USER = "<HOST@EMAIL.COM>" EMAIL_HOST_PASSWORD = "<HOST_EMAIL_PASSWORD>"
In docker-compose.yml, under the service celery:
celery
ports: - "587:587"
As to why it was not working previously, it was because of my college network configurations. Switching to a different network solved the problem for me. I'm not entirely sure as to why the above is not working on the production server. The main differences between the two is port being configured for sending the mail ie EMAIL_PORT = 587 and the ports: -"587:587"
EMAIL_PORT = 587
ports: -"587:587"
@jflory7 Could you please guide me as to how should I proceed further?
@shraddhaag Nice digging. Just now, I checked the configuration on the server of the production site and it is set up to be a mail server on localhost. However, I don't think it is correctly figured to be a mail server and it probably doesn't make sense for us to spend time setting up an email server.
Instead, we could use something like Sendgrid to handle SMTP for us. We could configure our application to point to the Sendgrid SMTP servers. This saves a lot of headache over battling email in our deployment.
I think a pull request with the changes you suggest is still useful, since eventually we want to deploy via Docker (production is not set up with containers yet). But I have a feeling the root cause of this bug is that email is not being delivered by the production server or it is getting lost in spam filters.
Edit: See this README with some mentions of various email providers.
Metadata Update from @jflory7: - Issue marked as depending on: #198
it probably doesn't make sense for us to spend time setting up an email server.
That makes sense to me
I looked into Sendgrid and found this could be used to configure Sendgrid to handle sending emails. Should I configure it or this is to be done in staging/production environment?
Apart from this, I found this in settings/deployment.py EMAIL_HOST = 'in.mailjet.com' I am wondering if mailjet was configured to be used with fedora-happiness-packets before?
EMAIL_HOST = 'in.mailjet.com'
I think a pull request with the changes you suggest is still useful, since eventually we want to deploy via Docker (production is not set up with containers yet).
I've opened the PR #199 for the same :)
It's okay for this to be done in the staging/production environment only. For testing in the development environment, I think it's acceptable to use the console output from Celery to get to the email message when testing changes out.
Great question. I am not sure myself since this is before my time on the project. I assume this was used before but we can probably use something to meet our needs today and make a note in documentation.
Super, thanks! :tada: I will work at reviewing this PR soon (Friday by the latest).
Metadata Update from @jflory7: - Issue set to the milestone: Summer Coding 2019: community bonding
Metadata Update from @jflory7: - Issue unmarked as depending on: #198
Since @shraddhaag addressed this in #199, I am closing this ticket as complete. To fix this in production, we need to set up an outgoing mail service provider when we get to #111. Perhaps Fedora Infra has something we can use or we can use a third-party provider.
Thanks again for working on this one @shraddhaag! Closing. :clapper:
Metadata Update from @jflory7: - Issue close_status updated to: complete - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.