Inline Editing doesn't show modified value

When I’m editing a field, it seems to happen to dropdown fields, with Inline Editing, it changes the field value correctly, it changes the database correctly and the Change Log.
But when you update the page after this modification, it return a blank value. When you edit this blank value, it returns the first option of the dropdown, not the default or the correct value. When you leave the editing without saving it, you get the pop-up that the value will not be saved. When you click 'Ok" is shows the correct value as it should do.

I executed quick repair & Rebuild, but no success.

When I change back to No-Inline editing, the values that didn’t appear in the Inline Editing mode don’t appear either, and editing them in the traditional way will show the same wrong values.

What am I missing?

Hi,
Is the host of the SuiteCRM server Windows or Linux based?
Have you checked that your server/file permissions are set correctly?
Also, If you check your config.php file, you will find something alike:

 'default_permissions' => 
  array (
    'dir_mode' => ,
    'file_mode' => ,
    'user' => '',
    'group' =>' ',
  ),

What values do you have set for these?

Hi John,

Host is Linux based.
Server file permissions are set correctly
Config.php;

‘default_permissions’ =>
array (
‘dir_mode’ => 1517,
‘file_mode’ => 420,
‘user’ => ‘www-data’,
‘group’ => ‘www-data’,
),

Hi,

What version of SuiteCRM are you having this issue on?

Have you tried the steps posted by MatthewJones: Here

Hi John,

I’m having this on 7.3.1 and yes I have tried the steps posted by Matthew Jones several times.

Hi,

Is this a custom dropdown field you are trying to edit?

Which module/ Where in the CRM is this dropdown field located?

Was your v7.3.1 an upgrade from a previous version or a fresh install.

Have you tried clearing your browser’s cache before/after you inline edit this field.

Hi John,

it are custom dropdown fields as well as modified dropdown fields.
It’s in module Opportunities.
It was an upgrade of 7.3 but the creation of new modules and modifications of fields were all done in 7.3.1
Yes I’ve cleared my browser cache and even tried it on chrome and firefox. Same behavior.

Hi,

Are you trying to edit the field as a User or an Administrator?
What theme are you using? If you are using Suite7, please try the SuiteR theme.
Have you made any code customizations? This may be causing the issue as I am unable to replicate this on any of my test instances.

If possible, it may be worth downloading a fresh install that is separate from the instance you are using now, and testing if it happens on that one too.

Hi John,

I think I finally found the issue. It has to do with custom dropdown fields. The new or edited dropdown list don’t allow you to create the ‘Item Name’ (Key) freely.
So in some cases I created slightly different Keys then ‘Display Labels’. e.g. ‘Value_1’ and ‘Value 1’. Now when the ‘Item Name’ is not equal to the ‘Display Name’ the problem rises when you use inline editing. Instead of storing the ‘Item Name’ in the database it stores the ‘Display Label’. This causes the problem displaying it correctly after the pages is refreshed.
I guess the reason you couldn’t replicate the problem was you didn’t try a custom created dropdown list with unequal key values pairs.
When I changed on of the Language files storing the Dropdown list and edited it so all Item Name were equal as the corresponding Display Name it worked fine.
Hope you can replicate the issue now and we get this fixed.

1 Like

Hi,

Thanks for the updated information, took a look at this in better detail and I was able to replicate it.
I’ve logged it on our Github’s issues page: #492

This is kinda a big deal. Is anyone interested in posting the code to resolve this? Using the language file to fix is only really an option if either

1 - You don’t have a bunch of existing data in the database (or are willing to run some queries to update all of that data).
or
2 - You are willing to have your display label match your key label, which is not an option for many cases (at least after-the-fact).

If someone can point me to the file where this would need fixed, I would be willing to take a stab at fixing it… I would also need to know where the file is that maps keys to values in normal edit view to use as an example.

Thanks,
sieberta

Having the same problem, I think inline editing should be turned off until a fix comes out.

Think I found a solution to this issue. The problem lies within the Javascript for inline editing. The file in question is located in include/InlineEditing/inlineEditing.js .

Look for this line of code in the getInputValue function:

case ‘enum’:
if($(’#’+ field + ’ :selected’).text().length > 0){
return $(’#’+ field + ’ :selected’).val();
}
break;

Change this line -> return $(’#’+ field + ’ :selected’).text();

To This -> return $(’#’+ field + ’ :selected’).val();

This way the dropdowns for inline editing will save the value instead of the label.

Hope that helps.

1 Like

Thank you very much. With your suggestion the right drop down value was saved to the database.
Another issue came up, once you change the value and hit save, instead of displaying the label, the field is displaying the value. we need to refresh the page to display the correct label.

I’m not a .php expert nor a novice but went ahead and checked the code in InlineEditing.php, checked the cases managed by the function formatDisplayValue and saw that the function is missing a case for ‘enum’ field types. I added the following lines to the function and it seams working fine now :

    //if field is of type enum.
if ($vardef['type'] == "enum") {
    $value = str_replace("^", "", $value);

    $array_values = explode(",", $value);

    foreach ($array_values as $value) {
        $values[] = $app_list_strings[$vardef['options']][$value];
    }
    $value = implode(", ", $values);
}
2 Likes

Good catch!

I did it just a tad differently for simplification. Instead of adding those lines, all you should need to do is add a condition to the muitienum statement.


So this -> if ($vardef['type'] == "multienum")
Can be changed to this -> if ($vardef['type'] == "multienum" || $vardef['type'] == "enum")

Thanks for finding that. Hopefully this will be permanently added to the next release.

1 Like

Yes it’s even better !

Thank you

Firstly, thanks to both of you for posting your solution contributions for this.

I’m feeling really dumb, because I cannot get these to work on my system. The editing of the .php file went swimmingly. The editing of the .js file seemed to have no effect. In troubleshooting, this is what I’ve found so far:

  1. If I “view source” I see this: http://domainname.com/include/InlineEditing/inlineEditing.js.pagespeed.jm.bsLA9uLJEf.js I’m not sure where the “pagespeed.jm.bsLA9uLJEf.js” comes from. I would guess some sort of Caching?
  2. If I open that URL in my browser, I see a copy of the javascript with all of the extraneous stuff cut out (like comments) but it also doesn’t reflect my changes.
  3. If I cut the end off of that, and view inlineEditing.js, the first time it didn’t have my changes… then I hit CTRL+F5 and it did have my changes… which is a little weird because I had CTRL+F5ed several times in troubleshooting and testing on the normal browser window instead of the view source.

This is the code I currently have in there, although I think it is irrelevant as it seems to not be getting included:


            case 'enum':
                if($('#'+ field + ' :selected').val().length > 0){
// NEW/CHANGED to fix inline editing on dropdowns according to https://suitecrm.com/forum/kickstart-testimonials/6367-inline-editing-doesn-t-show-modified-value#24216
								alert $('#'+ field + ' :selected').val();
								alert $('#'+ field + ' :selected').text();
							   return $('#'+ field + ' :selected').val();
// ORIGINAL:                    return $('#'+ field + ' :selected').text();
                }
                break;

Obviously, the “alerts” are me trying to figure out what is going on… that is how I figured out my code wasn’t even getting run.

I of course I did a repair+rebuild as well as a Repair JS Files… but to no avail. Oh an of course CTRL+F5 (already mentioned).

I don’t think it is related, but I would mention that I deleted the original .js and .php files and reuploaded them rather than overwriting them because those files were owned by daemon:daemon instead of bitnami… which is the user I’m forced to ftp in as. I’ve never had issues when I’ve done this before, but I also haven’t needed to edit much JS in SuiteCRM… usually just PHP.

Thanks in advance for your trips and tricks!
sieberta

Did you clear your browser’s cache ?

Perhaps? I thought that is what CTRL+F5 did…

Thanks for your response,
sieberta