Add import/export API actions

[berthieresteban]

What does this PR do ?

Add import/export features to API Actions view

Buttons import/export to left corner in sidebar export:

• open modal with table listing all the saved queries of all env (in the localStorage)
• allow to check one or more queries
• export button modal-ok

import:

• open modal with file input (file explorer/drag n drop)
• multifile import supported
• list of files to import (size and remove button)
• list of queries to import
• allow to edit queries name before import (inputstate (red/green) = name already used)

Tests added:

• Export a query in file and check file content
• Import a query with file
• Change a query name while importing

How should this be manually tested?

• Step 1 : create and save some queries
• Step 2 : click the export button and check the file
• Step 3 : delete your previous saved queries
• Step 4 : click the import button and upload the previous downloaded file

Other changes

/

Boyscout

/

[xbill82]

Er... What happened to the Netlify previews? 👀

[xbill82]

I need to dive back into the code but, looking at the PR description, I find it weird to be able to export the API actions for all the environments, given that one cannot see other environments' actions in the list on the left sidebar. To me

• Either API actions are cross-environment (i.e. all the actions are always visible no matter to which Kuzzle the AC is connected to) and therefore exportable
• Actions are separated by environment, so one can only export the actions of the current environment (i.e. the current connection).

What do you think @berthieresteban @Aschen @Njuelle ?

[berthieresteban]

I need to dive back into the code but, looking at the PR description, I find it weird to be able to export the API actions for all the environments, given that one cannot see other environments' actions in the list on the left sidebar. To me

• Either API actions are cross-environment (i.e. all the actions are always visible no matter to which Kuzzle the AC is connected to) and therefore exportable
• Actions are separated by environment, so one can only export the actions of the current environment (i.e. the current connection).

Your first point is convenient, the second is structured

IMHO Both have pro and cons

• First point UX is way worse in (in sidebar, no need to see actions for a specific plugin of one env in all other env, nor search actions for specific document ID / collection mapping), would need to implement a better error handling with user feedback and maybe change the sidebar UI
• First point Avoid duplicate simple actions in each env
• First point Allow user to export action of another env (convenient to share an action without need to change env while working on one)

I don't think that it is a problem that actions displayed when see / import-export are different Maybe if the import export modal display an env selector with current env by default for example you might find it less weird ? Also, listing the pro/cons above let me think that a "global" actions folder accessible in each env could be a good feature to avoid action duplications

[xbill82]

@berthieresteban I understand your point and it makes me think that actions could be not specific to an environment. Imagine you have three environments for the same Kuzzle app (which is the case for most of our users), then you are likely in the case of performing one same action for more than one environment, right? In this case, it is OK to go to the export menu and choose the actions from another environment and then re-import them, but... wouldn't it be more convenient to just access all the actions from the same view?

[rolljee]

Closing this, as this is now quite old. This should be reopened if this feature reach the roadmap