Closed rholighaus closed 8 years ago
I have inserted an Umlaut (ö) in a case update for both 7.2.3 and 7.4 and it shows without issue. Can you please recreate the issue by creating another case update and take a screen shot?
Hi @rholighaus, can you please try to recreate this issue and attach a screen shot?
Sorry mate, forgot about his. Now running SuiteCRM 7.4.3
Interesting behaviour now: The case updates with Umlauts in get saved, but any case update seems to freeze during the processing of the case update.
Here are a few screen shots illustrating it:
When I click on the “X” to close the message, I’m back to editing the case update.
When I reopen the case via the side bar, the Umlaut update has been stored, however.
When trying to enter a case update with no Umlauts, I seem to get the same “One moment please” window that’s stuck - and when reloading the case, the update is also saved.
Am 10.03.2016 um 13:09 schrieb paulgodley notifications@github.com:
Hi @rholighaus https://github.com/rholighaus, can you please try to recreate this issue and attach a screen shot?
— Reply to this email directly or view it on GitHub https://github.com/salesagility/SuiteCRM/issues/607#issuecomment-194814536.
Ralf Holighaus
Schopenhauerstr. 23・14129 Berlin, Germany
Mobile: +49 172 7108171 Home: +49 30 79702020
Hi @rholighaus, the screen shots have not added to the github issue. Can you please pop them up as it will help to replicate the issue?
@rholighaus which browser are you using? Can you please press f12 and try to save a case update and see if there is a javascript error thrown in the console?
Hi, I have just installed a fresh install of 7.4.3 and I can create a case and log updates without issue (both with and without Umlauts). Maybe this is a browser issue (I have tried this with both Firefox and Chrome).
Thanks Paul. I try in another browser and will let you know. Ralf.
Am 10.03.2016 um 16:52 schrieb paulgodley notifications@github.com:
Hi, I have just installed a fresh install of 7.4.3 and I can create a case and log updates without issue (both with and without Umlauts). Maybe this is a browser issue (I have tried this with both Firefox and Chrome). https://cloud.githubusercontent.com/assets/9193412/13675091/f30c2dc8-e6d7-11e5-97f2-90091e1a3c99.png — Reply to this email directly or view it on GitHub https://github.com/salesagility/SuiteCRM/issues/607#issuecomment-194917516.
Ralf Holighaus
Schopenhauerstr. 23・14129 Berlin, Germany
Mobile: +49 172 7108171 Home: +49 30 79702020
Hi Paul,
It took a bit - sorry.
I can narrow down the problem - there is indeed an error thrown by the browser, see screenshot attached.
It may have something to do with a change a made to custom/modules/Cases/metadata/detailviewdefs.php:
6 =>
115 array ( 116 0 => 117 array( 118 'name' => 'description', 119 'customCode' => '{$fields.description.value|escape:\'html_entity_decode\' |escape:\'html\'|strip_tags|url2html|nl2br}', 120 ), 121 ),
The customCode was added to show the HTML code in a description field instead of showing the HTML source. If I remove this change, the Case Update can be saved properly.
However, users are using the offered rich text editor to enter case descriptions (plus I’m creating new cases via the REST interface using HTML to highlight words). There’s no point of allowing people to highlight text in the case description but only display it as HTML code later…
I was hoping that 7.5.3 would make the customCode line obsolete but alas it hasn’t.
What do you suggest doing? Looks like I have the choice of providing HTML code to my users or allowing the to enter case updates…
Thanks for your help, Ralf.
Am 10.03.2016 um 16:36 schrieb paulgodley notifications@github.com:
@rholighaus https://github.com/rholighaus which browser are you using? Can you please press f12 and try to save a case update and see if there is a javascript error thrown in the console?
— Reply to this email directly or view it on GitHub https://github.com/salesagility/SuiteCRM/issues/607#issuecomment-194907526.
Ralf Holighaus
Schopenhauerstr. 23・14129 Berlin, Germany
Mobile: +49 172 7108171 Home: +49 30 79702020
Hi @rholighaus, I am not sure of the answer to your question. @mattlorimer or @JimMackin, can you please comment?
Hi @rholighaus, I have spoken to @JimMackin and he has advised me that this is a duplicate of an ongoing issue, covered in bug #975. That call has been assigned to one of the team and they will hopefully get a fix in place as soon as possible.
Sorry that this does not fix your issue right now, but it would probably be better to take out your custom code if that is causing the error (even though this will remove your custom formatting).
SuiteCRM 7.2.3 on Ubuntu 14.04 LTS
A case update entered to a case contained an o Umlaut (ö), which resulted in the detailed view just showing a blank page under the menu. Funny enough, when going into edit view, then saving the record, it would display, but the umlaut would look "funny", as a control character. Sorry, didn't take a screen shot. Going back into detailed view still it still showed it broken.
This was the content of aop_case_updates that broke the display:
mysql> select * from aop_case_updates where id='aefa0e2d-7c20-56a2-2690-56247abf9773'\G *** 1. row *** id: aefa0e2d-7c20-56a2-2690-56247abf9773 name:
Herr Wörner kommt am 02.11.2015 so g... date_entered: 2015-10-19 05:09:10 date_modified: 2015-10-19 05:09:10 modified_user_id: dbd8a580-63ba-153b-b0ff-51374efaf697 created_by: dbd8a580-63ba-153b-b0ff-51374efaf697 description:
Herr Wörner kommt am 02.11.2015 so gegen 9,00 Uhr
deleted: 0 assigned_user_id: dbd8a580-63ba-153b-b0ff-51374efaf697 case_id: c6ce2c0b-15f0-fbd6-0839-5608fbe6e8c9 contact_id: NULL internal: 0 1 row in set (0.00 sec)I have manually updated the database to change the (web-encoded) Umlaut 'ö' to 'oe' - and this fixed the detailed view:
mysql> update aop_case_updates set name='
Herr Woerner kommt am 02.11.2015 so g...', description='
Herr Woerrner kommt am 02.11.2015 so gegen 9,00 Uhr
' WHERE id='aefa0e2d-7c20-56a2-2690-56247abf9773';So the encoding into the database seems to be okay, just the output breaks - probably - the AJAX code?
Cheers, Ralf.