February 26, 2019 at 1:41 am #19666
New user — running self hosted.
I have installed the system and it is working fine, so far. However, I cannot add users. I create an additional user and gave that user full admin rights, but that user never gets an email invite.
The “test email” page will send a test email successfully, but when inviting a user, they *never* get the email.
This bug has been around for at least two years, per the very few forum threads I can find:
It’s very frustrating! I’ve done all of the troubleshooting — but can’t get at the info.
One thing I can do is inspect the mysql table and I see a pending confirmation token that could be used to validate my new user but I don’t know what that URL could be?
But getting back to the issue–it’s beyond clear that the code used on the page to define the email server (mailgun, smtp, mail, etc.) has a send test email button that uses different code to send email than the “Resend Invitation” button page. Why is this? And why can’t I just manually set a password for my new user and be done with it?
I appreciate your time. Any suggestions to help would be very welcome, as I’m about to abandon this software due to this.
App Version: v4.5.9
Server OS: Linux 4.10.0-28-genericFebruary 26, 2019 at 1:47 am #19667
Forgot to mention: I even signed up for a mailgun account due to this…and the test email button goes through mailgun (it appears in their logs) but the invitation and password reset emails do NOT go through the mailgun account. How is this possible? I’m using the mailgun API and not SMTP.February 26, 2019 at 1:59 am #19668
Have you setup DKIM and SPF records? If you can see it hitting mailgun, clearly Invoice Ninja is working and delivering the email to Mailgun, you’ll need to investigate the other side of this and not simply blame Invoice Ninja as it is impossible for Invoice Ninja to be responsible for end to end delivery of email. Thats just not the way the internet works.February 26, 2019 at 2:38 pm #19673
@davidbomba, Thank you for your response.
What is your explanation for the test email button on this page: /settings/system_settings going through mailgun but the resend invitation button /users/1/edit NOT going through mailgun? It literally makes no sense.
I am not ‘blaming’ invoice ninja for not ensuring that delivery of email goes through–I’m blaming it because the code used to send email is obviously different and there’s not a good way of troubleshooting it AND I can’t simply just reset my own password.
Please take this in the spirit in which it’s intended: a v2 rewrite from the ground up is happening right now, in your own words you can’t guarantee that email is always delivered, yet you give admins no other options than email for password resets and user registration. This needs to be improved.February 26, 2019 at 9:02 pm #19679
If you have spent any time looking at the code, you can clearly see that both of those routes go to the same method which handles the sending of email.
There is no mystery here, there is clearly a configuration issue with your setup (have you checked the error logs for more information?) you also haven’t answered my previous question regarding SPF and DKIM configuration.
We send literally millions of emails using this exact code base every month, then add on the tens of thousands of self hosted users who also use it without this exact issue.
If you need configuration assistance we are happy to help, but you’ll need to excuse me if I am blunt because from the tone of your message simply blaming invoice ninja, threaten that you’ll ‘stop using’ the app and that we need to ‘do better’ is clearly not the best way to start a support query.February 26, 2019 at 9:13 pm #19680
Again, I appreciate your response. I’m not sure why you’re so upset.
I’ve wasted time trying to get this to work — so I’m admittedly frustrated, and you haven’t answered my questions, instead you’re chiding me. So the same goes for you: how do you expect me to respond to being told what to do?
Again–the ‘blame’ here is that I can’t change the password from the GUI. If this one feature was implemented I could move on. I actually don’t want to use the system to send email–it’s not an important feature to me. What is important is that I have multiple users. But I can’t due to not being able to set a password from the GUI. That’s really what is frustrating to me. I’m being truthful–this is a showstopper for me because I can’t use the software due to not being able to do this. Imagine how many users don’t tell you that.
To answer your question: the logs say nothing.
Do you want to help me, or do you want to continue to chide me? I’m listening. Please give me instructions and I’ll troubleshoot this. The log files have not been helpful.February 26, 2019 at 9:19 pm #19681
The system is designed to be used with a working email system.
If you want to bypass this, it is simple set the column confirmed to 1 in the users table, then you can create many users and they won’t have to confirm their account.February 26, 2019 at 10:18 pm #19682
@DavidBomda : What would their password be?February 26, 2019 at 10:33 pm #19683
The only workaround for this would be to copy the administrator password hash and insert this into the additional user.
You’d then be able to log into the users account and change their password to something else.February 28, 2019 at 5:27 pm #19747
With these work arounds I’ve gotten my user in. Thank you David.
I’m a systems guy so I’m very curious about the test email always working and the other emails not. What’s the explanation? When I had things going through mailgun the test email showed up in the logs, but the other emails didn’t even make it to mailgun.
I turned on debug in the gui (and am impressed with laravel’s debug gui) and on the test email page, it shows that an email got sent, but on say the password recover page, invoiceninja says that the reset email was successfully sent, but laravel’s email panel shows nothing.
I’m sure there is some sort of configuration issue here, but what could it be and where do I look?February 28, 2019 at 8:47 pm #19748
I’d double check the logs in storage/logs/*.log for errors, in particular looking for errors emitted by Swiftmailer.
I’d also be scanning through /var/log/syslog to see if there are any other clues
You must be logged in to reply to this topic.