[Feature - Max Attachment Size] - UI check and notice implemented. BE validation, ENV variable, tests added. Readme updated. #115
Conversation
milos-dukic
changed the title
milos-dukic
force-pushed
the
feature-max-attachment-size
branch
from
5626e6d to
562679e
Compare
… validation added. ENV added. Tests added. Readme updated.
milos-dukic
force-pushed
the
feature-max-attachment-size
branch
from
562679e to
7daf51b
Compare
| </div> | ||
| </fieldset> | ||
|
|
||
| <div class="composer-notice" data-composer-target="attachmentNotice">File exceeds max attachment size (<%= max_attachment_size_in_bytes %> bytes)</div> |
There was a problem hiding this comment.
Given that a regular user who reads an error message about a max size in bytes will not understand what the limit is and the error message will leave them wondering, I find it much more intuitive for the error message to be in megabytes (MB). Megabytes is something that most users understand, and the file limit that most sysadminds would choose, will also be in megabytes.
There was a problem hiding this comment.
Yeah, but size in MBs is rounded(when you try to inspect/view file properties), while in bytes it isn't, and that can be a bit confusing, bytes are more precise.
| padding: var(--block-space-half) calc(var(--inline-space) + 1vw); | ||
| } | ||
|
|
||
| .composer-notice { |
There was a problem hiding this comment.
Looking at the screenshot preview, I think it would be better (In terms of UI) for the error message to be a little further from the message/input box (eg. a margin-top of a couple of pixels or similar).
There was a problem hiding this comment.
Yeah, the problem is that input element for texting, is stand-alone component i.e. external library, so that is the reason I put it below.
2 participants
This is the PR for #103
MAX_ATTACHMENT_SIZE_IN_BYTESaddedMAX_ATTACHMENT_SIZE_IN_BYTESaddedPreview:
