Add 'Replicate Previous Import' button to S3 and Filesystem imports

[willdunklin]

Addresses #16

[manthey]

I was expecting a button on each line of the past import list so maybe besides the Re-Import button there would be an Edit button (or some other short word) that would switch to the import form with that entry's values.

What often happens is that, on an active system, one has imported many things and we want to nearly redo a past import from a while ago (not necessarily the most recent one).

[manthey]

You should be able to run tox -e format,formatclient to resolve linting errors or see what needs attention.

[manthey]

This isn't the approach I was imagining. I was imagining no visible change to the assetstore import pages themselves. Rather, I was thinking there would be a second button on each line of the previous imports page. Besides "Re-import" there would be a button marked "Modify" (or maybe a different word). Clicking on Modify would switch to a fully populated assetstore import page for the appropriate assetstore.

Having separate drop down options for each parameter isn't obvious.

A typical work flow is: I import /local/path/dataset/one to collection/Study/Dataset I import /local/path/dataset/two to collection/Study/Dataset A while later, I want to import more, but I can't remember /local/path/dataset very well and don't want to retype it, so I click Modify and then edit it to be /local/path/dataset/three leaving the collection/Study/Dataset alone and click import.

Keeping the previous combination of path and resource is needed (selecting them individually loses the context between them).

[manthey]

This is looking good. There are few minor issues. When you are viewing Unique Past Imports, the Edit button doesn't populate the import page properly.

Even on tolerably wide displays, we end up needing more space, e.g., I was thinking that the edit button would just have the icon and no word and would have a tooltip that would say something like "Edit the import parameter". This would save a little horizontal space. Probably from a css perspective, we'd want the buttons to have a small gap between them and not break lines on wide displays (since they end up being taller than, say, the wrapped date strings).

If an assetstore has been removed, we show the id of the assetstore, and we can't edit (or reimport). So we really shouldn't show either button in this case. If the destination is gone, then edit reimport still can make sense (but not the plain reimport), since you might want to pick a new destination. As a simple test of that later, import to a folder, copy the folder and delete the original (because you might do this and rename the copy, then decide you don't need two copies), then you might want to reimport to the copied folder.

And, as a follow up PR, the folder icon for picking the destination should ideally open to the original destination rather than the no-where-in-particular default.

[willdunklin]

Sounds good. I made the UI changes you were mentioning:

The buttons are now conditionally displayed based on the existence of assetstores & destination paths.

[manthey]

Great. The only issue I see is when I group to unique past imports, the edit button goes to the import page but doesn't populate it.

[willdunklin]

Ah right, I'm in the process of getting that fixed currently! Forgot to add that before committing

[willdunklin]

Should be good to go with this set of features for now. I'm taking a look at adding the file browser integration now

[manthey]

Great. This is all working for me -- I'd like to remove the console.log statement before we merge it in.

[willdunklin]

Got it!

[manthey]

@willdunklin In the future, to make it easier to review changes, once comments are made on a PR, just made additional commits rather than force-pushing to the branch. If we end up with a lot of commits from a PR, we can do a squash-and-merge to keep the history clean.