CoreCommunity ExtensionsIncubatorDistributionsTYPO3 4.5 ProjectsTYPO3 4.6 ProjectsTYPO3 4.7 ProjectsTYPO3 6.0 ProjectsTYPO3 6.1 ProjectsTYPO3 6.2 Projects (+)

Bug #33062

export get mixed up

Added by Martin Holtz over 1 year ago. Updated about 1 year ago.

Status:Rejected Start date:2012-01-09
Priority:Should have Due date:
Assignee:- % Done:

0%

Category:-
Target version:2.0.0
Votes: 2 (View)

Description

Sometimes, i have an different ordern in the saved piVars-Array.

F.e.:

<piVars>
   <uid2>Hello</uid2>
   <uid3>World</uid3>
<...

<piVars>
   <uid3>World</uid3>
   <uid2>Hello</uid2>
<...

If that both records are exported, the CSV would be like

Hello;World;
World;Hello;

Because the keys are not respected while export.

IMHO it is a bug, not a missing feature. And perhaps it could be declared of an but while saving the piVars, but i guess, it there are keys, they should be respected.

33062_v1.patch (4 kB) Martin Holtz, 2012-01-09 15:23


Related issues

related to powermail - Feature #29799: Make export consistent Rejected 2011-09-15

History

Updated by Martin Holtz over 1 year ago

added patch.

Now, the piVar-Rows are based on the headerPiVars instead of the piVars which are available in the record itself

foreach ($headerPiVars as $key => $headerValue) {
. So, only the piVars which are defined in the header are shown.

The old implementation creates the header based on the piVars in the record with the most piVars. Now all used piVars in all records are taken to create the header.

This example works now:

<piVars>
   <uid2>Hello</uid2>
   <uid3>World</uid3>
<...

<piVars>
   <uid3>World</uid3>
   <uid2>Hello</uid2>
<...

But if an field gets deleted and another gets added, it will export all fields.

This example shows two records, where the field with uid3 gets deleted and a new one uid4 is created:

<piVars>
   <uid2>Hello</uid2>
   <uid3>World</uid3>
</piVars>

<piVars>
   <uid2>Hello</uid2>   
   <uid4>http://www.typo3.org/</uid4>
<piVars>

The export would be look like this:

Label UID2;uid3;Label UID4;
Hello;World;;
Hello;;http://www.typo3.org/

As the Field uid3 is deleted, we do not get the label via getFieldLabelFromBackend. I am not sure, if we should supress deleted fields - or if we allow the function getFieldLabelFromBackend to ignore enableFields.

These changes are not done for generateXlsTable, as i am not able at the moment, to test it. But it should be pretty simple to change generateXlsTable too.

Updated by J. Peter M. Schuler about 1 year ago

The problem described here and in the other bugs could be considered "own fault" due to changes/deletion in the fields, but the same problem arises if one uses optional fields and these fields are not filled by some users.

The applied patch works well with latest stable and trunk. Are there any open questions, considerations or scenarios that Martin or me didn't see?

P.S.: I tried several extensions as well and even the nwe formhandler. But powermail ist the only correct solution (i.e. editors are able to create new forms without a single line of TypoScript or using Plugin options) and so I'd really like to help fix this issue.

Updated by J. Peter M. Schuler about 1 year ago

Patch still works with Powermail 1.6.6 and TYPO3 4.5.15. Any chance it may get inlcuded in future versions?

Updated by Alex Kellner about 1 year ago

  • Target version set to 2.0.0

Updated by Alex Kellner about 1 year ago

  • Status changed from New to Rejected

Also available in: Atom PDF