Bug 879347

As simple as you would think this would be, its ridiculously hard to figure out how to get this to work.

It is simple to write the code to do what we want. In this method:

  org.rhq.enterprise.gui.coregui.client.components.upload.FileUploadForm.submitForm()

we simply want to check to see if the file exists and is readable:

    // --- START BZ 879347
        } else if (!new java.io.File(value.toString()).getAbsoluteFile().canRead()) {
            String message = "Make sure the file exists and is read-accessible";
            changeIcon(iconRed, message);
            setUploadError(message);
            // note - don't even submit this definite failure            
    // --- END BZ 879347
        } else {
            changeIcon(iconLoading, MSG.common_msg_loading());
            uploadInProgress = true;
            super.submitForm();
        }

The problem is, SmartGWT doesn't want to tell us the full path of the file the user selected!!! value.toString() is returning just the name of the file with no path information - even though (in FF at least) I can see the absolute, full path of the file in the text field of the file upload component. So I know the component knows the full path, its just not telling me what it is. I tried other APIs on the component but nothing it giving me the full path. So I have no way of actually checking to see if the file is readable.

Also, I have error callbacks set up, but for some reason, the component isn't calling my error callbacks if it fails to read the file. So even that code isn't able to detect the problem and report it to the user.

So, there are roadblocks all through this that is making it impossible for me to even ask the GWT API to tell me if there is a problem so there is no way for me to avoid doing the upload if I know it will fail, nor is there a way for me to be told this problem occurred during the upload.

From the SmartGWT Javadoc:

http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/widgets/form/fields/UploadItem.html

"NOTE: Browser-specific behaviors:
while getDisplayValue() can be used to retrieve the filesystem path of the uploaded file on some browsers, different browsers will return either just the file name without path or the full path. It is plausible that some browsers may switch behavior in the future to not supply this value at all. Do not rely on this value."

This is exactly what I see with the getValue() API as well. Terrrrrrific!

Mazz,
can you please re-visit this?
Could we just tell that to upload to some "random" temp file? And require the (target) file name to be provided on top of that?

The REST-api now also has an upload option, where a tmp-file is created and a handle returned to the caller. Perhaps that is helpful in some way.

(In reply to Heiko W. Rupp from comment #3)
> Mazz,
> can you please re-visit this?
> Could we just tell that to upload to some "random" temp file? And require
> the (target) file name to be provided on top of that?
> 
> The REST-api now also has an upload option, where a tmp-file is created and
> a handle returned to the caller. Perhaps that is helpful in some way.

Can you explain? Are you saying to upload to a temp file and then we rename that temp file? If so, the problem isn't the target. The problem is the source. The user doesn't have read permissions on the file he's trying to upload. So the problem is occuring on the client side.

Ohhh. Fixing pebkac :)

This may help then: http://www.html5rocks.com/en/tutorials/file/dndfiles/#toc-monitoring-progress

I don't think this is a solvable problem using smartgwt's UploadItem widget. There is no way to get the full path (this is not a bug, it's for security reasons) and therefore we can't check the read access.  It's unclear why the upload hangs, I would consider that a smartgwt bug although I don't see any mention of that issue in their forums.

We need to know how much effort should be expended trying to support this use case of someone trying to upload a bundle they can't physically read.

I came across this potential alternate widget: 

  http://www.moxiegroup.com/moxieapps/gwt-uploader/

But it does not in the public maven repos.  So even if it worked for us we'd have to drop it in our private repo.  I don't think we should work on a replacement unless we determine this is really necessary.  Even if we do, it may not pan out.

Asking for re-triage from GSS...

Moved to 3.3 as this is a non critical issue.

Although this is a bug in the client side code, the file a user wants to upload must be readable by the user who is attempting to upload it.

This needs to be investigated further to see how we can fix this.

There is no more to add than what is above, this is either unsolvable or may require a lot of work (and maybe still doesn't work).  Pushing to JON 4 and maybe  a different GUI technology.

JBoss ON is coming to the end of its product life cycle. For more information regarding this transition, see https://access.redhat.com/articles/3827121.
This bug report/request is being closed. If you feel this issue should not be closed or requires further review, please create a new bug report against the latest supported JBoss ON 3.3 version.