Interactive path chooser for informing user decisions

[jamoore]

During insight, the import process should include a prominent GUI element which allows the user to choose how many proceeding path elements will be eliminated from the server-side stored file.

For example, if the user has selected several files from:

C:\Users\me\Desktop\Data\Good

like

C:\Users\me\Desktop\Data\Good\OME-TIFF\Monday\screen1\...
C:\Users\me\Desktop\Data\Good\OME-TIFF\Tuesday\foo.ome.tif
C:\Users\me\Desktop\Data\Good\OME-TIFF\Wednesday\...

It should be possibly for the user to state that the top-N elements be removed. Here a value of 6 would remove C:\, Users, me, Desktop, Data, and Good, leaving OME-TIFF as the top-level.

If any conflicts are caused by this choice, for example if the user chooses to frequently omit OME-TIFF/* as well, then numbered parent directories will be created so that the user will have multiple directories named screen1.

Implementation details: server-side this would mean that a directory /OMERO/ManagedRepository/%user%/%date%%suffix%/OME-TIFF would be created if it doesn't already exist for this user and group pair, and if it does, %suffix% will be incremented to -1, -2, etc.

Note: This is very similar to how the patch utility works:

       -pnum  or  --strip=num

          Strip the smallest prefix containing num leading slashes from each
          file name found in the patch file.  A sequence of one or more
          adjacent  slashes  is counted  as  a  single  slash.  This controls
          how file names found in the patch file are treated, in case you keep
          your files in a different directory than the person who sent out the
          patch.  For example, supposing the file name in the patch file was

             /u/howard/src/blurfl/blurfl.c

          setting -p0 gives the entire file name unmodified, -p1 gives

             u/howard/src/blurfl/blurfl.c

          without the leading slash, -p4 gives

             blurfl/blurfl.c

          and not specifying -p at all just gives you blurfl.c.  Whatever you
          end up with is looked for either in the current directory, or the
          directory speci‐ fied by the -d option.

except in our case p0 and p1 will lead to identical results, since the path is being concatenated with the managed repo path.

[wmoore]

I don't think the GUI element for choosing file path should be prominent unless the clients also support browsing images via that path. If we don't get around to supporting that for 4.5.0, then the path chooser should be subtle, only for users who know ahead of time that they want to access files directly from the managed repo.

So, are we going to try and support path browsing in the clients for 4.5.0?

Also, the repo path chooser should allow users to manually enter a destination path, for cases where the local path to images is meaningless / incorrect.

[jmoore]

Replying to wmoore:

I don't think the GUI element for choosing file path should be prominent unless the clients also support browsing images via that path....

We'll have to try it before we know.

So, are we going to try and support path browsing in the clients for 4.5.0?

No.

Also, the repo path chooser should allow users to manually enter a destination path, for cases where the local path to images is meaningless / incorrect.

Agreed.

[jburel]

Referencing ticket #9821 has changed sprint.

[jburel]

Decision is not to allow users to select path for now

[jmoore]

Should we close this then, and instead open one for adding a "list FS files" button as Will has done in web?

[jburel]

see #10351