Issue CSV export of dbjoin as checkbox

[troester]

If elements= all selected for CSV export it's exporting correctly

Table___dbjcheckbox
label13,label7, etc

but also additionally columns with table___dbjcheckbox_id, table___dbjcheckbox_params

If elements=visible (and dbjcheckbox is in list view) or elements=selected (and dbjcheckbox selected)
it's exporting
table___dbjcheckbox_id
13//..*..//7

instead of table___dbjcheckbox
label13,label7

 

[troester]

Friendly bump

 

[cheesegrits]

Looking at it now.

-- hugh

 

[troester]

It doesn't make a difference if the element is included in list view or set to "always render".

It's always exporting this "raw values" with table___dbjcheckbox_id
which is no existing element at all
The element in the list is table___dbjcheckbox

table___dbjcheckbox_id is an "artificial"one which seems to be doing some group concat on

table_repeat_dbjcheckbox.dbjcheckbox WHERE parent_id = myrowid

 

[cheesegrits]

OK, on the first case, with the export of the foo_id and foo_params ... those are "derived" values we use internally, describing the auto created many-to-many table (<table-name>_repeat_<element-name>). The lines of code where they get added is in the csvexport.php model, lines 702 to 712, where we add $data element names not found as actual elements.

I'm not 100% sure why we add them. I suspect it may be to do with being able to import that data again, as I think we'd need those values in order to recreate the many-to-many entries. However, I also noticed that by including them, other data gets bumped over into them (so in my case, where I have foo___name as the next element, name is missing from the export, and the name values are in the foo_param column). So obviously the mechanism is broken.

So try commenting those lines out, so it doesn't add !$found names to $h.

When I do that, it seems to export OK. Although I have a hunch it wouldn't correctly import.

-- hugh

 

[troester]

Hmm, doesn't help.
The only difference is that now the column header is empty (I've set to export element labels and there's no label for this strange "table___dbjcheckbox_id" element).
It's still exporting "3//..*..//2" instead of "my-dbjoin-label3, my-dbjoin-label2"

 

[troester]

ok, the column header is not empty but not displayed, screwing up the column data

Setup: "frontend option =no" + export = all
With Heading format =short element name or label and the original csvexport.php the csv file is "correct", showing the expected dbjoin labels in the element column but the additional columns xxx_id and xxx_params
With your modification it doesn't display this additional headers but it still displays this row data --> so all column data after the dbjoin-checkbox is wrong

With Heading format = full element names this "column headings not matching data" is already with the original csvexport.php and no difference with the modified code.

Setup frontend options=yes:
Original code: It doesn't display the selected element with dbjoin labels but xxx_id with concatenated raw values.
Modified code: it doesn't display the column header but still these "raw" values, so screwing up the following columns.

 

[cheesegrits]

Meh.

I'll have another go at it soon.

-- hugh

 

[troester]

I think I've found it.
The problem is not in csvexport.php, it's already in the $data.

In models/list.php setHeadingsForCSV is doing

                    $pName = $elModel->isJoin() ? $db->qn($elModel->getJoinModel()->getJoin()->table_join . '___params') : '';

                    foreach ($asFields as $f)
                    {
                        if ((strstr($f, $db->qn($name)) || strstr($f, $db->qn($name . '_raw'))
                            || ($elModel->isJoin() && strstr($f, $pName))))
                        {
                            $newFields[] = $f;
                        }
                    }

which is setting this xxx_id element.
But I don't know how to get the correct one.
It's correctly exported if export is set to "elements=all", so Fabrik "knows" how to do it.

The additional _params etc. elements in the export with "all" elements are
in csvexport.php line 188 ff.
They are removed correctly - but only if export is set to Data AND Data_raw. Any reason for this?

One more issue with export overriding the list's start and limit.
I think this is in view.csv.php:
it should store the original list's ones and reset them after the export (not sure if in sessions and/or in input)
I have seen this again
https://github.com/Fabrik/fabrik/issues/1643

 

[troester]

Friendly bump.

Main issue:
Dbjoin as checkbox is not exported correctly if the elements are set to visible/selected/frontend select/via URL.
(It IS exported correctly with elements = all, so Fabrik "knows how to")

 

[cheesegrits]

I'm trying to find some time to work on this.

-- hugh

 

[troester]

to keep it on the radar...

 

[cheesegrits]

Yup, I haven't forgotten, just trying to find time to work on it.

-- hugh

 

[troester]

Still here

 

[troester]

One more little bump...

 

[troester]

Any news in 2017?

 

[cheesegrits]

Have you tried it recently? I kind of half way fixed some of that in another thread on this stuff.

-- hugh

 

[troester]

Seems I have overlooked a related commit.

I just tested:
Yes, it's exporting the dbjoin-checkbox element xxx now
not only if exporting "all" elements (as it was before), but also with elements = "visible" and "selected"

But
With setting: data=yes, raw=no
it's additionally exporting xxx_id and xxx_params (headers and columns)

With setting: data=no, raw=yes
the rows are exportet correctly
dbjoin_checkbox_raw
["30","1"]
but the headers have additionally xx_id and __params (so following columns have wrong headers)

same with data=yes and raw=yes (additional headers xx_id, xx_params)

 

[troester]

Hmm, I have the feeling this may be related:
With an ajax fileupload element in list view I get error 500 after the recent GitHub update
...
(SELECT GROUP_CONCAT(attachments SEPARATOR '//..*..//') FROM brief_repeat_attachments WHERE parent_id = `brief`.`brief_id`) AS `brief___attachments`, (SELECT GROUP_CONCAT(id SEPARATOR '//..*..//') FROM brief_repeat_attachments WHERE parent_id = `brief`.`brief_id`) AS `brief___attachments_raw`, , (SELECT GROUP_CONCAT(params SEPARATOR '//..*..//') FROM brief_repeat_attachments WHERE parent_id = `brief`.`brief_id`) AS `brief___attachments___params`,
...

Fabrik debug in the old version is showing
...
(SELECT GROUP_CONCAT(attachments SEPARATOR '//..*..//') FROM brief_repeat_attachments WHERE parent_id = `brief`.`brief_id`) AS `brief___attachments`, (SELECT GROUP_CONCAT(id SEPARATOR '//..*..//') FROM brief_repeat_attachments WHERE parent_id = `brief`.`brief_id`) AS `brief___attachments_raw`, (SELECT GROUP_CONCAT(params SEPARATOR '//..*..//') FROM brief_repeat_attachments WHERE parent_id = `brief`.`brief_id`) AS `brief___attachments___params`, ...

so the error is coming from the double , ,

(but the "params" (obviously coming from the repeat table) shouldn't be there in both cases )

 

[cheesegrits]

I just fixed that locally, I'll commit soon.

Sent from my HTC 10 using Tapatalk