Added download permission checkbox in frontend
Added share attributes parsing and setting in frontend.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Note that the quota may change too when files are moved if the file is
moved, for example, to or from a folder shared by other user.
Besides the quota the storage statistics are also updated, similar to
what is done when a file is deleted.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The JavaScript code that updates the quota text expects the element to
have "quotatext" as id.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"t()" escapes and sanitizes the returned text by default, so strings
like "<" are converted to "<". However, the "jQuery.text()" parameter
does not need to be escaped, as "<" is shown literally as "<"
rather than "<". Now "jQuery.html()" is used instead, which "unescapes"
the given text and sets it as a new text node (as the text in the
parameter does not contain markup for elements, only text).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Probably here for legacy reasons, but it is a bit weird to call an .php
endpoint that doesn't correspond to a .php file
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
(cherry picked from commit c7931086cc)
Many users are getting confused by the inaccurate error message "Home storage for user $user not writable" because the storage *is* writable. The actual issue is a missing files/ subdirectory. cf. https://help.nextcloud.com/t/home-storage-for-user-not-writable/10831/7
By mentioning the possible cause in the error message, users are going to be able to rapidly solve their problem rather than bang their heads against the screen, Google, and eventually forums to find out that the error message is wrong in their case.
Yes, it would be better to detect and precisely describe the fault, or fix the problem automatically, but until then, be kind to the users for the next however many years.
When an upload fails a toast is shown with either a specific message or
just the textual part of the HTTP error code (which comes from the
upload failure handler and set by "jQuery.ajax()". However, if there
is neither a message nor an error then the toast will show the default
message from the Toastify-js library, which is an undescriptive "Hi
there!".
When HTTP/2 is used Chromium does not provide the textual part of the
HTTP error code, so when an upload fails the toast can receive an empty
message and thus just show "Hi there!". Now an explicit message is
provided as a fallback to prevent that.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
occ files:scan reports error "Implicit conversion from float XXX to int loses precision"
Signed-off-by: cld4h <20869428+cld4h@users.noreply.github.com>
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
