-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Exporting all data #32
Conversation
3d378b9
to
0a9d3ec
Compare
As explained in the issue exporting all data is unfortunately not as easy as it looks. You cannot simply use the first log entry to retrieve the export columns since the log can contain entries of various different forms with completely different fields. So you'd be left with traversing all log entries to make sure to add all possible columns to the export. This would be overkill given that there can be thousands or millions of entries. So for now explicitly configuring all known columns manually is the only option ATM. Do you have another idea? Otherwise I'm afraid I won't be able to accept the proposed change like this. |
OK I understand. But in this case we will also need some UI adjustments to make it clear to editors what will happen on export. |
@@ -76,6 +76,9 @@ module { | |||
property = submissionDate | |||
label = formlog.entry.submissionDate | |||
} | |||
60 { | |||
property = __allData |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should integrate this a bit differently because it actually doesn't make sense to configure some columns explicitly only to have it ignored by this special column.
We could have an additional option at the same level as columns
for this and maybe consider something like a labelPattern
(like LLL:EXT:foo/locallang.xlf:formlog.entry.%s
) where one could easily integrate custom labels.
@PhilippKuhlmay Sorry for the late response: we'd actually need two separate actions here, e.g. using a 2nd export button which is only clickable if entries have been filtered by a single form. That button needs the same target format selection (CSV/XLSX currently). But that by itself will be confusing and rather unclear so it needs a better UI/UX concept. Also we need to take into account that form definitions are not immutable. It's perfectly fine to add, remove or change fields in a form definition over time. This would mean that even log entries from the same form could have different fields. Thus we'd have the same problem as with exporting all entries of all forms. |
what about adding a hash over the full configuration (or all fields + finishers) and do some basic versioning with it? |
Hi, adding my 2 cents here ;-) The usecase of mostly all of our customer is:
So, having something like that would fit perfectly the usecase:
|
@dogawaf Would you like to propose your workflow as separate PR? |
I now use https://extensions.typo3.org/extension/form_to_database which does everything I need. |
Fixes #17