Office 365 mail

alright I’m on to something here i went in and deleted the default sending email account from email accounts but not the same named user from the users accounts. i then created a new account called it mail@domain.com remember i have an exchange connector based on ip so it doesn’t care about logon. now when i go into email queue and try to resend after logging in with the user of the same name as the old default email account a pop up says password not found and subsequently takes me back to the main page and logs out so obviously there’s a linkage between user and email account in ERPNext and how its logic handles email i am sure the developers are aware of this and can now provide the missing pieces as to why this is not working???

update it does this with any user i login in with

more interesting by the minute so i reset the site database and now every time i try to clear queue or send email it kicks me out and make me log back in obviously this is an ERPNext issue perhaps the approach should not be we cant duplicate but rather can you show me your environment and why our product fails so we can all work together to improve…

by the way i did a bench update today on this server…

ok so here seems to be the problem if for security you modify or change the default administrator account ie rename it messes everything up on the email side of things this should not be because of hippa and a variety of other laws in the us we need to do this with employee and customer data as a baseline… obviously from my experience this is a problem… this is erp software and it needs to be compliant my 20 + day journey trying to fix just email has uncovered a problem let me know where i can help…

reset data base with bench --site server.domain.com --force reinstall

fresh install what password is it looking for default sending account is blue

Method

frappe.email.queue.flush

Error

{‘retry’: 0, ‘log’: <function log at 0x3b14938>, ‘site’: u’server.domain.com’, ‘event’: u’all’, ‘method_name’: u’frappe.email.queue.flush’, ‘method’: <function flush at 0x3bb3050>, ‘user’: u’Administrator’, ‘kwargs’: {}, ‘async’: True, ‘job_name’: u’frappe.email.queue.flush’}
Traceback (most recent call last):
File “/home/frappe/frappe-bench/apps/frappe/frappe/utils/background_jobs.py”, line 61, in execute_job
method(**kwargs)
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/queue.py”, line 251, in flush
check_email_limit([])
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/queue.py”, line 143, in check_email_limit
smtp_server = SMTPServer()
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/smtp.py”, line 138, in init
self.setup_email_account(append_to)
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/smtp.py”, line 141, in setup_email_account
self.email_account = get_outgoing_email_account(raise_exception_not_set=False, append_to=append_to)
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/smtp.py”, line 62, in get_outgoing_email_account
email_account = get_default_outgoing_email_account(raise_exception_not_set=raise_exception_not_set)
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/smtp.py”, line 90, in get_default_outgoing_email_account
email_account.password = email_account.get_password()
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/base_document.py”, line 597, in get_password
return get_decrypted_password(self.doctype, self.name, fieldname, raise_exception=raise_exception)
File “/home/frappe/frappe-bench/apps/frappe/frappe/utils/password.py”, line 19, in get_decrypted_password
frappe.throw(_(‘Password not found’), frappe.AuthenticationError)
File “/home/frappe/frappe-bench/apps/frappe/frappe/init.py”, line 299, in throw
msgprint(msg, raise_exception=exc, title=title, indicator=‘red’)
File “/home/frappe/frappe-bench/apps/frappe/frappe/init.py”, line 292, in msgprint
_raise_exception()
File “/home/frappe/frappe-bench/apps/frappe/frappe/init.py”, line 265, in _raise_exception
raise raise_exception, encode(msg)
AuthenticationError: Password not found

ok here’s the problem we need to remove the need for a password that is checked against the ERPNext database when email is sent so that an anonymous relay validated vial ip/connector works with office365 this is 100% ERPNext issue all of my other third-party apps work great with office365 either as login or ip/connector relay.

that way it would work without:
AuthenticationError: Password not found

or if login is setup
(535, ‘5.7.3 Authentication unsuccessful’)

i have invested over a month on this product and have submitted a substantial amount of information documenting the problem as have numerous others what do we have to do to get some resolution on this?

As has been mentioned, you need to start a Github issue. All the development around Erpnext happens on github.

Compile the information you have gathered (which is very helpful) and make a clear request. For example “remove internal password validation from email requirements” is fairly clear. “Fix broken email” is not.

Finally, you code a solution yourself, wait for Frappe to consider the issue and have time to do something, create a “job” on the Frappe board and pay someone to make the changes, or sponsor the development with Frappe.

If you can’t make the necessary changes yourself, it boils down to being patient and thankful for a free product to get developed to work the way you want it to, or paying someone to do the development either specifically for you, or for the benefit of the whole community.

3 Likes

The only reason for not filing a bug report was because you and several others stated that you have it working so it seemed a configuration issue but after 20 or 30 attempts it finally turns out that it is based on design that is not structured to follow conventional mail standards for relay and login as is noted with others finding issues with gmail and aol. I still find it hard to believe that anyone has it working with office365 in ver 7 because even with a connector based ip it fails because email accounts need to be authenticated in erpnext???

