enabling "invite people" for password-protected folder/file #9931
Conversation
|
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
| @@ -639,7 +646,7 @@ export default defineComponent({ | |||
| this.hasPublicLinkEditing, | |||
| this.hasPublicLinkContribute, | |||
| this.hasPublicLinkAliasSupport, | |||
| !!link.password, | |||
| false, | |||
There was a problem hiding this comment.
does this always work? for example if you have password enforced for editable links only and switch permissions from existing link that only has view permissions to editable permissions, will the password required still pop up as it did before?
There was a problem hiding this comment.
@janackermann Could you please navigate me more in detail on how to recreate this use case?
There was a problem hiding this comment.
Sure, please remove all the other env settings and set
SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD
SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD
To true
https://owncloud.dev/services/sharing/configuration/
This will let you create a standard readonly link but as soon you want to change to edit permissions the popup opens and asks you to set a password
There was a problem hiding this comment.
Got popup asking to setup password in case of "can upload", "can edit" and "secret file drop". Still able to change to "invited people" which will drop password. After dropping password, I'm only able to set to "can view" without popup
There was a problem hiding this comment.
If I read the code correctly you can remove the hasPassword param from the LinkShareRoles.list and LinkShareRoles.filterByBitmask functions entirely, right? If that's correct then please do so.
There was a problem hiding this comment.
@kulmann
I was attempting to remove it from the start, but wasn't successful, quickest fix was setting false for it in specific instances.
If I would to test again removing it completely, how would this condition would be resolved?
...(hasAliasLinks && !hasPassword ? [linkRoleInternalFile, linkRoleInternalFolder] : []),
packages/web-client/src/helpers/share/role.ts LinkShareRoles.list
Don't have enough understanding of what and how alias link works and what it could affect
There was a problem hiding this comment.
[...] how would this condition would be resolved?
...(hasAliasLinks && !hasPassword ? [linkRoleInternalFile, linkRoleInternalFolder] : []),packages/web-client/src/helpers/share/role.ts LinkShareRoles.list
Alias links are what we now call only invited people or internal links in the ui. They don't hold permissions on their own, they just serve as a pointer to a file or folder (but in the same data structure like a public link). Meaning: the one who clicks on such a link needs something else which grants permission to the file/folder, i.e. a share or a space membership with certain privileges.
That being said, a password doesn't make sense at all for an alias link, because the receiver of the link needs to hold permissions to access the linked file/folder anyway. Don't know why we would ever hide the alias link role when a password has been set before. Removing the && !hasPassword in fact seems to be the underlying bugfix, that you addressed by always setting it to false. Just remove the && !hasPassword condition entirely please. And with that there are no other references to the hasPassword param anymore => you can get rid of the param.
|
Kudos, SonarCloud Quality Gate passed! |
* enabling invite people for password-protected folder/files * removed hasPassword from LinkShareRoles * added invite people for password-protected folder changelog
Description
Enabling users to switch link permission to
invited onlyfor password protected folders/files.While switching to
invited only, the password and expiration date is removedRelated Issue
Types of changes
Checklist: