Editor includes extra field on sumbit, but that field was not changed

Editor includes extra field on sumbit, but that field was not changed

rldean1rldean1 Posts: 141Questions: 66Answers: 1
edited January 2021 in Editor

Do you have any idea why an extra field would be included on submission, when only 1 field changed, and the form-options are set to changed only?

In the request, it includes the Action, DT_RowId, and the modified Email field. However, there is an extra field, ResendEmail which I did not change.

Any ideas?

Even when I explicitly define the column 'Email' (commented out below), it will still include a superfluous ResendEmail field.

                    }).on('click', 'tbody td:nth-child(4)', function (e) {
                        app.dteUnscheduled.inline(this)
                        // app.dteUnscheduled.inline(this, 'Email', {
                        //     submit: 'changed'
                        // });
                        // app.dteUnscheduled.inline(this, {
                        //     submit: 'changed'
                        // });
                    });

I should mention that the ResendEmail field is a bit value, 0 or 1 from SQL. In DataTables, it is a rendered field:

    {
        data: "ResendEmail",
        title: 'Resend',
        className: 'text-center',
        visible: (app.access_level === 'Admin') ? true : false,
        render: function (data, type, row) {
            if (type === 'display') {
                // if the email bit is queued (1)
                if (data) {
                    return '<i class="fas fa-history ml-1 text-success resend-popover data-toggle="popover" data-lastemaildate="' + row.ResendEmail + '"></i>';
                } else {
                    return '<a class="resend-popover" href="#resend" data-toggle="popover" data-lastemaildate="' + row.LastEmailDate + '"><i class="fas fa-envelope"></i></a>';
                }
            };
            //for all other types
            return data;
        }
    },

Answers

  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin

    I suspect, based on the fact that it is showing as false that you are feeding in a boolean value (i.e. typeof variable === 'boolean') which is not the same as false), thus causing this issue.

    How are you defining ResendEmail - is it a hidden field type?

    Allan

  • rldean1rldean1 Posts: 141Questions: 66Answers: 1

    YES! In the Editor, ResendEmail is hidden. Side note: I'm not using the Editor form, I'm using a click listener for this specific field, and it it invokes .edit().set().submit().

    ResendEmail is stored as 0 or 1 in the database, but SQL's for json path transforms it into the string true or false. {"ResendEmail":false} Notice there are no quotes ---->>> and that appears to be what I'm feeding DT/DTE.

    Here's the DTE config:

                                    {
                                        label: "ResendEmail:",
                                        name: "ResendEmail",
                                        hidden: true
                                    }
    
    

    To tell you the honest truth, it's not breaking anything, but I've observed strange things like this before, and wondered how to fix it.

  • rldean1rldean1 Posts: 141Questions: 66Answers: 1

    Some brief testing indicates that if I cast it as an integer, then it stops the superfluous submission.

                        --,ResendEmail
                        ,cast(ResendEmail as int) as ResendEmail
    

    It maintains the original 0 and 1 as it is in the database, and as it is fed to DT/DTE. I've observed that there are no quotes around the int {"ResendEmail": 0} {"ResendEmail": 1}.

    I don't fully understand what's happening here, but I guess the answer is:

    MSSQL for json path transforms 0 to false
    HOWEVER
    DataTables likes 1 better than true, and 0 better than false
    SO
    feed it what it likes

  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin

    That's interesting - the hidden field type shouldn't be changing the type at all - it just stores the original value. So when the comparison is done, it should be seeing the original type to compare against. I'll look into that. If you see any others like this, let me know - most likely they are type related as well.

    Allan

This discussion has been closed.