Bug #33062
export get mixed up
| 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.
History
Updated by Martin Holtz over 1 year ago
- File 33062_v1.patch added
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