As you know ERPNext is an open source projects and we all benefit from people contributing to issues that are important to them. You could either find a developer or fund someone to fix them for you and the entire community.
You cannot “demand” something from a community and a product that you use for free (even if you may be paying someone for hosting / support, the product is still essentially free). You can be an active participant in bringing in a change.
Email Inbox will improve when someone puts in resources to make it better. That could be you too!
A indicated in our post we are fully aware of the requirements and limitations of open source, as we stated in our post “Yes there was a telegram group and we eagerly joined because we understand the need for all hands on deck in opensource projects but little or no activity occurred.” prior to joining the telegram group we were told by the organizers that they had the ear of a core team member so of course this was a great place to understand the goals and engage those responsible for coding this particular component all along looking for where we could provide resources and experience of over 18 years working with open source projects those whom succeeded and those whom did not. Now several months later with little to no movement and more troubling corruption of the mail store we decide to reach out and document the efforts and engagements to highlight some severe development issues that in long run hurt adoption of the project. Nowhere were “demands” made just an effort to highlight our efforts and those of others to engage those responsible for this component and a lack of response from core in this forum and GitHub. The links we provided where just a few of the substantial post on this subject.
You wrote “Email Inbox will improve when someone puts in resources to make it better. That could be you too!”
That’s exactly what this post was meant to do get someone to step up and say I contributed substantially to create the code for email inbox here is our logic and why we did it this way… take a look at this piece of code and make suggestions…no accountability is just bad development in my opinion…
@rmehta I respectfully disagree, what happened here was the introduction of an inadequately developed feature, Email Inbox, it should have never left development in the state it is in then and is in now. It is not a working feature if it proclaims to be imap compatible and then steals mail off the server causing numerous legal issues, Imap is just that, synching which ERPNext does not also adhere to standard on even folders.
Prior to the introduction of Email Inbox we were able to collect email and function just fine. Since the introduction of Email Inbox email communications has been compromised. As I suggested before in this post and why I am concerned about the creditability of this project is that instead of do no harm development methodology it seems to be full steam ahead where ever the money takes it instead of making sure that development of one feature doesn’t adversely affect other features. The fact that your response states that fixing email inbox is not critical only tells me that that my concerns may be valid. We are more than willing to make sound investments but the response to our questions over the last year and half have forced us to take a more cautious approach and the response directly from you about something clearly broken adds significantly more concern. For now without any clear path to fix the broken email inbox we will have to wait until fixing this feature is a priority and focus on fixing the damage it has caused to email flow where we have it deployed. It is really a shame as ERPNext had most of the feature we wanted and needed but if its core is broken; and email is at the core for a good erp system; its just not a system that works for us and our clients right now…
@rmehta Perhaps we are using the wrong title but all of the issues started with the introduction of Email Inbox the change in setup and configuration all coincided so we have used Email Inbox as the categorization. The fact of the matter is the email accounts are setup and use the same code which is broken resulting in removing messages from the corporate server and not synching properly including root folders. All we are doing is setting up an account i.e. billing which is used to send invoices generated in ERPNext upon sync mail is brought in but not put in the sent folder on mail server and more often than not instead of leaving mail on corporate mail server it removes it all together. In addition mail that is appended for things like tickets are not consistent and demonstrate the same results. we have nothing special in our setup just one sending and receiving account and 4 accounts to deal with marketing and support. we have setup this with about 5 other erp products over the last year and they all address mail properly so we are not sure why this seems to be an issue and not a focus we are not the only ones posting on this…
It feels like we are talking two separate things and perhaps its due to a lack of written documentation. I have always suggested that before an feature is added the developers must articulate a clear user friendly doc to go along with the development or sufficiently amend existing docs before it gets committed. Videos may be helpful for some and flashy but written content should always be available.
Now back to email inbox I don’t believe we ever set it up it was just there one day with a version upgrade if you can tell us how to remove we will gladly test but I doubt it going change things as it is the email accounts (Email Inbox was our categorization as state previously) that are experiencing the issues. Did you have a read of the thread previously attached we are not the only ones?
Maybe you could take the time to watch the videos and turn it to a written document. It’s a community or group effort.
Setup a test environment to test and report the results. The threads are all just feature requests.
Please realize there is no “core team” - there are “core committers” but there is no team who centrally decides what is important and what is not. Each community user decides on their own. If this is important for you, contact a service provider to develop what you want in core.
I realize you’re most likely not going to be happy with this post, but what I suggested is the best way to get the results you’re actually looking for. Whether or not you accept that is your decision. I also agree that some of your criticism is very valid and has been shared by others and is known by users - then question the becomes who is willing to step up and be the solution.
Help comes in all forms in all forms and doesn’t always take place online in this forum this very post will help many users in the community and we are not without our likes here or posts on GitHub so your above statement is a bit inaccurate and not helpful. In addition we participate in numerous other projects so this is not one we spend all our time just like many others here we help where we can…
I have watched the videos and found they less than helpful for how I learn so not an area I would be willing to help.
Someone decided that email account and email inbox was ready for production in I believe ver 8 which it was not should have stayed in dev that’s why were are here posting trying to get a handle on all this before it gets worse and the email gets delete from both servers.
I know @clarkej is on the job and has been a great resource and have worked with him in the past but the fact remains “core committers” need to be cautious about pollinating production with code that is not ready do what your want in dev but keep production pure and by all means realize that email and crm go hand in hand…
Thank you for your time and consideration with this issue we will not take up anymore of your time but will leave the post for the rest of the community to consider…
Agreed. I’ve edited my post and removed that statement.
For information, Email inbox was not a feature contributed by Frappe or a core committer. It was a contribution by community member IAG and it met their needs. See [8.0] Email Inbox merged - WIP. This is an example of how users will deal with things that are important to them. As you’ll see in the thread by the contributor of Email Inbox, “the goal for the email inbox is for users to have an email inbox within frappe with emails linked to customers and suppliers and general docs aswell as transparency to allow users to see all communications between a peticular supplier”
The module does that. So saying “its not ready for production” is not accurate. It is ready for production for the use-case it was designed and developed for.
It doesn’t meet your particular use case, but that is completely different than not being ready for production. If you need additional features, that’s a step you’ll have to take, just like IAG took to meet a requirement they had.
So this asks a big question?
If it was for one user why was it committed to production, should it not have just been an app and not contaminated production, something that was already working well for the general population where is the quality control here. And was the email accounts code changed to accommodate this if so it broke something working we will look at this committal but quite frankly I think its bad development all around, this stuff should reman in dev, let the special needs cases reside there and let the more standard routine reside in production uninhibited…
I have still not received guidance on how to remove email inbox as per my earlier post in this thread…
It’s a generic feature which is useful and is used by others. Contribution guidelines are clearly defined. Search github and the forums. Please stop with the pointless rhetoric.
The documentation is clear on how to “configure” email inbox, so just follow those steps in reverse to “remove” it. Its already been explained that your use case is better solved by using standard incoming and outgoing features. If you’re having trouble with that, then say that specifically with the steps you’ve taken and screenshots of all your settings so that people can help (if they choose - this is a volunteer forum).
If you want the features you desire added to Email Inbox, you’re going to need to contact a service provider or developer to make it happen. The root cause of items not showing up in sent items is an Exchange limitation. See Redirecting. Other systems get around this limitation by using BCC behavior. ERPNext does not have that feature presently. If you want it, add it, or get enough people to care about it to get attention.
Also, the core of the alleged disappearing email is how you’ve configured IMAP to act on your email account and the email server, not with how ERPNext handles email. That has already been explained in this very thread.
@felix My suggestion was not “pointless rhetoric” just because you can do something doesn’t mean you should if you read the thread you posted [8.0] Email Inbox merged - WIP when it was merged there was many post stating “beta” and a lot of head scratching by other members which is exactly what I was commenting on here. What was beta doing in production is again my question?
I have my email configured properly as I have been managing mail system for 20 years and that was the first thing I checked. It is definitely an issue with the imap stack in ERPNext particularly because it doesn’t happen to every email this sort of selective synch issues almost always points to the client.
Where does this tell you how to remove email inbox or kindly post the link you speak of:
We are sorry that our suggestions bring agita to some but we have been participating in this community and asking questions for over a year and felt email could no long continue the way it has been since we began despite our efforts to uncover the logics as to why it developed the way it was. We now have some important answers from this thread and will proceed accordingly.
If you did a search for the videos as well, there is a video which shows how to set up email inbox. Here is the link. If you do not want to use it, then I think you can just unlink the “Email Account” set up from the user ID and de-activate it.
If you are having problems and it is still not disabled, you can share the steps you have carried out and probably raise a GitHub issue for it.
On your point about quality control, there is always a develop branch into which a feature is released first and is there for at least a month or two before it is merged. So it is entirely up to the community to make the most of the time to test and report issues, if any with it. If there are no critical issues reported during that time on GitHub, it is an assumption that it works fine.
Secondly, being an open source project, testing things with outlook server is not a realistic expectation as it is not readily available without having a paid license.
I have seen the video it just walks through activation and features. Email Inbox was added by default when we upgraded to ver 8 there should have been some sort of installation procedure in our case it just appeared.
I love it when folks say rtm and the manual doesn’t have what they think it does, I do rtm its the first thing I do so I don’t waste others time.
So as we thought it appears there are no uninstall instructions and the only thing to is to reverse engineer by unlinking as you suggested. We’ll have a go at that but I suspect its rooted deeper in the code and the issues will still exist.
As for outlook its a business app and ERPNext is about business, it holds a 7% share worldwide and as an application based install it as the top, that’s a lot of potential users that I’m sure ERPNext would like to attract. It is a standard in the US which is a nice source of revenue and resources so I would not write it off just because it requires a license, which for testing that $12 a month no contract well worth it considering the base that developers could attract. only a suggestion not telling folks how to spend their money or how to develop…
I thought I’d add my two penny worth. Email Inbox we use in production and it serves a useful purpose for us. That said it was quite buggy to start with, ie emails could not get marked as unread/read when you did this, and still its a little clunky moving from one email to another or deleting an email doesn’t feel right as you are not returned to the email list. Email conversation history used to only show the new parts of the emails only hiding the earlier sections in emails whereas this often does not happen now so there is much more scrolling up and down than is probably necessary.
That said Email inbox and email handling generally does fulflll its spec as it is great for flagging up new emails coming in rather than trying to keep up with the updates in Opportunities and Quotations, etc.
Getting rid of the Inbox is not at all difficult - it is just a untick in your user settings and then you revert to the normal pre v8 behaviour.
I do agree that the docs could do with improving ( i have helped here myself to improve wording or where they may be incorrect) but I think your use case with an Exchange server is perhaps not how others would use it. Often an open source stack will use a fully OS mail stack with Dovecot or similar server. I would presume that testing is carried out with this more often than Exchange, which is why bugs (and fixes) such as yours do not always come to light as readily as you would like. I do not know what Frappe use on their cloud platform but would guess it’s very likely to be Dovecot or similar OS MTA. Perhaps you could push your particular emails to a simple separate OS mail server as copies so that ERPNext can work with this instead more happily with a true IMAP implementation although I appreciate this is a bit of a hammer to crack a nut.
On other matters relating to email I have raised issues with the usability of email in ERPNext which is good and quite usable but could be better. Personally I find the narrow standard width an annoyance with longer mail threads than necessary but @rmehta was good enough to at least explain the rational behind why he preferred the current method rather than a proposed wider email modal view that I requested. You certainly do not get this level of potential input with Microsoft or Google !
I still believe and would like to see some tweaks and improvements to email as I believe it’s a core part of the framework many of which i have raised Github issues with and discussed within the ERPNext CRM group. As a non developer i cannot directly improve things myself but happy to work with others to coordinate improvements where possible.
But all said the fact that ERPNext is 100% free in terms of cost and wholly within the spirit of the GPL is immense and I believe Rushabh would never sell the application under a Freemium / Community / and Commercial Open Source model such as Odoo have moved to and many other protagonists have done (Sugar CRM anyone …).
As a community project we do have the power to change things how we wish which is more than many ERP applications would permit but obviously all changes and improvements may not always be what you would wish for.
There are still issues with Email Inbox we went in to all users and removed the link to Email Inbox under each user, reload, logout then back on. Select Email Inbox mail shows then reload again we get New Mail Account Button select reload again email returns it does not turn off completely now we know we can hide the icon but just know that there is interaction going on gives us pause and that it really doesn’t bring us back to pre ver 8 functionality.
Second as suspected there has been a change to email accounts ERPNext no longer follows sync it marks all email it syncs as read and in some case removes from the mail server this is not the definition of IMAP this is acting more like POP3 despite clearly setting up as an IMAP client. We will be looking for notations in frappe/email for reasons why this was done. thanks @clarkejAnother email issue Read Receipt - #4 by clarkej and here Email Account Issue
We would just like to suggest for the sake of others starting out with ERPNext that there is a reason for standards like IMAP as it gives all developers a platform to adhere to that way all clients i.e. outlook, android and yes ERPNext respond the same way. It should make no difference whether our mail server is dovecot or exchange both adhere to IMAP standards so we should expect ERPNext interaction be the same which it appears not to be. While there may be only a few of us now there will be more as ERPNext gains some traction so hopefully this thread will stimulate others to participate in the solution…
We have a customer using Daylite with Apple Mail on the macOS. The guys from marketcircle have ahd a very good idea on how to integrate Mail to their software. To me their approach makes a lot of sense as most people or not willing to give away their Thunderbird, Outlook etc.