-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: share by mail: password not automatically set although passwords enforced #43919
Comments
@fenn-cs do you think this is a frontend issue only? can you provide a quick check 🙏 |
@sorbaugh It appears to be at the frontend level |
This bug seems to have been a backport into version 27 and now 27 is affected. I tried to apply 27.1.7 this morning and my post upgrade quality testing had this same issue. In version 27.1.7, the UI for automated password appears to be filled as expected. However when you attempt to save the link it fails and displays "Error creating the share: Passwords are enforced for link and mail shares". If you manually type in a password into the password field it works and the share is saved with success. I rolled back to my 27.1.6 snapshot and it immediately worked again as expected. So in some way, the automated password is being put into the UI but the variable is not being loaded correctly until a manual password is entered. I have another test instance with 27.1.7 and can easily replicate. Happy to test patches. |
Same problem here. (NC 27.1.7) |
Same Problem here, (NC 27.1.7) |
Before the password is set on a new share, the computed property `hasUnsavedPassword` is used to check that `this.share.newPassword` is not undefined. Direct assignment without using Vue's `this.$set` makes it impossible for vue to detect that changes have happened on the share object. Hence the inreactivity. This worked initially most likely because `this.share.newPassword = await GeneratePassword()` was executed before the computed properties where evaluated. Resolves : #43919 Signed-off-by: fenn-cs <[email protected]>
Before the password is set on a new share, the computed property `hasUnsavedPassword` is used to check that `this.share.newPassword` is not undefined. Direct assignment without using Vue's `this.$set` makes it impossible for vue to detect that changes have happened on the share object. Hence the inreactivity. This worked initially most likely because `this.share.newPassword = await GeneratePassword()` was executed before the computed properties where evaluated. Resolves : #43919 Signed-off-by: fenn-cs <[email protected]>
Before the password is set on a new share, the computed property `hasUnsavedPassword` is used to check that `this.share.newPassword` is not undefined. Direct assignment without using Vue's `this.$set` makes it impossible for vue to detect that changes have happened on the share object. Hence the inreactivity. This worked initially most likely because `this.share.newPassword = await GeneratePassword()` was executed before the computed properties where evaluated. Resolves : #43919 Signed-off-by: fenn-cs <[email protected]> [skip ci]
Before the password is set on a new share, the computed property `hasUnsavedPassword` is used to check that `this.share.newPassword` is not undefined. Direct assignment without using Vue's `this.$set` makes it impossible for vue to detect that changes have happened on the share object. Hence the inreactivity. This worked initially most likely because `this.share.newPassword = await GeneratePassword()` was executed before the computed properties where evaluated. Resolves : #43919 Signed-off-by: fenn-cs <[email protected]> [skip ci]
Before the password is set on a new share, the computed property `hasUnsavedPassword` is used to check that `this.share.newPassword` is not undefined. Direct assignment without using Vue's `this.$set` makes it impossible for vue to detect that changes have happened on the share object. Hence the inreactivity. This worked initially most likely because `this.share.newPassword = await GeneratePassword()` was executed before the computed properties where evaluated. Resolves : #43919 Signed-off-by: fenn-cs <[email protected]>
Before the password is set on a new share, the computed property `hasUnsavedPassword` is used to check that `this.share.newPassword` is not undefined. Direct assignment without using Vue's `this.$set` makes it impossible for vue to detect that changes have happened on the share object. Hence the inreactivity. This worked initially most likely because `this.share.newPassword = await GeneratePassword()` was executed before the computed properties where evaluated. Resolves : #43919 Signed-off-by: fenn-cs <[email protected]>
Before the password is set on a new share, the computed property `hasUnsavedPassword` is used to check that `this.share.newPassword` is not undefined. Direct assignment without using Vue's `this.$set` makes it impossible for vue to detect that changes have happened on the share object. Hence the inreactivity. This worked initially most likely because `this.share.newPassword = await GeneratePassword()` was executed before the computed properties where evaluated. Resolves : #43919 Signed-off-by: fenn-cs <[email protected]>
On 28.0.4 (final) the problem persist :( |
Just upgraded to 28.0.4. It works if the default share permissions under Admin -> Sharing have some permissions enabled, but if the permissions are set to either all enabled or all disabled (view only) it breaks and the password doesn't generate. |
I can confirm. This bug still exists in 28.0.4. Steps to reproduce are identical to the initial bug report. |
Confirmed, still broken in 28.0.4 and 27.1.8. |
Fix in #44571 |
Problem still persists on NC 28.0.5 and 29.0.0. |
@MalteP please open a new issue, this is unrelated to this one. This one was about enforced passwords, which is fixed now. |
Bug description
If creating a share by mail and the usage of a password is enforced (Administration settings -> Sharing -> Allow users to share via link an emails -> Enforce password protection), the password field is not prefilled (as it was until NC 28.0.2). A click on "Save share" leads to an error message and the share is not being created.
Steps to reproduce
Expected behavior
A password should be automatically created and inserted/suggested in the password field.
Installation method
Community Manual installation with Archive
Nextcloud Server version
28
Operating system
Other
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Updated from a MINOR version (ex. 22.1 to 22.2)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
No response
Additional info
Bug found in NC 28.0.3
The text was updated successfully, but these errors were encountered: