What requirements exist for uploading downloaded custom configs

[shaman-apprentice]

Question

I am not sure if this is a bug or designed behavior.

As a user I want to know why an upload failed.

Observed behavior:

1. Save a custom config and modify the file name ending when save dialog pop ups
2. Upload the same custom config
3. It fails due to invalid or missing API version

Question

I would expect that the third point would be a successfull upload. So my question is:

• Is this a bug?
• Is it designed behavior? Can we improve the error message in that case, that it becomes clear, that the file name must match a specific format?

[shaman-apprentice]

Similar question:

1. Create a custom config
2. Download custom config and use default name
3. Delete all custom configs
4. Upload downloaded custom config

The uploaded custom config is not applicable. What did I miss?

[Hall-Ma]

Edit: My text does not answer your questions, but the problem is real 😆

I have tried to track down the problem. In our demo, we load our sample files via URL. Therefore we analyze by query parameters in which mode our sample files should be loaded (delta, multiple or single). Our sample files haven't such a 'mode' query parameter. That means that the function getParameterByName() returns null and in getRenderStateFromUrl() we are running into the else block where the files are set to single mode.
Long story short, that is the problem why you can't use the custom views when uploading them again because they are saved in multiple mode (actually, we don't have the single mode anymore).
However, if you select the sample maps again, you can use the custom views again, because they have been set to multiple mode and this 'weirdness' is only shown with our sample maps. When uploading other files you can use the custom views as usual.

[shaman-apprentice]

That clarifies my second question, thanks! Any idea about the first one?

[ce-bo]

I can confirm what @Hall-Ma said. There is an issue with multiple/single mode.
@shaman-apprentice Regarding your first question: The file ending must be .cc.config.json. Otherwise (I guess) the file is going to be treaten as a normal cc.json map, isn't it?

[BridgeAR]

Ideally, files should be identified by their content and not by their file ending. I personally would in fact be fine to drop the .cc part.

[shaman-apprentice]

While extracting upload custom configs buttons for #2734, I found the (falsy) logic within fileChooser, which makes the file ending mandatory. I will fix the need for the specific ending within migrate-and-extract-upload-custom-configs-button