Hello Aldup,

The row data object has been exposed as a second parameter in the column formatter function for the igGrid and this change is available in the latest SR for IgniteUI.

Please do not hesitate to contact me if you have any questions.

Hello Aldup,

Just wanted to let you know that exposing the row data through the custom formatter function in igGrid's columns is logged in our internal system with an ID of 133392. We will keep you posted of any developments regarding this matter.

Feel free to contact me if you need more information.

Hi,

Yes, Konstantin's suggestion is good, it would be very useful and covers my needs.

For the moment I bypassed the problem by reprocessing the data source before binding.

Thanks for your help,

Hello Alain,

Please let me know if Konstantin's suggestion is ok for you.

Hi again,

I played around with your sample a bit to figure out what exactly we can do in order to  accommodate for this scenario. Let me first say this, the grid is in general expecting its columns to be tied to a key from the data source meaning the column configuration is usually having access to only one data value from per cell. One way to do this is to have a separate column for each value and separate template for each column. I am saying this not only because of the architectural limitation of the templating engine to handle multiple sequential conditionals, but also because in your current sample the templating engine in fact receives only the value of the CanEdit property of your data rows. 

In order to avoid that you need to set localSchemaTransform: false in the grid options and a key for the column inside the column settings corresponding to one of the column values. Now this doesn't solve the issue with the templating engine not supporting the sequential if-s and using nested if-s for this doesn't make sense. So the way I figured you could achieve this is if we expose the entire data row inside a column formatter for you. In this way you would be able to return only one single value back to the templating engine and it would handle it just fine. If we do that your grid configuration will look like this:

$("#grid").igGrid({
    columns: [
    //Displayed Columns
        { headerText: "ProductID", key: "ProductID", dataType: "string" },
        { headerText: "Name", key: "Name", dataType: "string" },
        { headerText: "ProductNumber", key: "ProductNumber", dataType: "string" },
        {
            headerText: "Actions",
            key: "CanEdit",
            dataType: "string",
            formatter: function (value, data) {
            var string = '';
            string += data.CanEdit ? 'OK - ' : 'KO - ';
            string += data.CanDelete ? 'OK - ' : 'KO - ';
            string += data.CanRead ? 'OK - ' : 'KO - ';
            string += data.CanValidate ? 'OK - ' : 'KO - ';
            string += data.CanLock ? 'OK' : 'KO';
            return string;
        },
        template: '${CanEdit}'

        }
    ],
    autoGenerateColumns: false,
    localSchemaTransform: false,
    dataSource: products

});

If you want to put markup inside your value you just need to change the template to a non encoded one {{html CanEdit}}.

This is sort of a workaround but it doesn't hurt to get access to the data row inside the custom formatter function. Let me know what you think about this potential solution. If you like it then we can create an internal work item to expose the data row inside the custom formatter.