mirror of
https://github.com/SuiteCRM/SuiteCRM.git
synced 2026-03-02 19:16:58 -05:00
Cannot import email - failed to load relationship - v7.9.0 #1945
Labels
No labels
Area: API
Area: Campaigns
Area: Cases
Area: Clean Up
Area: Clean Up: Performance
Area: Dashlets
Area: Databases
Area: Developer Tools
Area: Elasticsearch
Area: Elasticsearch
Area: Emails
Area: Emails:Campaigns
Area: Emails:Cases
Area: Emails:Compose
Area: Emails:Config
Area: Emails:Templates
Area: Environment
Area: Installation
Area: Language
Area: Mobile
Area: Module
Area: PDFs
Area: PHP8
Area: Reports
Area: Studio
Area: Styling
Area: Upgrading
Area: Workflow
Area:Activity Stream
Area:Calls
Area:Import
Area:Projects
Area:Search
Area:Surveys
Area:Themes
Area:Users
Branch:Hotfix
Good First Issue
Hacktoberfest
Help Wanted
PR:Community Contribution
PR:Type:Enhancement
Priority:Critical
Priority:Important
Priority:Moderate
Severity: Major
Severity: Minor
Severity: Moderate
Status: Requires Code Review
Status: Requires Updates
Status: Stale
Status: Team Investigating
Status:Assessed
Status:Fix Proposed
Status:Needs Assessed
Status:Requires Automated Tests
Type: Bug
Type:Deprecated
Type:Discussion
Type:Duplicate
Type:Invalid
Type:Question
Type:Suggestion
Type:Suggestion
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/SuiteCRM-SuiteCRM#1945
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @blloyd78 on GitHub (May 30, 2017).
Issue
Two issues:
Expected Behavior
There should be some kind of dialog box appear to define how you want the email filed.
The email details screen should populate all of the fields (sender/message body/etc)
Actual Behavior
A blank record is created without any relationship. See the following tail from the sugarcrm.log file:
`Tue May 30 11:13:32 2017 [1665][44bc535b-103d-dc6e-00c6-54a3d594bf4d][FATAL] Failed to load relationship emails_email_templates while saving Emails
Tue May 30 11:13:33 2017 [3787][44bc535b-103d-dc6e-00c6-54a3d594bf4d][FATAL] emails_email_templates_idb for emails_email_templates failed to load
Tue May 30 11:13:33 2017 [3787][44bc535b-103d-dc6e-00c6-54a3d594bf4d][FATAL] emails_email_templates for emails_email_templates failed to load
Tue May 30 11:13:33 2017 [3787][44bc535b-103d-dc6e-00c6-54a3d594bf4d][FATAL] Failed to load relationship emails_email_templates while saving Emails
Tue May 30 11:14:37 2017 [1663][44bc535b-103d-dc6e-00c6-54a3d594bf4d][FATAL] emails_email_templates_idb for emails_email_templates failed to load
Tue May 30 11:14:38 2017 [1663][44bc535b-103d-dc6e-00c6-54a3d594bf4d][FATAL] emails_email_templates_idb for emails_email_templates failed to load`
Possible Fix
None.
Steps to Reproduce
Context
I am simply trying to file emails against contact/opportunity records. The text of the email is completely missing, rendering the imported email useless.
This is a high priority issue.
Your Environment
@pgorod commented on GitHub (May 30, 2017):
Did you follow the special steps described in the Release Notes for this upgrade?
https://suitecrm.com/wiki/index.php/Release_notes_7.9.0_User_Guide
@blloyd78 commented on GitHub (May 30, 2017):
I have run through those instructions, but the same problems persist. The 'Sync' operation seemed to fail repeatedly on my primary account (no error displayed, just a blank screen), so I decided to delete and recreate the account.
Using the supplied instructions I tried to recreate my account, but the necessary dialog box does not appear - so I cannot add any new email accounts under the user account settings.
My sugarcrm.log file is still full of exactly the same errors and the email screen is completely broken (see attached screenshot):
@blloyd78 commented on GitHub (May 30, 2017):
I have re-added the primary email account as a "group email" address (it is currently impossible to add "personal" addresses), and re-run the Sync email addresses option.
Email is still completely inaccessible. Here is the latest sugarcrm.log tail:
I'm going to try and roll-back. This is a disaster.
@blloyd78 commented on GitHub (May 30, 2017):
Just tried a fresh upgrade, ensuring all email accounts were synced before doing anything else. Clearly something is still broken (see attached screenshot). Is it possible that the sync process is timing out on the primary email account?
Rolling back again. The upgraded system cannot even send a new email.
@samus-aran commented on GitHub (May 30, 2017):
Ok - a few issues to tackle then.
@PhillyD1973 commented on GitHub (May 30, 2017):
Samus, I replied in the SuiteCRM forums. However, attached is a screen shot of the add email setting which will not open for me either.
Following is the last part of my logs also. Sorry to chime in on this however I believe we are both having the same issues.
@blloyd78 commented on GitHub (May 30, 2017):
OK, I have performed another upgrade from 7.8.3 to 7.9.0 and carried out the synchronisation of the email accounts as per the upgrade instructions. All of my accounts synchronise correctly and present completion notices except my main account which results in a blank screen:
As instructed, I cleared my browser cache which has sorted the problems displaying the Inbox correctly:
However, importing emails still does not provide any kind of dialog box allowing me to allocate them to a contact/account/opportunity etc. The routine also only imports a handful of values - From, To and Subject - the actual email body is completely missing:
Here is the latest tail from the sugarcrm.log following the email import attempt:
I have successfully deleted and re-added the primary email address at last - as well as deleting the email settings in the Administration applet, you also need to reassign a new primary email address to the user record - otherwise it cannot be re-added. Unfortunately deleting and re-adding the account does not solve the issue of body text being removed from the import, even though the repair sync operation does complete successfully this time round.
Also of interested - attempting to bulk import several messages, including one that has already been imported generates this interesting error:
Sugarcrm.log output remains the same however:
@pgorod commented on GitHub (May 30, 2017):
@blloyd78 how exactly do you "roll back" between attempts?
Do you revert to a snapshot of a virtual machine?
Do you replace files from a backup?
Do you replace files and database from a backup?
@blloyd78 commented on GitHub (May 30, 2017):
I am using a snapshot of the virtual machine @pgorod - I can restore back to a fully operation v7.8.3 installation in a few minutes
@blloyd78 commented on GitHub (May 30, 2017):
UPDATE:
Just tried the 7.8.3 -> 7.8.4 -> 7.9.0 upgrade route and the same problems are still present, as are the errors in the sugarcrm.log:
@Mausino commented on GitHub (May 30, 2017):
Hi @blloyd78 i getting same or similary problems as you... after upgrade from SuiteCRM 7.8.3 to 7.9 we are fighting with those things...
If i will have more details from my developer, i put their here.. Sorry if it looks as spam comment...
@blloyd78 commented on GitHub (May 30, 2017):
@Mausino - you may be able to resolve item 2 in the list by clearing your browser cache - delete all cached content and cookies for your SuiteCRM address - that trick worked for me.
@Mausino commented on GitHub (May 30, 2017):
@blloyd78 yes, i deleted what i could :D it helps little bit.. maybe on server is something about i don't know... i'm thinking about revert back all process of upgrade.. because now it looks that the emails are unusable for my company... when my employees come to work, will get heart attack :( i will try resolve with developer some things which make me crazy now... thanks for your help
@blloyd78 commented on GitHub (May 31, 2017):
@gymad I have made the code change suggested in your fix and performed a quick repair but the problem remains - the email body is not imported (among other things). The sugarcrm.log indicates the problem still exists:
@samus-aran commented on GitHub (May 31, 2017):
Hi @blloyd78
Problem with having multiple issues on one issue is that we apply fixes for different things in different commits.
Can we review what the main issues are again so that when apply changes that you know which one helps progressively?
[FATAL] emails_email_templates_idb for emails_email_templates failed to load
@blloyd78 commented on GitHub (May 31, 2017):
OK, from your list:
@samus-aran commented on GitHub (May 31, 2017):
@blloyd78 Lets do some steps if you are able to help us troubleshoot the issues.
Issue 1. When you click onto an already imported email via the Email Module (or another module?) do you get that [FATAL] emails_email_templates_idb for emails_email_templates failed to load error?
Do you get this FATAL error if you click on a email that has not been imported yet?
@Mausino commented on GitHub (May 31, 2017):
@samus-aran after upgrade to 7.9 i have those issues
1 still apears
2 I also have not any pop up... it is importing to somewhere..
5 when i upgraded i had this issue also... but i deleted all inbound emails and recreate new and issue disapear but i got new one... that the folders stayed in email settings https://www.screencast.com/t/RSMIjJiVj
@blloyd78 commented on GitHub (May 31, 2017):
@samus-aran
This is what happens when you click on an email that has already been imported:
An email that has not yet been imported can be accessed and read correctly. There are also no errors generated in the sugarcrm.log
@samus-aran commented on GitHub (May 31, 2017):
@blloyd78
There is proposed fix for the imported email body issue (issue 1 here).
Would be great if you could test it out - we've asked @Mausino a few questions - same applies to yourself if you are able to answer.
"We just want to double check if the issue occurs when you have imported the emails after the upgrade or before? If it was after then the fix should resolve the issue but will require a re-import of that particular record. You should be able to delete the email (which only deletes the CRM record not the IMAP message) via the Detail View of the Record."
https://github.com/salesagility/SuiteCRM/pull/3620
@blloyd78 commented on GitHub (May 31, 2017):
@samus-aran @Mausino - the issue only occurs with emails imported after the upgrade. I have applied the code changes listed in the proposed fix (#3620), and I can import emails - kinda. Here's an original email before import:
And here's that same email after import:
I'm also getting the same
[FATAL] emails_email_templates_idb for emails_email_templates failed to loaderrors@samus-aran commented on GitHub (May 31, 2017):
@blloyd78
See the body in the second screenshot - can you reload the page (i.e. just refresh)? Does that still happen - the escaping of the html?
@blloyd78 commented on GitHub (May 31, 2017):
@samus-aran - That worked! We're getting closer...
@samus-aran commented on GitHub (Jun 1, 2017):
Ok @blloyd78 Just going over this again.
[FATAL] emails_email_templates_idb for emails_email_templates failed to load
Pull Requests: https://github.com/salesagility/SuiteCRM/pull/3620 & https://github.com/salesagility/SuiteCRM/pull/3621
So 4 our of 5 we have either tackled or rectifying. The last one is something we haven't reproduced. We may need to work on that more so.
Can we focus on that one in this thread more so?
Ok, when you view this account in the Emails Module, anything interesting in your Logs (SuiteCRM logs) on DEBUG mode? All other email accounts work i.e. don't show blank screen? What is different about that email account to the rest?
When you do the repair tool 'Sync Inbound Email Accounts', and only select your problem account, does it come up with any errors on the screen (should be showing progress at least)?
Updated - May raise a new issue specific to the blank account depending on how extensive it is.
@blloyd78 commented on GitHub (Jun 1, 2017):
With regards to #5, I assume that this is a bog-standard timeout issue. The Inbox of the account in question holds 607 messages, and a further 4 subfolders; none of the other accounts comes close in terms of numbers.
I should also point out that the blank screen is displayed at the end of the 'Sync Inbound Email Accounts' action - the actual inbox itself loads correctly. It's worth noting that none of the email accounts actually shows a status dialog until after the process has completed.
@Mausino commented on GitHub (Jun 1, 2017):
@samus-aran i had same/similary issue as @blloyd78 and with point 5, my url address after upgrade looks like this and was blank:
http://mydomain.com/index.php?module=Emails&action=DisplayDetailView&folder=INBOX&folder=inbound&inbound_email_record=4cdc0d21-6acb-6e5b-8055-592e71094633&uid=25566&msgno=1773
but my developer fix something and it looks now like (sorry i wil know more what he fixed when will available tomorrow):
http://mydomain.com/index.php?module=Emails&action=DetailView&record=1a2588cb-a87f-7ace-f065-592e71b0f728
i hope, that it helps localize the issue for point 5. (more about how developer fixed it, i will add tomorrow)
@samus-aran commented on GitHub (Jun 1, 2017):
Ok then @blloyd78 - the timeout has been increased for this Inbound Sync Account tool so hopefully a timeout should be minimised but it does sound like that.
But let us know @Mausino the feedback when your developer returns 👍
@Mausino commented on GitHub (Jun 1, 2017):
@samus-aran he left me skype message now :)
Here is: "I've just removed a custom controller file (custom/modules/Emails/controller.php) which was out of date and produced the issue. I'm not sure if this was added by another plugin installation, or if was added by they and forgot to update/remove when done upgrades."
@samus-aran commented on GitHub (Jun 1, 2017):
@Mausino - Thanks for that feedback. Yes that would make sense if you have a custom controller as we can't overwrite that in any upgrade. But that is perhaps something to discuss with your developer to ensure your customisations now match the new structure.
But this raises a point - we should be checking (for often customised files) if we have changes for core modules and people have customisations (using upgrade safe ways which is great!) which would cause conflict. Perhaps just an alert on the upgrade wizard when doing the preflight check that it says "Hey, we are updating these files in core - but we found you have similar named files in the custom folder" so you can prep yourselves of any development changes needed for the upgrade afterwards. Makes sense?
@pgorod commented on GitHub (Jun 1, 2017):
@samus-aran your suggestion is something I had thought of before, and actually meant to do one day.
I think it's absolutely a good idea. Upgrades that replace customized files, or that refrain from replacing them (but leave out necessary new files) must be warned to the users.
I think it should be presented on-screen to the admin doing the upgrade, not just logged. It's something that definitely requires attention. Better yet if was warned before the upgrade, during the pre-flight check, so the issue could be analyzed before any changes broke the system.
@Mausino commented on GitHub (Jun 1, 2017):
@samus-aran very nice idea with warnigs... 🥇 or some place where developers could know what they should/need to check :)
@chris001 commented on GitHub (Jun 2, 2017):
The first part of this bug, the part where it shows old data on the page and appears to be severely broken, is proof that the upgrade code should clear out the old cache so that the app doesn't show that outdated stuff to the user. The user shouldn't be stuck with having to go into the Admin page and do that manually.
@Mausino commented on GitHub (Jun 2, 2017):
@samus-aran could you create for your idea "Hey, we are updating these files in core - but we found you have similar named files in the custom folder" the record/suggestion in trello ???, that will not forget by time.