BugFix - Do not Filter Share Type #1741
Conversation
Signed-off-by: alperozturk <[email protected]>
alperozturk96
force-pushed
the
bugfix/create-sharee-user
branch
from
11b3961 to
7c591c3
Compare
Signed-off-by: tobiasKaminsky <[email protected]>
| } else { | ||
| null | ||
| } | ||
| return ShareeUser(userId, displayName, shareType) |
There was a problem hiding this comment.
This changes what this function returns in some cases. For example, if a public link share was parsed, null was previously returned, now ShareeUser("", "", PUBLIC_LINK) is returned. I'm not sure if or what implications this change has.
There was a problem hiding this comment.
This change is intentional. Previously, the corresponding remote file lacked a shareType due to a missing username. Now, even if the username is absent, we can still determine the shareType, allowing it to be displayed in the UI.
A missing username should not cause issues (crash etc), as external share links do not include one, and the username should not be mandatory. We might consider renaming the data class and adding documentation in a separate PR.
See, there is no username for this share.
Client PR: nextcloud/android#14989