Allow to use entity export csv configuration in the form export

Suscribe to this feature because I don't understand what is the point. Drush usage ?
Because I need to set again Machine name instead of label every time I do an export... :( I thought config could avoid this .

Understood. Actually when I save a setting when I redo an export some fields doesn't keep the previous settings. But part of the job is done :)
I'm not PHP dev so I can't help on patch ;)

I think the solution here is a "revert to default" button maybe on each entity type. And maybe a drush command to wipe the settings for all users and revert to default, deferring to config if one exists.

If there is a config entity for that export, it will revert to that config. Right now, that config is never used, it seems, even on a fresh install of the module.

In the form logic there is a TODO in comments

// @TODO handle configuration values
$configuration_default = isset($user_default_values[$field_name]['form']['options']) ? $user_default_values[$field_name]['form']['options'] : [];

It seems like there should be a $config_default instead of [] where it gets the data from config. But the UX is not clear, which is why I would suggest having a "revert" or "reset" button that essentially deletes the $user_default_values that is stored per-user.

That makes sense. But I think there are two use cases we can add to this situation and take advantage of the config.

• The module was just installed and the user has never done an export. The config should determine what shows up the first time a new user uses the export form.
• A new entity/bundle is enabled for export by the admin. The user has never done that export before. The config should determine what shows up the first time a new user uses the export form.

The use case I am thinking is if you are delivering a website with export functionality to the client, you may want to set up some settings for them in config instead of them having to figure out all the formatting options. The same for any new user to the system.

What would also help is an API documented or in-UI block/widget creator that we can say "Here is a button to generate this export, according to this config set"

The alternative to this module is using views and views_data_export spending lots of dev time wiring up all the fields and formats and permissions for every single entity. I think that is overkill for many usecases, which this module can more directly address. For instance, a site owner wants to export structured but human-readable data into another software to do data analysis.

I made a crude mockup according to my idea of what this issue is looking for. It is shown below.

I added the 'Use Saved Configuration' drop down. This assumes that the 'Basic Page Configuration Setting 1' and 'Basic Page Configuration Setting 2' are configurations that the user has saved for a Basic Page on the Entity export csv configuration entities page (/admin/config/content/entity-export-csv/configurations). After the selection is made from this drop down, then the values for all of the fields will be populated according to the item that was chosen.

I left None as the default choice, which I am assuming would enable all of the fields as a default. Or, perhaps per the discussion so far, we might want to have None display the default from what the user has already saved. Or perhaps we want to have another choice of 'Default' for using what the user saved from their previous usage. That would seem to be another aspect open for discussion.

Am I on the right track here? Is this along the lines of what you had envisioned for this issue? Are there things that should be changed?

Looking forward to feedback about this.

I just installed the module and it's quite great. Only thing bothering me is that export config is stored per user and not in yml config. This is not practicable in a multi user setup. A default config on a node type basis would be highly appreaciated.

Here's a patch that allows using of configured exports in export csv form while also retaining the original weirdish user data features.