Just so you know for future, raising an issue in Github can be done for any kind of a change you’d like to see in the product. It doesn’t mean anything will be done about it :slight_smile: but that’s the place to put them and discuss them. A Github Issue could be a feature request, or a bug report, or a suggestion for a change to a current feature.

I’m sure everyone on this forum knows the pain of trying to discover how a feature works or can work for you that has less than optimal documentation or no documentation. People try to help each other out as best they can, when they have time. I spent 2 months trying to learn how to properly install the software and setup a development environment. I consider the time spent understanding the software the “cost” of the product, and it’s still low. The Frappe team work very hard to make ERPNext great and they owe us nothing but they keep giving anyway. I always keep that in mind when something doesn’t work the way I expect or would like. I find that the more respect I give the more help I get, and I need a lot of help. :slight_smile:
I’m sorry your email issue means a delay in using ERPNext to it’s fullest, I hope a resolution is found soon and I’m sure it will benefit us all.

1 Like

I am all about open source, community development and contribute to many projects where i have a specific skill to offer and have for many years i am just struggling with the concept that erp which is so dependent on email and is not working regardless of the workarounds and suggestions from others i apply, email is at the core of erp always has been, its kind of like having oven without fuel to run it… I like what ERPNext is doing from the vid and functionality and why i left oddo but email is pretty big…Python is not my forte but i will dig in just not excited about the lack of focus on this fundamental issue that others have brought up for a long time??? no judgement here just trying to understand what’s really important so i can assess the fit…

3 Likes

I have a new fresh install and do not want to contaminate the email accounts settings. I know I can make it work via mailjet but would really like to have it native office365 can anyone confirm that email accounts work both ways in version:
ERPNext: v7.1.3
Frappe Framework: v7.1.3
If so please post screen shots so I can emulate.

Thanks

Hi,
Is there any news regarding the O365 integration?

Ms has a very good reference on the API and how it should be used:
Office 365 API reference

I am also willing to help on the topic.
Not a developer anymore, but I am available to assist in any other way possible.

Regards,
Jan

The issue is that for some reason on the smtp outbound setting the option to specify login was removed and changed to a one size fits all approach with domains and email inbox. this new implementation feels awkward to me. it works just not as well as it did before the change.

What additional functionality were you looking for?

For me the fact that if you use outlook, Communications in ERPNext does not get updated automatically so I have go in and clear out mailboxes in ERPNext manually if I have already read and responded in outlook. seems like it should mark as read in ERPNext using the imap flags like other apps do.

@imllc i agree and it also don’t pull in the send mail either

The functionality that I’m looking for is as follows:

  • account for sending Quotes
  • account for sending Invoices
  • account for sending Servicedesk communication
  • account for sending ERPNext technicals mails (reports, logs, pw reset, …)

Every Main functionality in erpnext should have the option to specify the account being used for sending mail. (Invoices, Quotes)
Or at least a default sending account.
Maybe the option should sometimes be there to select a different sending account depending on the specific situation.

Every account has a username and password and can be configured in ERPNext.

There is no need for open relay system, where you don’t need password auth.
I personally also don’t need a mail sync solution with ERPNext.
What I do need is that when a mail is sent via ERPNext, it is also visible in the sent items of my O365 maibox.
This is the case if you use the O365 API.

Well said and exactly what we have and I suspect many others need.

I have used many integrated products with exchange and office365 but by far the mail implementation in ERPNext seems to be the most awkward.

Can you tell us about how you implemented the office365 API with ERPNext?

I haven’t implemented it yet. Never needed to implement it because this is most of the time a standard supported functionality.

I just know that I mentioned this to other companies who develop software now, and they both managed to implement it within a couple of weeks.

I would love to invest in the feature. And though I know my way around coding, I’m not a developer anymore.
Still it is very strange for me that this feature is not yet implemented by ERPNext core.
That API is supposed to be very easy to implement.
And if ERPNext wants to broaden their userbase and customers, than this seems to me an easy win.

I’m having some talks about this with another ERPNext customer.
If you like we could discuss some mutual investment for developing the solution for us?

Or ask ERPNext core what the cost would be for them to implement it.

1 Like

Added to this,
There is already a request in git:

https://github.com/frappe/erpnext/issues/6602

They talk about 3 items:

  1. anonymous account
    → why would you even want this these spammy times
  2. send as other account
    → why send as other user, I just want to sent as the account I verify
  3. imap
    → who would want to use imap with O365? there is a great API

Why is option 4 - implementing the authenticated account system with the provided API- not mentioned as an option?

This was at the time an effort to find a compatible work around for the limitation of ERPNext mail and security model and what we could control from our side as office365 admins along with limitations of google cloud compute. More issues were created later on with the addition of the email inbox and as a result we moved to azure and found more suitable implementation yet not as good as it could be.

I agree it would be preferable to use the office365 api at the time we were only trying to at least get basic functionality that is almost universally available on other platforms.