-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PTV-1886 staging area limit file size #3312
base: develop
Are you sure you want to change the base?
Conversation
… icon, add hover effect for the button (affordance), in detail show info tab by default, remove unnecessary bluebird, rename import that conflicts with built-ins, minor formatting improvements [PTV-1886]
Fixes case of 0-length file, uses Alert rather than showing warning in same style as file snippet, handle null as head/tail snippet as well as the bespoke text value "not text flie" [PTV-1886]
…n, set maxFileSize for dropzone widget, support decimal and binary file sizes explicitly (and in appropriate places), handle 413 (request entity too big) errors, generally improve dropzone layout and styling, display max file size in dropzone, fix globus link handling and use a dialog before opening a new window to catch and display errors [PTV-1886]
… it internally, especially when debugging tests! [PTV-1886]
note - need another pass at tests to cover changes during PR-preparation
some test cases added, some unused code removed, some code simplified
…rea-limit-file-size
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## develop #3312 +/- ##
===========================================
+ Coverage 29.22% 29.27% +0.04%
===========================================
Files 495 495
Lines 50482 50545 +63
===========================================
+ Hits 14755 14798 +43
- Misses 35727 35747 +20
... and 4 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
Before and after user interface: |
…rea-limit-file-size
…rea-limit-file-size
@Bill @ialarmedalien resolved merge conflicts, merged the repaired tox.ini into .flake8, some code quality fixes to make the bots happier. Don't know why the integration tests aren't passing. I spot checked one of the narratives involved for a failing public data test, and it looks fine. (Such integration tests will occasionally fail due to changes in ref data since they use live CI services.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot happening here, but this looks good.
Got a couple minor changes and suggestions for you.
|
||
For a custom 413 response, first define a location within the server block handling the `staging_server`. | ||
|
||
```nginx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this set up in the staging service? I know you were making changes there, too, with @bio-boris .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will come from changes to the nginx proxy. I've included the instructions, at least for what worked for me.
I tested this out by setting the kbase-ui proxy up with a low limit to trigger the 413 for arbitrary file sizes.
Yes, there is a set of changes coming for the staging service too, but the Narrative changes (other than the handling of a custom 413, which is auto-detected) don't depend on them. However, for anyone sending files between 4.4 and 5GB, the current staging service will crash. The upcoming changes address this.
@@ -78,8 +79,8 @@ | |||
|
|||
.kb-dropzone { | |||
border: 2px dashed use_color('mid-blue') !important; | |||
margin-bottom: 5px; | |||
max-height: 150px; | |||
// margin-bottom: 5px; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can just delete these. I don't think they need to come back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roger that.
@@ -91,14 +92,23 @@ | |||
.dz-message { | |||
color: rgb(0 0 0); | |||
font: normal 400 24px/28px $typeface-page-text; | |||
margin: 2em 4.5em; | |||
// margin: 2em 4.5em; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, ye ole "not sure this will work, keep an eye on it and remove later" that doesn't get removed.
Gone, and also rearranging a bit to put styles where they should be, and adding some of those "this is the full path of this style" comments. They do help clarify, as nested styles can be painful to follow...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the nested styles are hard, having the full path as a comment is very helpful!
} | ||
|
||
// .kb-dropzone__message--upload | ||
&__message--upload { | ||
font-family: $typeface-page-text; | ||
font-weight: 700; | ||
} | ||
} | ||
|
||
&.dropzone.dz-clickable button { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
// Bootstrap overrides | ||
|
||
// necessary? | ||
.progress-bar { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might not be necessary at this point, but Bootstrap's progressbar is occasionally an oddball, and was annoying to work against Dropzone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bootstrap already sets the width for .progress-bar to 0, and I don't see anywhere in the KBase codebase that sets this class otherwise that would need overriding.
Also, in the widget code the width is set via direct style to '0' on reset, but should probably set it to '' to remove the style and let the class style take over.
Anyway, it is working, so I don't see any reason to change anything here, other than the fact that these files are being revised and who knows when the next opportunity will come.
// Realistically, this should poll until the condition is met, or | ||
// timeout. Reason being that in real usage (or if using a real service mock), | ||
// the call that generates the error may take an indeterminate amount of time, | ||
// and certainly will not be on the next tick of the event loop. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's some tooling in testUtil
that might be helpful to get the behavior you mention. The waitForElementState
function might make the most sense here. Then you can make it an async
test, await
on that, and it'll fail if it times out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The existing file upload widget tests don't use that, I guess, since it was made later. If this works and is stable for now, that's fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it works, so I don't see a reason to just change it.
It was more of a note to preserve the fact that it only works because it is using a specific style of mock service. It would fail, e.g., in an integration test, or a mock service which is either a true http server or includes a modest delay to simulate a network call.
I had just been through evaluating the implementation with different browsers. If memory serves, I found that some browsers wait for a good long while before reporting back the 413, others immediately, but in all cases it is a network call to the service occurs first, which is certainly longer in duration than a 0ms timeout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that sounds reasonable.
@@ -0,0 +1,107 @@ | |||
define(['jquery', 'util/bootstrapDialog'], ($, Dialog) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
@@ -1,14 +1,23 @@ | |||
<form class="kb-dropzone dropzone" style="min-height:200px"> | |||
<form class="kb-dropzone dropzone" | |||
style="min-height:100px; display: flex; flex-direction: column; justify-content: center;"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you move the inline styles to SCSS?
Thanks for looking at it, @briehl, working on it. |
SonarCloud Quality Gate failed. 0 Bugs No Coverage information Catch issues before they fail your Quality Gate with our IDE extension SonarLint |
Let me know when this is ready for re-review, thanks! |
Description of PR purpose/changes
The primary motivation for this set of changes is to ensure that the staging area widget applies a file size limit of 5GB to user uploads. This is achieved by setting that value in the Narrative config template, and propagating that value to the dropzone widget. This code was in place, although the max file size value was inaccurate.
In addition, there are changes around ensuring that this and related errors are properly displayed. And around this are changes to ensure that the staging upload widget communicates this file size limit to the user.
One related set of fixes applies to the usage of decimal and binary measurements of file size. In several cases these units were mixed and up and communicating incorrect information to the user. The important distinction is that users will be aware of decimal file size (e.g. MB, GB) as that is what is reported by most operating systems and tools that rely upon them. On the other hand, the dropzone widget and nginx work in binary file sizes (e.g. MiB, GiB). So there is code to convert back and forth and ensure that users see file sizes in decimal. Generally all code uses file size measurements in bytes.
A document attached shows the before and after ui states.
Jira Ticket / Issue
Related Jira ticket: https://kbase-jira.atlassian.net/browse/DATAUP-X
DATAUP-69 Adds a PR template
)Testing Instructions
Dev Checklist:
Updating Version and Release Notes (if applicable)