DataTables logo
≡

Excel export regression when adding columns in customizeData

Excel export regression when adding columns in customizeData

peter.brunspeter.bruns Posts: 9Questions: 7Answers: 0
in Buttons

Link to test case new version (failing 3.1.3): https://live.datatables.net/picazufe/1/edit
Link to test case old verison (working 2.3.4): https://live.datatables.net/yetuviba/1/edit

Error messages shown: dataTables.buttons.js:997 Uncaught TypeError: Cannot read properties of undefined (reading 'includes')

Description of problem:

Hi,

I think I found a regression in the Excel export after upgrading from DataTables 2.x to 3.x.

My setup previously worked with:

  • DataTables 2.3.4
  • Buttons 3.2.5

After upgrading to DataTables 3.x, Excel export fails if I add extra export-only columns inside exportOptions.customizeData and also update headerStructure / footerStructure.

The export fails in addRow at:

columnTypes[i].includes('num')

For the added export column, columnTypes[i] is undefined. It looks like columnTypes is still based on the original DataTable columns, while the customized export data now contains additional columns.

Interestingly, adding the extra values only to header, footer, and body does not trigger the error. It starts failing once I also add the corresponding entries to headerStructure / footerStructure.

However, without updating headerStructure / footerStructure, the added columns don't appear correctly in the exported header/footer.

The same customization works with DataTables 2.3.4.

Is this an unintended regression, or has the expected way of adding export-only columns changed in DataTables 3.x?

This question has an accepted answers - jump to answer

Answers

  • allanallan Posts: 66,097Questions: 1Answers: 11,019 Site admin

    Hi,

    Many thanks for posting this. To be honest, I hadn't really expected an additional column to be added to the export by manipulating those arrays! The Excel exports checks the column's data type to see if it should be exported as a number or not. Of course if there is no matching column, then that is going to fail.

    What I've done is to add an extra guard to make sure that the type is available before it is used. That will be in the nightly build shortly if you'd like to try it out there, and it will be in the next patch release.

    What I'm thinking on top of that, is that it might be an idea to include the column types in the exportData object. Then you could possibly manipulate that array as well as the data and structure arrays.

    As a quick note, since you mentioned it - the export no longer uses header and footer, but rather uses the structure parameters as they have colspan / rowspan and multi-row information for the header and footer, while the original properties do not. They are a single row for backwards compatibility. The export features don't make use of them any more.

    Allan

  • peter.brunspeter.bruns Posts: 9Questions: 7Answers: 0

    Hi Allan,

    a extra propertie for the column types would be greate addition.

  • peter.brunspeter.bruns Posts: 9Questions: 7Answers: 0

    Hi Allan,

    I created a pull request for this:

    https://github.com/DataTables/Buttons/pull/217

  • allanallan Posts: 66,097Questions: 1Answers: 11,019 Site admin
    Answer ✓

    Many thanks :). That's it merged in and it will be in the next release of Buttons.

    Allan

Sign In or Register to comment.