Refers to issue #8220
user_ldap configured with custom filters for active directory access
(group-member-association is "member"). Then it can happen that the
members of a group contain members that don't belong to the users
available in Nextcloud (the most trivial reason is that the user filter
contains "(!(UserAccountControl:1.2.840.113556.1.4.803:=2))" to exclude
disabled users from being imported).
This can be fixed by applying the ldapUserFilter when resolving the UID
for a DN fetched from the group's member list.
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
When the browser reports a drag of items other than files (for example,
text) and then triggers a drop event with no files no error message
should be shown to the user, as in that case there would be no highlight
of the drop zone and no indication that the drop would be valid (except
for the mouse cursor); the error message should be shown only when
the drop event with no files follows a file drag.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The highlighting was removed in Firefox when the cursor was no longer
moving to handle the behaviour of reporting a file drag and then
providing no files in the drop event. That behaviour (which was only
present in Firefox 48 and 49) is already handled with the "dropnofiles"
callback, so that special handling is no longer needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a file is dragged from the desktop to the file list the file list
is highlighted, and when the file is finally dropped or the drag
operation is cancelled the highlighting is removed. In some cases, due
to a wrong implementation, a browser may end a file drag with a drop
with no files (for example, when a folder or text is dragged), which
would cause the highlight to not be removed. Now those cases are handled
with the "dropnofiles" callback, which restores the UI and also shows a
message to the user.
The error message is just a generic one, as in some cases it is not even
possible to know whether the problem came from a text drag or a folder
drag, and whether the problem appears or not depends on the browser,
version and even operating system.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The jQuery Plugin triggers the "dragover" callback when the browser
triggers the "dragover" event and the types in their DataTransfer
include a "Files" item. It also triggers the "drop" callback when the
browser triggers the "drop" event and the list of files in its
DataTransfer is not empty.
Unfortunately some browsers may trigger "dragover" events with a
DataTransfer that includes a "Files" item and then trigger a "drop"
event with an empty list of files. When that happens the actions
performed in the "dragXXX" callbacks could be left hanging if they were
expected to be finished in the "drop" callback (for example, if the drop
zone was highlighted during the drag to be then restored when the file
was finally dropped). This commit adds the "dropnofiles" callback to be
able to handle those situations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"disableDropState" was set as the event handler in 8d4e5747f3, but
the duplicated code was accidentally added back in 786e858d23.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Some bad databases don't respect the default null apprently.
Now even if they cast it to 0 it should work just fine.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If a PUT request comes in that is not JSON or from encoded. Then we can
only read it (exactly) once. If that is the case we must assume no
shared secret is set.
If we don't then we either are the first to read it, thus causing the
real read of the data to fail.
Or we are later and then it throws an exception (also failing the
request).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>