Hey, this is a strange one and nothing from the log is jumping out at me (though my eyes may be a little tired at this point). Basically:
User creates Contact record
Possible duplicates found
User saves anyway (ignoring duplicate)
Error retrieving record. This record may be deleted or you may not be authorized to view it.
Did not see any FATAL errors in the log and nothing in the apache/php log. I set logging level in Suite to DEBUG and nothing jumps out either. In fact, I even see
Thu Apr 9 19:47:24 2015 [5059][1][DEBUG] Saved record with id of 48b70691-b076-3c28-989a-55270f88fe84
but can not bring it up (and it’s not in the db). Can anyone replicate this issue? Any ideas where I can look next? Relevant dump from the log attached (sorry for the extraneous info).
Forgot to add that I had recently upgraded our instance to 7.2.1. Just did a clean install of 7.2.1 and the issue persists (777 permissions just to check). I’m looking more closely into /modules/Contacts/Save.php, ShowDuplicates.php and ContactFormBase.php to see if I can more clearly identify the issue.
Anyone else having this problem/have any ideas? My users were adding a number to the end of last names as a workaround but I commented out the contents of getDuplicateQuery in ContactFormBase.php (non-upgrade safe, I know) until I can figure it out.
It looks like a guid is being set for the Contact somewhere in the in ContactFormBase.php or ShowDuplicates.php, so when the save method is called it attempts to update the non-existent record instead of creating a new one. Until I figure out where the the id is being set, I have modified /modules/Contacts/ContactFormBase.php as a workaround. After the if statement around ln 476…
if (empty($_POST['record']) && empty($_POST['dup_checked'])) {
I have added an elseif statement, since ‘dup_checked’ is set to true in ShowDuplicates.html (ln 53). Elseif statement:
I apologize for the stream of consciousness that is this thread but I’m going to keep digging until I figure out what is going on (or someone smarter than me points out the obvious problem ).
So, I logged $focus right before it was passed to the save method in ContactFormBase with a new record and then a duplicate record (attachments included). I used Meld to diff the two and noticed that $focus->new_with_id was set to true for the non-duplicate record and was empty for the duplicate record, which is why my previous workaround saved correctly. Trying to figure out why it’s being unset now but someone please feel free to end my misery by jumping in with the answer if you have it.
Bug itself is tracked on GitHub as Issue # 179 and there is a proposed fix, though it seems to be a bandaid as well since it modifies formbase, but it has the added benefit of fixing the same issue with Leads. Proposed fix may fit in with future plans as well-- I don’t know.
I haven’t had another chance to look into it since my workaround, but the issue was with $focus->new_with_id not being set for duplicate records. My workaround/temporary fix was to modify {SUITECRMDIR}/modules/Contacts/ContactFormBase.php and replace its contents with the contents of the attached text file.